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.