Add job_workflow_repo and job_workflow_path metric labels

[ben181231]

(NOTE: This pull request is created by Claude Code via GitHub MCP)

WHAT

Adds two new labels to all job-related listener metrics, parsed from job_workflow_ref:

• job_workflow_repo: the {owner}/{repo} hosting the workflow file (e.g. myorg/myrepo)
• job_workflow_path: the workflow file path within that repository (e.g. .github/workflows/ci.yml)

Changes:

• WorkflowRefInfo gains Repo and FilePath fields, populated by ParseWorkflowRef
• jobLabels() exposes them as job_workflow_repo / job_workflow_path
• Unit and integration tests updated to cover the new fields
• Helm chart values.yaml documentation examples updated for both charts

WHY

#4240 introduced job_workflow_name and job_workflow_target as lower-cardinality alternatives to job_workflow_ref, with the intent of eventually deprecating job_workflow_ref.

However, job_workflow_name alone drops information that only exists in job_workflow_ref today:

• For reusable workflows — where a workflow in one repository is called by jobs in other repositories via {owner}/{repo}/.github/workflows/{filename}@{ref} — the repository hosting the workflow file can differ from the repository running the job (the repository/organization labels describe the caller, not the workflow host). Once job_workflow_ref is removed, the workflow's host repository would be unrecoverable.
• Two different workflows named e.g. ci.yml in different repositories (or in different paths) would collapse into the same job_workflow_name="ci" series.

job_workflow_repo and job_workflow_path preserve that information in structured, individually selectable labels, so users can opt into exactly the granularity they need via listenerMetrics without keeping the full high-cardinality job_workflow_ref.

RELATED

• GitHub Actions documentation on cross-repository reusable workflows: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows

[Copilot]

Pull request overview

This PR enhances the listener’s job-related Prometheus metrics by adding two optional, structured labels derived from job_workflow_ref—the hosting workflow repository and the workflow file path—so users can retain important workflow identity details without relying on the higher-cardinality job_workflow_ref.

Changes:

• Extend WorkflowRefInfo and ParseWorkflowRef to extract job_workflow_repo ({owner}/{repo}) and job_workflow_path (workflow file path within that repo).
• Expose the new fields via jobLabels() so all job-related metrics can include them when configured.
• Update unit/integration tests and Helm chart values.yaml examples to cover/document the new labels.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
cmd/ghalistener/metrics/workflow_ref_parser.go	Parse and expose hosting repo + workflow file path from job_workflow_ref.
cmd/ghalistener/metrics/workflow_ref_parser_test.go	Add assertions for parsed repo/path alongside name/target across test cases.
cmd/ghalistener/metrics/metrics.go	Add new label keys and include them in job label generation.
cmd/ghalistener/metrics/metrics_integration_test.go	Validate emitted label maps include the new workflow repo/path labels.
charts/gha-runner-scale-set/values.yaml	Document new labels in listener metrics configuration examples.
charts/gha-runner-scale-set-experimental/values.yaml	Document new labels in listener metrics configuration examples (experimental chart).

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.