feat(listener): add workflow name/repo/path to default job counter labels

[ben181231]

Note

This PR was drafted with the assistance of an AI agent (Claude Code).

WHAT

Add the workflow-identifying labels to the listener's default metrics config for the two job counters:

• gha_started_jobs_total
• gha_completed_jobs_total

Labels added to both defaults:

• job_workflow_name — workflow file name without extension
• job_workflow_repo — {owner}/{repo} hosting the workflow file (from feat(listener): add job_workflow_repo and job_workflow_path metric labels #31)
• job_workflow_path — workflow file path within that repository (from feat(listener): add job_workflow_repo and job_workflow_path metric labels #31)

Also adds TestDefaultMetricsJobCounterLabels to pin the expected default label sets.

WHY

We want to relate GitHub Actions workflows to job load on our runner clusters via the exported metrics. The listener already parses job_workflow_ref (workflow_ref_parser.go) and populates the workflow labels in jobLabels() — but they are not part of the default label set, so today they are only emitted when every runner scale set overrides listenerMetrics explicitly. Since listenerMetrics replaces (rather than merges with) the defaults, that means duplicating the entire default metric set across every scale set's values just to add these labels. Putting them into defaultMetrics removes that maintenance burden and lets scale sets go back to relying on defaults.

Scope/cardinality notes:

• job_workflow_name alone is ambiguous: two workflows with the same file name collapse into one series, and for reusable workflows the repository/organization labels describe the caller, not the workflow host. job_workflow_repo + job_workflow_path (added in feat(listener): add job_workflow_repo and job_workflow_path metric labels #31) disambiguate this with bounded cardinality.
• job_workflow_ref/job_workflow_target are deliberately not added — they embed branch refs, which makes their cardinality unbounded (a concern for metrics backends that bill or degrade on high-cardinality custom metrics).
• Counters only; the duration histograms are left unchanged to avoid bucket-multiplied cardinality.
• GitHub upstream never added workflow labels to defaultMetrics (Add job_workflow_ref label to listener metrics actions/actions-runner-controller#4054 / Add workflow name and target labels actions/actions-runner-controller#4240 only added the parsing and values.yaml examples), so this is a deliberate fork-default divergence.
• The chart's values.yaml commented example already lists the workflow labels, so no chart change is needed.

RELATED

• Builds on feat(listener): add job_workflow_repo and job_workflow_path metric labels #31 (merged): adds job_workflow_repo / job_workflow_path parsing and labels
• Upstream reference: Add job_workflow_ref label to listener metrics actions/actions-runner-controller#4054, Add workflow name and target labels actions/actions-runner-controller#4240, Add job_workflow_repo and job_workflow_path metric labels actions/actions-runner-controller#4606
• Fork pattern: Add job_queue_duration_seconds metric #19

[pgreze]

Reviewed both #31 and this PR. The approach — patching the fork's defaultMetrics instead of enumerating listenerMetrics in values files — is the right one, and the code is correct and well-tested. But two of the three new labels don't earn their place:

• job_workflow_path — redundant, please drop it. GitHub requires workflow files to live directly in .github/workflows/ (no subdirectories), so the path is always .github/workflows/{job_workflow_name}.yml|.yaml. The only information it adds over job_workflow_name is the .yml vs .yaml extension, which is worthless in a dashboard.

• job_workflow_repo — new information only for reusable workflows (where the host repo differs from the caller's repository label); for every normal workflow it equals repository. (repository, job_workflow_name) already gives a unique series per caller-workflow pair, which covers the load-attribution goal. Keep it only if we actually want to aggregate by reusable-workflow host (e.g. "how much runner time does an org-wide reusable-deploy.yml consume across all callers") — defensible, but if not, drop it too.

• job_workflow_name — keep. Not derivable from any existing default label; this is the whole point.

Practical consequence: dropping both makes #31 entirely unnecessary — the listener already parses job_workflow_name (upstream actions#4240 is in master), so this PR shrinks to adding labelKeyJobWorkflowName to the two counters' defaultMetrics (~6 lines, no parser changes). If we keep job_workflow_repo, #31 is still needed but should have FilePath stripped.

(Posted by Claude Code, reviewed by pgreze)