Repository navigation
Add job metadata labels to runner pods when a job is assigned #4485
Description
What would you like added?
When using ARC at the org level, there's no way to attribute runner pod costs to the specific repository or workflow that triggered the job. The EphemeralRunner status already receives job info (repository name, display name, workflow run ID) from the listener when a job is assigned, but this information is never propagated to the pod.
Proposal: Patch pod labels/annotations with job metadata when the controller reconciles an EphemeralRunner that has been assigned a job:
- actions.github.com/job-repository (label, sanitized)
- actions.github.com/job-display-name (label, sanitized)
- actions.github.com/job-repository-name (annotation, full value)
- actions.github.com/workflow-run-id (annotation)
Changes required:
- EphemeralRunner controller patches pod labels/annotations when job info is present on the status
- Scale set manager role needs patch verb on pods
- Label values are sanitized to meet K8s validation (63 chars, alphanumeric start/end)
Why is this needed?
This enables cost attribution via pod labels without requiring changes to individual workflows. It also allows us to only modify permissions on the listener pods, ensuring the actual runner pods don't have permissions to mutate pod configuration.
Activity
github-actions commentedon May 5, 2026
Hello! Thank you for filing an issue.
The maintainers will triage your issue shortly.
In the meantime, please take a look at the troubleshooting guide for bug reports.
If this is a feature request, please review our contribution guidelines.
ntno commentedon May 21, 2026
hello github team
i manage enterprise runners using ARC and this feature would greatly help my team to get visibility into our users' usage patterns. we are interested in organization, repository, workflow file, and job name labels.
thank you!
hnnynh commentedon Jun 5, 2026
We've been thinking about this as well, and it would be very helpful for our ARC metrics and cost attribution use cases.
We've been considering how to implement this through custom configuration, so it would be great if this were supported as a built-in feature. It would also be useful if repository-related data were available in metadata, not only in status, so it can be used more easily for Kubernetes-level observability and attribution.
It would be good to add custom label that gets data from job status. (It's just an idea.)
Hope to see this feature available soon.
jordan-da commentedon Jul 23, 2026
It would be extremely useful if we could associate run id to resource usage. Right now it isn't easy determine how much a workflow needs when it runs, making it really hard to tune. You basically have to create a whole other runner with its own name just for this purpose, but that doesn't help for ongoing tuning.
hnnynh commentedon Jul 24, 2026
For now we just wrote a little exporter that watches EphemeralRunner objects and exposes the job info (repo, job, etc.) that's already on the status as per-pod metrics. I'd love to see it supported natively. +1