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

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 }')

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.

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.

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

Having the same problem

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

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

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

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

Your scenario is indeed a common challenge when working with GitHub Actions, especially when dealing with artifacts and needing to trace them back to their originating jobs. Here are a few strategies to consider that might help streamline this process:

1. Environment Variables: Utilize GitHub's environment variables to include the job ID or other job-specific identifiers in your artifact names. GitHub Actions provide a set of default environment variables that can be quite useful. You can access the job name using GITHUB_JOB, the workflow name using GITHUB_WORKFLOW, and other useful identifiers.

   name: CI
   
   on: [push]
   
   jobs:
     build:
       runs-on: ubuntu-latest
   
       steps:
       - name: Checkout code
         uses: actions/checkout@v2
   
       - name: Build
         run: |
           echo "Building..."
           # Your build commands here
   
       - name: Upload artifact
         uses: actions/upload-artifact@v2
         with:
           name: artifact-${{ github.run_id }}-${{ github.job }}
           path: path/to/artifact

   In this example, the artifact name includes the github.run_id and github.job, which will help ensure unique and traceable names.

2. GitHub Contexts and Expressions: You can leverage GitHub contexts and expressions to dynamically generate artifact names that include unique identifiers.

   - name: Upload artifact
     uses: actions/upload-artifact@v2
     with:
       name: artifact-${{ github.run_number }}-${{ github.job }}
       path: path/to/artifact

3. Custom Scripts: If the built-in environment variables do not meet your needs, consider using a custom script to generate a unique identifier and save it to a file that can be included with your artifact. You can also log this identifier for future reference.

   jobs:
     build:
       runs-on: ubuntu-latest
   
       steps:
       - name: Checkout code
         uses: actions/checkout@v2
   
       - name: Generate UUID
         run: |
           UUID=$(uuidgen)
           echo "UUID=$UUID" >> $GITHUB_ENV
           echo "Generated UUID: $UUID"
   
       - name: Build
         run: |
           echo "Building with UUID: $UUID"
           # Your build commands here
   
       - name: Upload artifact
         uses: actions/upload-artifact@v2
         with:
           name: artifact-${{ env.UUID }}
           path: path/to/artifact

4. Workflow Level Context: If you need to pass information between jobs within the same workflow, you can use the outputs feature in GitHub Actions. One job can set an output, which can then be used by another job.

   jobs:
     generate-id:
       runs-on: ubuntu-latest
       outputs:
         job_id: ${{ steps.set-output-job-id.outputs.job_id }}
   
       steps:
       - name: Generate UUID
         id: set-output-job-id
         run: |
           UUID=$(uuidgen)
           echo "::set-output name=job_id::$UUID"
   
     build:
       runs-on: ubuntu-latest
       needs: generate-id
   
       steps:
       - name: Checkout code
         uses: actions/checkout@v2
   
       - name: Build
         run: |
           echo "Building with Job ID: ${{ needs.generate-id.outputs.job_id }}"
           # Your build commands here
   
       - name: Upload artifact
         uses: actions/upload-artifact@v2
         with:
           name: artifact-${{ needs.generate-id.outputs.job_id }}
           path: path/to/artifact

By using these strategies, you should be able to create unique and traceable artifact names, reducing the risk of name collisions and improving your ability to track which job generated which artifact.

You can only identify jobs uniquely within a workflow run by name in cases where you:

• don't use a matrix
• don't override the default name

You can only identify jobs uniquely within a workflow run by name in cases where you:

• don't use a matrix
• don't override the default name

What are DRY principles .. 🤦

Yes, it's hard-coding the name on the top level and pushing it down the road.

The same is done in our project.

And it looks like nobody notice in the GH/m$, that this is an issue.

I think i found a solution to work without further input parameters see v3 of https://github.com/marketplace/actions/enhanced-job-context

Looks great!

Do you know what it executes under the hood in https://github.com/qoomon/actions--context/blob/main/index.ts#L24-L26?

It works in job1, job2, and job3. But now I wonder what's changed, and how to implement it in other tools, like https://github.com/PyGithub/PyGithub

Oh my chaos, more dirty hacks! https://github.com/qoomon/actions--context/blob/main/lib/actions.ts#L249-L252

They match the job by a runner. It's not so bad if you ignore the fact that GH would do whatever it takes to not implement fixes in a proper place.

I take my words about "dirty" back. It looks like your invention, in this case, is a VERY smart and elegant solution!

Mapping the job to a one with runner_id + status == in_progress looks reliable.

glad it finally works

The implementation does not work with matrix jobs nor with jobs in reusable workflows.

The details of why it's useless are in https://github.com/orgs/community/discussions/8945#discussioncomment-7497043

Thank you for sharing and pointing these my way! Both are good examples of why this remains hard. And both actually are great examples of why I am so keen that we start to burn down the paper cuts. There are lots of cool features in Actions (such as reusable workflows!) where other bits of Actions 'just don't quite play nice'. This is what we really want to get to <3

Thank you for taking the time to reply to me and help me understand more. 🫶

Wow, I did not expect such a simple implementation for an issue open since 3 years. @nebuk89 maybe you could address this somewhere :-)

Without reviewing the PR I would guess you are right @jenseng , quite often I have found that a bunch of the simpler things that I hope can 'just' be done in the runner also require at least a small server side change from us :)

@nebuk89 I've created a new updated PR actions/runner#3489 to implement the changes from actions/runner#1950

Even having this "full" job name is a big improvement. I use pre/post job hooks on the runner to collect telemetry- but its useless without the full job name because I cannot distinguish any of the matrix jobs (of which, I have a ton) https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/running-scripts-before-or-after-a-job

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 

  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.

• Other users may engage with your post, sharing their own perspectives or experiences.

• GitHub staff may reach out for further clarification or insight. 

  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

@nebuk89 I can not find any roadmap item reflecting this issue. Could you help me out to find the right one?

Fwiw, you should do:

env:
  IS_SARIF: ${{ matrix.browser == 'safari' && 1 || 0 }}
  JOB_INDEX: ${{ matrix.shardIndex - (matrix.browser != 'safari' && 1 || 0) }}

You shouldn't use ${{...}} inside run: statements, it's a bad/dangerous practice.

Appreciate the pro tip 🫡 If you can't tell, I don't work primarily in CI/CD or know tons about security lol fwiw I followed your advice and it's not only more secure now but looks much cleaner 🥳

I'm not saying it's perfect, but sometimes I have gotten fixes from support. (One ticket recently although I cross posted a public docs ticket and a support ticket resulted in a fix.)

Vendors typically have an internal system of some sort tracking discussions like these, and filing a ticket will get a "corporate customer X wants this" added to that system. Which is what happened with our ticket.

I don't expect it will cause anything to be changed more quickly than they've already planned, but you never make the shots you don't take, etc.

We are completely stuck without access to the job id.

Our use case is to collect metrics from runners using hooks (ACTIONS_RUNNER_HOOK_JOB_STARTED, ACTIONS_RUNNER_HOOK_JOB_COMPLETED).

Since some essential information (such as job status and queued time) is only available via the API, we need to fetch metrics from the API.

However, we can't correlate API metrics with runner metrics because there is no common set of fields that allows for this.

Providing the job id would solve the issue.

Additionally, neither GITHUB_TOKEN nor GitHub context variables are available in hooks, so we can’t even use workarounds like qoomon’s action that attempts to detect jobs. And I fully agree with saxonww that calling the API for each job is a path to nowhere.

It’s very disappointing that such a simple request has been ignored for years. The original issue was created more than five years ago: actions/runner#324

@saxonww could you please share the internal ticket ID with me? I plan to contact our GitHub support contacts or open a new ticket and would like to refer to yours—maybe it will increase the chances of this being taken into account.

@Peter-Sh 3362887. We have some others we've opened about raising API limits, because as soon as we started pulling the job number workflows began to fail.

I'm replying to your comment but this is intended to be more general and not you-specific. I don't think it's helpful to take the attitude that a simple request means it's a simple change, or that the request is being ignored. I'd guess that everyone at Microsoft looking at this understands and would agree it would be useful to include the job number, but that the underlying architecture of GitHub Actions, and specifically where and when the contexts are created and updated, make this more complicated than we realize. A clue would be that when using an API call, the job number is not consistently available right away, so you have to implement some sort of backoff/retry if you need it.

the underlying architecture of GitHub Actions, and specifically where and when the contexts are created and updated, make this more complicated than we realize

Yeah this indeed seems to be the case. In the wild I've even seen self-hosted runner jobs finish before the job records exist from a GitHub UI/API perspective 🤯 ... so I suspect that making the job id available within the job would require some significant plumbing/rearchitecting 😞

I went ahead and put together an action to extract the UUID from the worker log. It turns out these logs actually always present on the runner, whether or not debug logging is turned on 🥳 . So basically the usage is as follows:

- uses: jenseng/get-job-uuid@v1
  id: job-uuid

The uuid output will contain the GitHub-generated UUID for the job. You can then use that to reliably retrieve the job id:

- env:
    GITHUB_TOKEN: ${{ github.token }}
    uuid: ${{ steps.job-uuid.outputs.uuid }}
  run: |
    # first find the check_suite_id for this run
    check_suite_id="$(
      gh api "repos/{owner}/{repo}/actions/runs/${GITHUB_RUN_ID}" --jq .check_suite_id
    )"

    # then use the check_suite_id and uuid to find the job id (the check run id _is_ the job id)
    job_id="$(
      gh api "repos/{owner}/{repo}/check-suites/${check_suite_id}/check-runs" \
        --jq ".check_runs[] | select(.external_id == env.uuid) | .id"
    )"
    echo "::notice::Job ID: ${job_id}"

For example, the action repo's own CICD workflow uses the action to extract its own job ids and generate full job URLs. A nice thing about this approach is that it should work reliably across runner types (ubuntu-latest, windows-latest, self-hosted), with matrix jobs, etc.

If I have some time in the next couple days, I'll see about putting together a higher level action to retrieve the job id, more or less as outlined above.

As @jenseng identified earlier, this PR introduced feature-flagged support for JobContext.CheckRunID (thanks to @pje), which was shipped three months ago in actions/runner v2.324.0.

Could you share if there's been any development since then to include the job_id or check_run_id to the job expression context within GitHub Action runners, please? Even if it's available by setting certain environment variables/features, be keen to give it a try. Thank you 👍

Based on how the flag is implemented in the codebase, I would have thought you'd set actions_add_check_run_id_to_job_context as a repository secret similar to how you'd set ACTIONS_STEP_DEBUG...

gh secret set actions_add_check_run_id_to_job_context -r <org>/<repo> --body "true" 

However, this did not work nor did any other attempts to place the environment variable.

I don't think they're particularly similar.

One appears to be a runner configurable:

       if (Global.Variables.GetBoolean(Constants.Runner.Features.AddCheckRunIdToJobContext) ?? false)

The other is looking at a run context:

varsContextData.TryGetValue(Constants.Variables.Actions.StepDebug

They just happen to be constants.

If you want to play with this, you could probably host your own runners and set the global feature flag.

(I absolutely want this feature, but don't have the energy or money to spend setting up my own runners especially given that my code needs to run on GitHub default runners.)

For perspective we have set up our own runners and could enable the feature flag. But we also support using github hosted runners alongside them. So it doesn't make sense to adopt this unless it is supported by both.

I suspect this won't even work on self-hosted runners until GitHub starts sending down additional data from the backend... the feature flag value comes from the RunnerJobRequest message, which is entirely controlled by GitHub. Additionally, if it's set to true, the runner takes additional data from the message's ContextData and injects it into the job context. I've spot checked these messages fairly frequently (I just checked one now), and they have never included the check_run_id.