Associating GitHub Actions Workflow Jobs to their API Counterpart

[kylekthompson]

Hello!

My team and I have been working on an integration with GitHub for a while now and have been running into some challenges around the cohesion between the actions runner environment and the GitHub Rest API.

Long story short, we were finding that in some cases it's a little challenging to associate a job that's running in Actions to a job that's returned by the API:

• On the runner side, there's only the GITHUB_JOB environment variable (which is the YAML key) (no database identifier or anything of that nature)
• On the API side, there's only the database identifier and display name (which doesn't necessarily align with the YAML key because it includes matrix information and takes the user-specified job name into account)

I've opened a PR to the runner to expose the display name, which would significantly help, but we were wondering if it'd be possible to expose the YAML key through the GitHub API (the same thing exposed in the GITHUB_JOB environment variable) as well. The combination of YAML key + display name, I believe, would let us uniquely identify a job within the list that's returned from, e.g., the list jobs endpoint. Right now, that's not possible with the runner PR alone because, while likely a rare occurrence, job display names do not need to be unique.

I will note, however, that really my suggestions here are a sort of stop-gap. As I alluded to in the runner PR, it'd be great if the job's database identifier could be included in the runner context, but I wouldn't be surprised if there were some architectural decisions precluding that as an option. In lieu of that, this'd be sufficient for our use cases at least.

Thanks!

An aside: I'd love to find out that I'm wrong and there's a better way to do this, so please feel free to suggest something else!

[ChristopherHX]

The combination of YAML key + display name, I believe, would let us uniquely identify a job within the list that's returned from, e.g., the list jobs endpoint

I don't think this is enough, we need the jobid of the rest api, which is not sent to the runner via the protocol.

• job display name is not unique per yaml key one example of a lot of possible situations

  jobs:
    _:
      strategy:
        matrix:
          a:
          - a
          - a
          - a
      steps:
      - run: exit 0 # All three jobs have displayname `_ (a)`

• The jobid of the rest api was already requested here https://github.com/orgs/community/discussions/8945
• Here a cancelled PR created after the response of the first request, Add github.job_id to context. actions/runner#1950, closed after someone realized that the job id for the rest api is not in the job request message.

[ChristopherHX]

I found a (buggy) workaround for selfhosting, but it get's slow / unreliable if some webhooks are delayed or dropped by github. Probably needs to poll the webhook endpoint to avoid missing a message.

E.g. this small fake github runner combined with webhooks can technically inject the rest api job id into the github context, then invoke the runner with an altered request message:
https://github.com/christopherhx/megascaler#extras-for-actionsrunner

[kylekthompson]

I don't think this is enough, we need the jobid of the rest api, which is not sent to the runner via the protocol.
The jobid of the rest api was already requested here https://github.com/orgs/community/discussions/8945

Yep, I absolutely agree having the database identifier sent to the runner context would be ideal. Thanks for the link to that discussion, I wasn't able to find it earlier!

• job display name is not unique per yaml key

That's a good reproduction and good to know. I'm not sure how much of a lift getting the job's database identifier into the runner's context would be, but in lieu of that I think this still at least helps minimize the risk of collision further. I'd be curious to see how often we run into those sorts of matrix collisions- while possible, I'd initially think teams wouldn't be likely to define a job like that because it'd presumably be running the exact same thing and burning minutes.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬