Expose job numerical id in workflow definitions and actions runner

[crohr]

Select Topic Area

Product Feedback

Body

Hello,

Building upon Expose GITHUB_JOB_ID as an environment variable, I would make the case here to the product team to finally give us access to the job id (numerical, e.g. 26515583698) generated by GitHub when creating a new workflow job.

Exposing in workflow definitions

Currently we only get access to the job's Run ID through ${{ github.run_id }}, but it is not enough in case we want to:

• fetch details from a specific job through e.g. the GitHub API, requiring us to fetch the run details, then iterate over the jobs until we find the correct one.
• easily build the full URL to reference a single job.
• most importantly, in the case of ephemeral self-hosted runners, there is no way to pin a job to a specific runner via the use of its job id in labels, which would greatly help third-party tooling such as ARC, Cirun, RunsOn, etc.

Exposing in actions runner

Currently, when using self-hosted runners AFAIK there is absolutely no way to know which specific job is being executed by the runner. GITHUB_RUN_ID is currently set, but it would be great if we could also access the job ID. This would help a lot with troubleshooting.

Thanks for considering the request, and please let me know if you need further details.

[alecmocatta]

There are API endpoints that require this; it's odd how hard it is to retrieve. Agree it should be exposed as an environment variable.

Fwiw, here's what we did to get it:

name: ${{ join(matrix.*, ' - ') }}
env:
  JOB_NAME: ${{ join(matrix.*, ' - ') }}
steps:
  - uses: actions/github-script@7a5c598405937d486b0331594b5da2b14db670da # v6
    with:
      script: |
        const assert = (x, ...args) => { if (!x) { throw console.assert(x, ...args) } }

        // https://octokit.github.io/rest.js/v18#actions-list-jobs-for-workflow-run-attempt
        let jobs = await github.rest.actions.listJobsForWorkflowRunAttempt({
          owner: context.payload.repository.owner.login,
          repo: context.payload.repository.name,
          run_id: context.runId,
          attempt_number: process.env.GITHUB_RUN_ATTEMPT,
          per_page: 100,
        })
        assert(jobs.status === 200 && jobs.data)
        jobs = jobs.data.jobs

        jobs = jobs.filter(job => job.name === process.env.JOB_NAME)
        assert(jobs.length === 1)

        const job_id = jobs[0].id;
        return job_id

[kzu]

Unless you pass down a specific envvar for the job name, this isn't generalizable for a reusable action, for example. That's what I meant, sorry m

[Marle383]

There are API endpoints that require this; it's odd how hard it is to retrieve. Agree it should be exposed as an environment variable.

Fwiw, here's what we did to get it:

name: ${{ join(matrix.*, ' - ') }}
env:
  JOB_NAME: ${{ join(matrix.*, ' - ') }}
steps:
  - uses: actions/github-script@7a5c598405937d486b0331594b5da2b14db670da # v6
    with:
      script: |
        const assert = (x, ...args) => { if (!x) { throw console.assert(x, ...args) } }

        // https://octokit.github.io/rest.js/v18#actions-list-jobs-for-workflow-run-attempt
        let jobs = await github.rest.actions.listJobsForWorkflowRunAttempt({
          owner: context.payload.repository.owner.login,
          repo: context.payload.repository.name,
          run_id: context.runId,
          attempt_number: process.env.GITHUB_RUN_ATTEMPT,
          per_page: 100,
        })
        assert(jobs.status === 200 && jobs.data)
        jobs = jobs.data.jobs

        jobs = jobs.filter(job => job.name === process.env.JOB_NAME)
        assert(jobs.length === 1)

        const job_id = jobs[0].id;
        return job_id

[rdhar-tc]

This is a great snippet, thanks for sharing @alecmocatta!

It's a shame that we have to set the job name to match the JOB_NAME environment variable instead of something more contextually relevant, until GitHub exposes more job-specific values.

I gave it another go so that it's compatible with both matrix and regular jobs without a naming convention, as well as fallback for jobs with custom names.

- name: Get job link
  uses: actions/github-script@v7
  env:
    matrix: ${{ toJSON(matrix) }}
  with:
    script: |
      // Query jobs for the current workflow run.
      const { data: workflow_run } =
        await github.rest.actions.listJobsForWorkflowRunAttempt({
          attempt_number: process.env.GITHUB_RUN_ATTEMPT,
          owner: context.repo.owner,
          repo: context.repo.repo,
          run_id: context.runId,
        });

      // If matrix is used, find the job which includes the matrix values,
      // otherwise find the job with the same name as the current job.
      // If the job is not found, fallback to the first job.
      const link = workflow_run.jobs.find((job) =>
        (process.env.matrix.length
          ? job.name.includes(Object.values(JSON.parse(process.env.matrix)).join(", "))
          : job.name.toLowerCase() === context.job
        ).html_url || workflow_run.jobs[0].html_url;

      console.log("link: ", link);

[guettli]

thank you for that snippet. But overall I think it would be much better if Github would provide JOB_ID.

[rdhar-tc]

Agreed, @guettli, these are (hacky) workarounds until GitHub API provides an actual resolution for JOB_ID from any event trigger.

[alexevanczuk]

Hi all –
I wanted to check in if there's been any progress on this – is there anything on the roadmap to expose the job ID as an environment variable?

I tried some of the workarounds, but we quickly got rate limited, since we have 80 test shards each with their own job, and we push a lot of code, so I guess we went over the default tier for API requests here.

It'd be really great to get that job ID in an env var – we're building some tooling that links directly to a failing test shard (vs the CI suite as a whole), and this would be a huge UX improvement when using GitHub actions.

Thanks!

[qoomon]

@alexevanczuk feel free to try my action https://github.com/qoomon/actions--context

[jenseng]

There's an older discussion around this, where the GitHub team recently indicated that they are actively working on implementing this feature 🥳

[jenseng]

job.check_run_id (i.e. the numeric job id) is now available. Additionally, if/when this PR gets merged, it will also be available as an environment variable 🤞