Add workflow name and target labels

[mumoshu]

Hey team 👋 Thank you very much for maintaining this awesome project!

This is for https://github.com/orgs/community/discussions/172708.

This PR adds job_workflow_name and job_workflow_target labels to all job-related Prometheus metrics, making it possible to track metrics by workflow name and differentiate between main branch builds, PRs, and tag releases.

# Job completed for pull request
gha_completed_jobs_total{
  enterprise="",
  event_name="pull_request",
  job_name="test-job",
  job_result="succeeded",
  job_workflow_name="ci-pipeline",              # NEW: workflow file name
  job_workflow_ref="example-org/example-repo/.github/workflows/ci-pipeline.yml@refs/pull/42/merge",
  job_workflow_target="pull/42",                # NEW: target ref (PR #42)
  organization="example-org",
  repository="example-repo"
} 1

# Job execution duration for branch push
gha_job_execution_duration_seconds_bucket{
  enterprise="",
  event_name="push",
  job_name="build",
  job_result="succeeded",
  job_workflow_name="deploy",                   # NEW: workflow file name
  job_workflow_ref="example-org/example-repo/.github/workflows/deploy.yml@refs/heads/main",
  job_workflow_target="heads/main",             # NEW: target ref (main branch)
  organization="example-org",
  repository="example-repo",
  le="30"
} 1

# Job startup duration for tag push
gha_job_startup_duration_seconds_sum{
  enterprise="",
  event_name="push",
  job_name="release",
  job_workflow_name="release-automation",       # NEW: workflow file name
  job_workflow_ref="example-org/example-repo/.github/workflows/release-automation.yml@refs/tags/v2.1.0",
  job_workflow_target="tags/v2.1.0",           # NEW: target ref (tag v2.1.0)
  organization="example-org",
  repository="example-repo"
} 15.5

I've tested this by locally running ARC on a kind cluster and triggering workflows against a test repo - the new labels are correctly populated for push, pull_request, and tag events.

While this could be a temporary solution until the Actions performance metrics page is enhanced with fine-grained metrics per job target (when applicable), I believe this is valuable to have today based on experience running ARC in production.

[Copilot]

Pull Request Overview

This PR enhances Prometheus metrics for GitHub Actions Runner Controller by adding workflow name and target labels to job-related metrics. This enables better tracking and filtering of metrics by workflow name and distinguishing between different deployment targets (main branch, PRs, tags).

• Adds job_workflow_name and job_workflow_target labels to all job-related metrics
• Implements workflow reference parsing logic to extract meaningful workflow names and target information
• Updates Helm chart documentation to reflect the new metric labels

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
cmd/ghalistener/metrics/workflow_ref_parser.go	Implements parsing logic to extract workflow name and target from GitHub workflow references
cmd/ghalistener/metrics/workflow_ref_parser_test.go	Comprehensive test suite for the workflow reference parser with various reference formats
cmd/ghalistener/metrics/metrics_integration_test.go	Integration tests verifying the new labels are correctly populated in job metrics
cmd/ghalistener/metrics/metrics.go	Updates job label creation to include the new workflow name and target labels
charts/gha-runner-scale-set/values.yaml	Updates example metric configurations to include the new labels

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The condition idx > 0 should be idx >= 0 to handle the case where the PR number is at the start of the string. Currently, if prPart starts with the separator, the target won't be set.

Suggested change

	if idx := strings.Index(prPart, "/"); idx > 0 {
	if idx := strings.Index(prPart, "/"); idx >= 0 {

[mumoshu]

This intends to extract {number} out of refs/pull/{number}/merge by (1)TrimPrefix producing {number}/merge and (2)the idx here points the position of /.

If we allowed idx to be 0 like suggested, info.Target could potentially be pull/ without any number, which isn't useful anyway.

[nikola-jokic]

Hey @mumoshu,

First of all, your PRs are always well appreciated!

Quick question: since the workflow ref introduces a bit higher cardinality, wouldn't it be better to split the ref and only use these fields? We can split on '@' and use the first part as the workflow, and the second part as the target? I'd love to deduplicate information and reduce the storage. Since the next release is 0.13.0, we can create a breaking change as long as we call it out in the release. The way you explained the problem, it seems to me that it is more beneficial to users to have the ref split than to have it as a single label. I'm not sure that is why I have to ask ☺️

And feedback from others on this PR is always appreciated as well!

[mumoshu]

Hey @nikola-jokic!

Removing the existing job_workflow_ref in favor of the new job_workflow_name (or call it job_workflow? Although I slightly prefer having _name) and job_workflow_target works if that's what you mean!

To be more precise about high cardinality, I was to omit the existing job_workflow_ref from my listenerMetrics. I.e., users won't suffer from high cardinality as long as they keep their previous listenerMetrics settings as-is. Pls let me know if I'm missing anything 🙏

Moving this forward, how about adding job_wofklow_name and job_workflow_target in this PR, and following up with another PR that removes job_workflow_ref?

That way, we can have some grace period to hear back from the community if we can safely remove job_worfklow_ref.

[Steve-Glass]

Moving this forward, how about adding job_wofklow_name and job_workflow_target in this PR, and following up with another PR that removes job_workflow_ref? That way, we can have some grace period to hear back from the community if we can safely remove job_worfklow_ref.

100% agree with this approach. Lets add it to the 0.13.0 release. We will maintain job_workflow_ref until the 0.14.0 release 😄

[nikola-jokic]

Thank you!