Select Topic Area

Product Feedback

Body

Reopening #53420

The webhook payload sent when a job is initially triggered always has workflow_job.runner_group_id & workflow_job.runner_group_name set to null. This is documented:

runner_group_id integer or null Required
The ID of the runner group that is running this job. This will be null as long as workflow_job[status] is queued.

runner_group_name string or null Required
The name of the runner group that is running this job. This will be null as long as workflow_job[status] is queued.

https://docs.github.com/en/webhooks/webhook-events-and-payloads#workflow_job

This makes sense(?), in the sense that the runner's group cannot be determined until the job is placed onto a runner. The use case for including runner metadata in the workflow_job event isn't obvious, I suspect it is to match the schema of https://docs.github.com/en/rest/actions/workflow-jobs?apiVersion=2022-11-28#get-a-job-for-a-workflow-run. Which itself is probably designed like that to keep the logic simple for a GitHub web UI view.

But back to the webhook event: the group requested by the job is a static value, set in the job's runs-on in the workflow file, so can be determined as soon as the job is triggered. Please include the requested group in the webhook event payload, with a suggested location of workflow_run.group. This would match the behaviour for labels, where the webhook payload includes the requested labels, but not the actual labels of the allocated runner.

Use case

We have a few different systems for managing self-hosted runners, and we'd like to keep the runner labels the same between systems. This lets us have something like a production group and an experimental group, and move jobs between them as needed. At the moment, we're using an array of labels like

jobs:
  my-job:
    runs-on:
      - ubuntu-latest
      - group=experimental

And configuring the webhook endpoints for the systems to ignore deliveries when the group label doesn't match. If the requested group were available in the webhook payload, there would be no functional change. We'd just update the syntax to:

jobs:
  my-job:
    runs-on:
      labels:
        - ubuntu-latest
      group:
        - experimental

And our systems would then filter deliveries by inspecting the payload's workflow_job.group instead.

What would make a difference is in managing and monitoring the systems, as we could easily control which repositories/workflows could use these systems via the existing runner group management UI.