[SDCI-1994] Use RUNNER_TEMP to retrieve job name in measure command

[afontan]

Fix GitHub (GHES / self-hosted) job name extraction for measure --level job

Problem

Users running datadog-ci measure --level job on GitHub Enterprise Server / self-hosted runners can see:

• could not find GitHub diagnostic log files

This prevents the command from automatically determining the job display name (the UI name), which is used for correlation when GITHUB_JOB is not the display name (e.g. job name: overrides, matrix jobs).

Root cause

For GitHub Actions job-level metrics, we attempt to infer the real job display name by reading the runner diagnostic logs and extracting the "jobDisplayName" field.

The previous implementation only searched a small list of hardcoded _diag paths (primarily GitHub SaaS defaults like /home/runner/actions-runner/.../_diag). On GHES/self-hosted runners, the runner installation directory is frequently different, so the code never sees Worker_*.log and emits the warning.

Solution (what changed)

• Derive diagnostic log directories from RUNNER_TEMP:
  • RUNNER_TEMP typically points to <runnerRoot>/_work/_temp, so we can derive <runnerRoot>/_diag (and <runnerRoot>/cached/_diag) without assuming a fixed install path.
  • We still keep the old hardcoded directories as fallbacks.
• Improve warning message when no logs are found:
  • Include the directories that were attempted to speed up troubleshooting.
• Add unit test covering the RUNNER_TEMP-derived _diag path.

Testing

• Added a unit test that fails on the old implementation and passes with this change:
  • Sets RUNNER_TEMP to a non-standard runner root and verifies Worker_*.log is discovered via the derived _diag path.

Note: I wasn’t able to execute the full Jest suite locally in this environment due to missing Yarn install state / dependencies, but the change is isolated and covered by targeted unit tests.

Why this matters / expected impact

This improves GitHub job-level metric correlation for:

• GHES deployments
• self-hosted runners installed outside /home/runner/... or /opt/...

It does not change behavior when:

• DD_GITHUB_JOB_NAME is already set (we skip inference)
• the runner remains in the previous hardcoded locations

Sources used

Internal code (this repo)

• packages/datadog-ci/src/commands/measure/measure.ts (where getGithubJobNameFromLogs() is invoked for --level job)
• packages/base/src/helpers/ci.ts:
  • getGithubJobNameFromLogs() (diagnostic log discovery + parsing)
  • githubWellKnownDiagnosticDirsUnix / githubWellKnownDiagnosticDirsWin
  • shouldGetGithubJobDisplayName()
• packages/base/src/helpers/__tests__/ci.test.ts (existing tests + new test for RUNNER_TEMP derivation)

External documentation

• GitHub Docs: self-hosted runner diagnostics and troubleshooting (location/availability of runner diagnostic logs):
  https://docs.github.com/en/actions/how-tos/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners?learn=hosting_your_own_runners&learnProduct=actions&platform=windows

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)

[datadog-official]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 5b17abe | Docs | Datadog PR Page | Was this helpful? Give us feedback!}