This action returns the UUID for the current job.
Notably, this UUID is generated by GitHub and can be used to identify the corresponding job record via API calls.
- uses: jenseng/get-job-uuid@v1
id: job-uuid
- env:
uuid: ${{ steps.job-uuid.outputs.uuid }}
run: |
echo "job uuid: $uuid"On the API side, this UUID is exposed as the corresponding check run's external_id. So to get from the UUID to the job ID, you can do something like the following:
- name: Find job id
shell: bash
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, you can see the extracted job ids from this repo's own GitHub Actions jobs.
Although GitHub doesn't directly expose the job UUID, it can be reliably extracted from the worker diagnostic logs that get generated for every job. Even if debug logging is disabled, these logs are still present and accessible within the job. The basic process is as follows:
- The action finds the
Runner.Workerprocess information. - The action infers the
_diagdirectory relative to the location of theRunner.Workerbinary. This is necessary since the directory may be in a different location depending on the runner type (e.g.ubuntu-latestvswindows-latestvsself-hosted) - The action extracts the UUID from the worker log file in the
_diagdirectory.
This action is known not to work within containerized jobs, since the host processes and file system are not accessible from within the container.
The scripts and documentation in this project are released under the ISC License