Add job_id into github.context

[alvarezfr]

Hi,

Right now, it seems that there is no way to identify the job that is being run from inside of the GitHub workflow run.

The github context only has the element job, with matches with the string id of the job.

But when you try to get the job from the GitHub API, there is no way to match against it. If there is no name for this job, you could match them but it is not safe.

I think you could add to the github or job context the id of the job run to be able to query the GitHub API about the current job.

I found these community entries regarding this request, but I couldn't find a ticket or discussion regarding this issue:

• https://github.community/t/job-id-is-string-in-github-job-but-integer-in-actions-api/139060
• https://github.community/t/get-action-job-id/17365/4

Thanks!

[ethomson]

Thanks for the feedback. We should add this, indeed. I'll talk to the team about this in the new year.

[nhooyr]

What I did to find the job run id with the workflow run id based on @ianhundere's solution:

GITHUB_JOB_ID="$(curl -fsSL -H "Authorization: token $GITHUB_TOKEN" "https://api.github.com/repos/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID/jobs?per_page=100" | \
  jq ".jobs[] | select( .name == \"$GITHUB_JOB\") | .id")"
if [ -z "$GITHUB_JOB_ID" ]; then
  printf "failed to query GITHUB_JOB_ID" >&2
  exit 1
fi

[ianhundere]

i don't think i updated this, but this is the final thing i came to:

jobs_url="https://api.github.com/repos/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID/jobs"
job_id=$(curl -s -H "Authorization: token ${{ env.GITHUB_TOKEN }}" $jobs_url | jq -r '.jobs[] | select(.name == "${{ github.job }}" and .status == "in_progress") | .id')
drift_url="$GITHUB_SERVER_URL/$GITHUB_REPOSITORY/runs/$job_id?#step:3:${{ env.STEP }}"
repo_slug=$(echo $GITHUB_REPOSITORY | awk -F/ '{ print $NF }')

[sblask]

I am using something similar, but the problem is that github.job does not always contain the complete job name. Not sure it works with matrix alone, but it definitely does not work with re-usable workflows (workflow_call/uses) - it only contains the job name of the called workflow, but not the one of the calling one. So for example only callee where the jobs endpoint returns complete job names like caller (matrix_element) / callee.

[sblask]

That solution is also assuming that you don't set a name on the job that is different from the "job ID" aka the key in the yaml file.

[casper-jensen-maersk]

2022 is almost over. Do you happen to have any news on this? Running actions inside a matrix renders the context totally useless without the jobid

[casper-jensen-maersk]

Do you happen to have any news on this topic?
Not having the job id makes it impossible to use the jobs list for anything. Especially if you are running inside a matrix or someone has named their job differently.

[lucasmellos]

Having the same problem

[nomantis]

This would be a very good to have feature. When there is an existing action that uses the GitHub API, you know there is a need for it. Having it in the context, and especially as an environment variable (so that automation can use it too, without having to pass it as a jinja template variable), would be a godsend! 🙏🏻

[tvandinther]

Chiming in from 2023, we really need this. The job I am trying to get the ID for is a matrix job with a stringified JSON object as its value so the name is truncated making the workaround practically useless.

[davidboweninrupt]

I'm embarrassed to share this, but I know people are struggling.

Here is how I'm getting this to work in every scenario:

1. Add an environment variable to the step where you want to use the job name. Use the same logic as for the actual job name (yes, that's fragile).
2. Consume the environment variable as provided_job_name in the code that wants to correlate the job name in the API
3. Have a list of possible_job_names which might match. The provided_job_name from the environment variable and one that does this:

if len(provided_job_name) > 100:
    possible_job_names.append( provided_job_name[:97] + "..." )

4. Iterate over all the jobs in the API and compare each one to the possible_job_names. I always get a match this way. Raise an error to point the user to step 1 if there is no match.
5. Profit

I know this is not pretty but it has been very effective. I really hope Github don't see this as a workaround which delays implementing the fix. If I see that happening I may have to delete this post.

I should also add the customary reminder that you shouldn't risk your career or your user's happiness based on a snippet of code you saw someone post on the Internet.

[tlhunter]

Our use case for requiring a job Id is as follows:

We have software that runs against dozens of different npm packages. Each package run is done in a separate job. If this software fails then we send a Slack message to the team to look at the incompatible npm package. Ideally we would be able to provide a URL in this slack message so that a developer can click it for more information:

https://github.com/${{ github.repository_owner }}/${{ github.repository }}/actions/runs/${{ github.run_id }}/jobs/<😥>

[hermanbanken]

Is github.job the fix for this?

jobs.<job_id>
Use jobs.<job_id> to give your job a unique identifier. The key job_id is a string and its value is a map of the job's configuration data. You must replace <job_id> with a string that is unique to the jobs object. The <job_id> must start with a letter or _ and contain only alphanumeric characters, -, or _.

No it is not: this is the string key of the job, as in my_first_job and my_second_job.

jobs:
  my_first_job:
    name: My first job
  my_second_job:
    name: My second job

[bansalsulabh]

job-name is also not present in the github context.

[jsoref]

job-name is also begged for here: https://github.com/orgs/community/discussions/16614

[jkwinder]

We could really use the jobid in the github context so on a matrix job so we can provide a html_url to a workflow status dashboard...

[Felixoid]

So, it's one of the plenty cases, where GH actions aren't fixing their fundamental issues.

Just an example of how we solve it in python https://github.com/ClickHouse/clickhouse/blob/4b7aa30/tests/ci/env_helper.py#L49-L95

The code tries to address either the feature requested in this discussion or in the issue actions/runner#2577

[Felixoid]

We are experimenting with reusable workflows, and it's just the last border before the deepest inconsistency hell. The logs are
logs_33.zip, the run is https://github.com/Felixoid/actions-experiments/actions/runs/6774723377, the there's the tree

So, the job has a name parameter. And it's overwritable. Then the name is included in the jobs API. See call_test / CallTestname-one and another_call / CallTestname-two. But there's no ... any way to get this name from the job itself. Both jobs have a simple GITHUB_JOB=CallTest.

In Felixoid/actions-experiments@8eaa77a I tried to override the parameter - no luck.

update: in tests + concurrency_call (logs_39.zip) I tried to get this variable from at least any place. No luck, neither of the contexts github, runner, env, nor job contains this value.

So, the outcome: without kicking around with strange self-invented variables, GH actions not only prevent you from finding an easy way to get the job_id, but any tool you have out of the box will ultimately give a broken solution. Because who needs to know the full Job name, right?

[jsoref]

Yup.
I think I collect everything eventually. I think most of it is near here:
https://github.com/check-spelling/check-spelling/blob/15a82f1a4276abf802d30e8af2a2961b1786d909/unknown-words.sh#L2279-L2312

[philn-delphia]

It's almost 2024 and still no movement on this?
We require the job name in order to check if the current job run has changed from a failure to a success. Unfortunately, the only available environment variable (and context variable) is the yaml key for the job, but this causes issues if the job has been given a name. In that case all the API calls use the name, which isn't available anywhere else!

It's seems to be impossible to tie a current run to a previous run unless either the name of the job becomes available in environment or context, or the slug (it's not an id, it's not a name, it's got no nomenclature I can find) needs to be available in the API responses.

[Felixoid]

I've been having a long conversation with GH support, and it feels like I almost convinced them that it's an actual issue

[CYWong-Nick]

It's now 2024 and GitHub is still adding job ID in context. We need a way to distinguish one job from another, especially when using matrix. This should not be a difficult thing either, the job ID is already in the URL.

[enginoid]

The impact of this is ultimately an inability to link to logs from a test reporting system. This is critical for our evals setup where debuggable events within the job need to link back to the full job for logs, so I think this could mean we have to switch away from GitHub Actions.

[austinpray-mixpanel]

I said to hell with it and just started using random IDs as suffixes to get around duplicate artifact names. I would have just liked to use the job id for the workflow_call so I can at least trace an artifact back to the job that generated it.

Greatly simplified, but this guy runs into trouble when trying to upload artifacts from workflow_call invocations where it's called multiple times in a matrix (or just used multiple times at all)

name: Storybook
on:
  workflow_dispatch: 
  workflow_call:
  push:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      # ////////////////////////////////////////////////////////////////////////
      # Setup tasks
      # ////////////////////////////////////////////////////////////////////////
      # ////////////////////////////////////////////////////////////////////////
      # Run tests
      # ////////////////////////////////////////////////////////////////////////
      # ////////////////////////////////////////////////////////////////////////
      # Upload test artifacts
      # ////////////////////////////////////////////////////////////////////////
      - name: Generate a unique id
        id: gen-id
        if: always()
        run: |
          echo "rand=$(openssl rand -hex 3)" >> "$GITHUB_OUTPUT"
      - name: archive storybook junit
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: storybook-junit-${{ github.run_id }}-${{ steps.gen-id.outputs.rand }}
          path: junit.xml
          retention-days: 7
      - name: archive storybook json
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: storybook-json-${{ github.run_id }}-${{ steps.gen-id.outputs.rand }}
          path: storybook-run.json
          retention-days: 7

[AFMiziara]

2 years and a half and this is still a HUGE gap on GitHub API. It makes a lot of possible integrations and useful actions very hard to be implemented.