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!