feat: add job_name to github context#3489
feat: add job_name to github context#3489qoomon wants to merge 1 commit intoactions:mainfrom qoomon:patch-1
Conversation
|
Hi, thanks for the patch. I am really looking forward to have it merged! By the way, what do you think about including the job ID? It would help with a bridge from https://api.github.com/repos/ClickHouse/ClickHouse/actions/runs/8363985040/jobs?per_page=1&page=13 to https://api.github.com/repos/ClickHouse/ClickHouse/actions/jobs/22961931602 in no additional actions |
|
@Felixoid unfortunately the job id needed for the api is not present, the System Variables {
"system.isScheduled": {
"value": "False"
},
"system.servertype": {
"value": "Hosted"
},
"system.culture": {
"value": ""
},
"system.pipelineStartTime": {
"value": "2024-10-04 11:28:22+00:00"
},
"system.runner.lowdiskspacethreshold": {
"value": "100"
},
"DistributedTask.NewActionMetadata": {
"value": "true"
},
"DistributedTask.EnableCompositeActions": {
"value": "true"
},
"DistributedTask.EnhancedAnnotations": {
"value": "true"
},
"DistributedTask.UploadStepSummary": {
"value": "true"
},
"DistributedTask.ForceGithubJavascriptActionsToNode16": {
"value": "true"
},
"DistributedTask.ForceGithubJavascriptActionsToNode20": {
"value": "true"
},
"DistributedTask.AddWarningToNode12Action": {
"value": "true"
},
"DistributedTask.AddWarningToNode16Action": {
"value": "true"
},
"DistributedTask.LogTemplateErrorsAsDebugMessages": {
"value": "true"
},
"DistributedTask.AllowRunnerContainerHooks": {
"value": "true"
},
"DistributedTask.DeprecateStepOutputCommands": {
"value": "true"
},
"DistributedTask.UseWhich2": {
"value": "true"
},
"DistributedTask.DetailUntarFailure": {
"value": "true"
},
"DistributedTask.UseActionArchiveCache": {
"value": "true"
},
"DistributedTask.EnableJobServerQueueTelemetry": {
"value": "true"
},
"DistributedTask.MarkJobAsFailedOnWorkerCrash": {
"value": "true"
},
"Actions.EnableHttpRedirects": {
"value": "true"
},
"system.teamProjectId": {
"value": "00000000-0000-0000-0000-000000000000"
},
"build.buildId": {
"value": "666"
},
"build.containerId": {
"value": "18431423"
},
"system.workflowFilePath": {
"value": ".github/workflows/example.yaml"
},
"system.phaseDisplayName": {
"value": "build"
},
"system.phaseId": {
"value": "08529e53-a864-5e57-8255-b4ac74128910"
},
"system.phaseName": {
"value": "build"
},
"system.phaseAttempt": {
"value": "1"
},
"system.jobIdentifier": {
"value": "build-with-reusable-workflow-with-matrix._20_x.build.__default"
},
"system.jobAttempt": {
"value": "1"
},
"System.JobPositionInPhase": {
"value": "1"
},
"System.TotalJobsInPhase": {
"value": "1"
},
"system.github.job": {
"value": "build"
},
"system.jobDisplayName": {
"value": "build-with-reusable-workflow-with-matrix (20.x) / build"
},
"system.jobId": {
"value": "0315e721-8f55-564f-db13-292a0596e43b"
},
"system.jobName": {
"value": "__default"
},
"system.github.token.permissions": {
"value": "{\"Contents\":\"read\",\"Metadata\":\"read\",\"Packages\":\"read\"}"
},
"system.workflowFileFullPath": {
"value": "qoomon/actions--context/.github/workflows/example-reusable.yml"
},
"system.github.token": {
"value": "***",
"isSecret": true
},
"system.github.results_endpoint": {
"value": "https://results-receiver.actions.githubusercontent.com/"
},
"system.github.results_upload_with_sdk": {
"value": "True"
},
"system.workflowFileRef": {
"value": "refs/heads/main"
},
"system.workflowFileSha": {
"value": "d2fec0f6c3c70eea6c8124a0a9458c7aea4565f4"
},
"system.runnerEnvironment": {
"value": "github-hosted"
},
"system.orchestrationId": {
"value": "595b9a62-e373-4b13-ba58-2f92a6c39f3a.build-with-reusable-workflow-with-matrix._20_x.build.__default"
},
"system.runnerGroupName": {
"value": "GitHub Actions"
}
} |
|
I see. Even a correct jobDisplayName is already a solid solution for the job ID resolving. So, many kudos to you |
|
Oh, wait. What about a defined env variable for this value? |
|
@Felixoid No unfortunately not. |
|
Thanks for making this PR.
|
|
This would make life exponentially easier. |
|
I have been involved tangentially with @qoomon a bit on this. @qoomon Correct me if i am wrong. Not Short, sadly too long full detail version: Up to this point it seems like a quality of life issue not necessarily a bug... But... Since the system.jobId contains a GUID that is not present in job api endpoint, the only unique identifier is the JOB name. The issue becomes apparent when you apply a matrix or reusable workflow: EDIT: (Since the is the only guaranteed unique data shared between the job level api and the github.job context) Something similar was added for the Telemetry. |
|
Finally I found a stable way 🎉 You could use my It will work also with matrix jobs and within reusable workflows. And any amount of jobs within a workflow run. jobs:
example:
runs-on: ubuntu-latest
environment: playground
steps:
- uses: qoomon/actions--context@v4
- run: |
echo "Job Id: ${GITHUB_JOB_ID}"
echo "Job Name: ${GITHUB_JOB_NAME}"
echo "Job Log URL: ${GITHUB_JOB_URL}"
echo "Environment: ${GITHUB_ENVIRONMENT}"
echo "Deployment URL: ${GITHUB_DEPLOYMENT_URL}"This action determines the current job by listing all job of current workflow with current run id and then finds current job by matching the runner name or id. |
This should work. As long as the names of the runners are unique? Which I think they are as that was the fall back method we had before if I remember correctly. |
|
They are unique in the environment variable however for the new GitHub runners they are all named 'GitHub Actions'. To work around that you need to parse the id from the environment variable and match the runner id with the job runner IDs from the API. |
Important
Solved see #3489 (comment) for a stable workaround.
Currently there is no system variable that contains a job id value that can be used to request the github api for a job.
system.jobIdcontains a GUID and therefore is useless for job API endpointBy providing the real/effective job name (as in the github api response of jobs), we are able to determine and request the current job by using list-jobs-for-a-workflow-run-attempt API endpoint and find the actual job by its name.
This would solve a lot of community requests e.g., https://github.com/orgs/community/discussions/8945
There was an attempt from attempt already from @TingluoHuang to fix this issue two years ago #1950
Update
It looks like the job.name of the api response job objects getting truncated at 100 characters 🤯.
So to make this work always the api response need to be adjusted as well.