Expose GITHUB_JOB_ID as an environment variable

[MarshallOfSound]

Describe the enhancement
Expose GITHUB_JOB_ID as an environment variable to the running steps. We need this in order for a job to be able to self-identify itself and potentially send it's own ID to a different service that would then use the GitHub API to perform actions (like check logs for instance).

Code Snippet
It looks like we need to add job_id to the whitelist here --> /~https://github.com/actions/runner/blob/master/src/Runner.Worker/GitHubContext.cs

Not sure though, hence raising this issue

[ericsciple]

Note, the job ID in yaml is the key in the jobs mapping (terminology aligns with step id keyword in yaml). So if we expose this via the context or env var, we should consider the terminology conflict.

[ericsciple]

@MarshallOfSound whitelist wont solve it. The job ID isn't in the github context.

on: push
jobs:
  one:
    runs-on: ubuntu-16.04
    steps:
      - name: Dump GitHub context
        env:
          GITHUB_CONTEXT: ${{ toJson(github) }}
        run: echo "$GITHUB_CONTEXT"

It sounds like for this scenario you need the number (this job_id), correct?

[MarshallOfSound]

@ericsciple Yes we'd need the job_id number that the GitHub API takes in. If that's not in the context how can we get that exposed?

[ericsciple]

@TingluoHuang @juliobbv might be able to help drive an ADR for this change. IIRC logs are best effort (although lots of retries, so likely there) and uploaded asyncronously. It's unclear to me whether adding the value would actually enable the desired scenario. Ting or Julio can help figure out.

Also it doesn't look like the runner has the job ID at all. I dumped the worker log and confirmed it's not in the job message received from the server.

[ericsciple]

@chrispat fyi can help prioritize or redirect if there is a better place for the request

[chrispat]

@MarshallOfSound CodeCov does something similar but they just use the run_id which is in the environment and context. Is there any specific reason you need to have the job_id?

[MarshallOfSound]

@chrispat It looks like the only way to get the logs of a job is with the job_id? Unless I'm missing something https://developer.github.com/v3/actions/workflow_jobs/#list-workflow-job-logs

Not sure how you can pull logs without it

[ericsciple]

The run id can be used to get the job ids

[MarshallOfSound]

@ericsciple Are you suggesting we iterate through all the jobs in the run and pull the logs for each job and if any one of them contains what we're looking for we can consider it valid? That seems do-able but sub-optimable (it'll go through an API token faster than you otherwise would)

[MarshallOfSound]

@ericsciple Just circled back to this and it looks like with the new GITHUB_JOB variable we can do a more exact job lookup now using the API. However I think I just hit this issue you predicted earlier.

IIRC logs are best effort (although lots of retries, so likely there) and uploaded asyncronously. It's unclear to me whether adding the value would actually enable the desired scenario. Ting or Julio can help figure out.

They may be best effort but afaics the logs aren't available in the API at all until the job completes. Are their any plans to allow us access to the logs before the job completes, otherwise I'm stuck behind a brick wall 😆

[dentarg]

I understand that 123805166 is GITHUB_RUN_ID (or github.run_id) in /~https://github.com/dentarg/actions-test/actions/runs/123805166

In /~https://github.com/dentarg/actions-test/runs/735126681, what is 735126681? Is that the job ID that's requested here?

It would be nice to be able to construct /~https://github.com/dentarg/actions-test/runs/735126681 from a workflow run. My use-case is posting a direct link to the build in e.g. Slack.

[chrispat]

That is the check_suite id. Depending on how you navigate sometimes you will get that URL. However, for slack I would recommend using the http://github.com/dentarg/actions-test/actions/runs/<GITHUB_RUN_ID>

[chrispat]

@ericsciple given we called called the YAML id of the job GITHUB_JOB it seems we could add a GITHUB_JOB_ID with the API job id to mirror GITHUB_RUN_ID.

[matkoch]

Any update on this? I still have to do HTTP requests and fancy json iteration to get the job id. 😃

[MichaelJJ]

We would appreciate this feature also, would like to see it in the $github context

[relsqui]

That is the check_suite id. Depending on how you navigate sometimes you will get that URL. However, for slack I would recommend using the http://github.com/dentarg/actions-test/actions/runs/<GITHUB_RUN_ID>

This does not address the problem. When there are hundreds of jobs in a workflow matrix, linking directly to the one that matters vs. linking to the workflow summary makes a world of UX difference.

[Evilweed]

Please expose, this is making our developers confused especially if the job was running with flag "continue-on-error" and is green but we need to for example link to this job in automatically generated comment that is added to PR :<

[cg14823]

By the looks of it the numeric job id is generated on the GitHub API but it is just not sent to the runner to be exposed. Is it possible to get it to the runner?

[Philippe-OPC]

Sry to dig this up, the numeric id of the job would be great. To explain a little bit my use case, i want to post the url of the job that failed to a database for a user to actually see logs of the CI tool i run in the github runner. The difficulty is that i use a matrix of var to run multiple times the "jobs". Here is some sample of the code i use to understand a little bit :

action file :

name: Ci tool run

on:
  workflow_dispatch:

jobs:
  job1:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        env_suffix: ["DEV","UAT","PRD"]
    environment:
      name: ${{ matrix.env_suffix }}
    env: 
      BASE_REF: ${{ matrix.env_suffix }}
    
    steps:
      - name: run ci tools
        uses: mycitoolssharedaction
        with:
          var1: var1
          job_id: ?????

code to write in a database :

const githubServerUrl = "https://github.com"
const githubRepository = process.env.GITHUB_REPOSITORY
const githubRunId = process.env.GITHUB_RUN_ID
const githubJobId = process.env.GITHUB_JOB_ID
const githubFullUrl = `${githubServerUrl}/${githubRepository}/actions/runs/${githubRunId}/jobs/${githubJobId}`

sql_client = new SQLClient();

query = 'INSERT INTO mytable VALUES(`${githubFullUrl}`)'

sq_client.run_query(query)

As an example

Thanks !

[untra]

This is also desired. For our use-case, we want to use the github api to post a reply to our PR in a failed build, with a link to /~https://github.com/company/repo/actions/$GITHUB_RUN_ID/jobs/$GITHUB_JOB_ID, which is a sweet dashboard to give context to a failed build.

[s0undt3ch]

Managing self hosted runners has not gotten simpler by GitHub.
The fact that we can use ACTIONS_RUNNER_HOOK_JOB_COMPLETED and ACTIONS_RUNNER_HOOK_JOB_STARTED helps a tad bit, but, which job?
We need that information to overcome the slim support for self hosted runners in the GH API.

[github-actions]

Thank you for your interest in the runner application and taking the time to provide your valuable feedback. We kindly ask you to redirect this feedback to the GitHub Community Support Forum which our team actively monitors and would be a better place to start a discussion for new feature requests in GitHub Actions. For more information on this policy please read our contribution guidelines. 😃

[relsqui]

I respect the reasons to close this, but "as completed" seems disingenuous.

[s0undt3ch]

Closing this issue, as @relsqui pointed out, as completed, is not the right thing to do.

This is a feature request, and going to a forum to discuss is about the same as, yeah, we might read it, and even reply, but we won't do it.

If we were talking about, please add runner events X and Y to webhooks, and then you could possibly say, let's bring this to the forums because there might be other events other users might be interested in, then, potentially it could make sense, buy still, leave the issue open because it hasn't been resolved, nor rejected.

My .1 cent.

[crohr]

As requested, I just opened a new discussion here.