fix(ci-providers): use JOB_CHECK_RUN_ID for GitHub Actions ci.job.id#2307
Merged
Conversation
GitHub Actions exposes the numeric job ID of the running step via the JOB_CHECK_RUN_ID env var. This commit reads it and uses it for both the ci.job.id span tag and the ci.job.url, falling back to the existing log-scraped fallbackGithubJobID when JOB_CHECK_RUN_ID is not set. Also refreshes the ci-env spec fixtures from the canonical DataDog/datadog-ci-spec source — most providers gained a JSON-string form of their PR-number env var, github.json gained the new JOB_CHECK_RUN_ID field plus updated ci.job.id / ci.job.url expectations, and buildkite.json's ci.node.labels expectation now matches insertion order (which is what the implementation already produces). Verified: CI='' yarn test -t 'ci spec' → 321 passed, 0 failed. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
anmarchenko
added
the
software-delivery
🎉 All green!❄️ No new flaky tests detected 🔗 Commit SHA: 5c79f40 | Docs | Datadog PR Page | Give us feedback! |
The `getCIMetadata` spec test did a strict deep-equal on the whole tags object, which made it sensitive to label ordering inside the `ci.node.labels` JSON array — even though the fixtures are auto-generated and ordering is not part of the contract. Apply the same destructure + `arrayContaining` pattern already used by the sibling "reads env info for spec" suite so both tests handle the auto-generated fixtures consistently. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
juan-fernandez
approved these changes
May 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why?
The
ci-envspec fixtures bundled inpackages/base/src/helpers/__tests__/ci-env/had drifted from the canonical datadog-ci-spec source. Notably:github.jsonlost theJOB_CHECK_RUN_IDenv var. The canonical spec mapsJOB_CHECK_RUN_ID(which GitHub Actions injects with the numeric job ID of the running step) to theci.job.idspan tag, and uses it to build aci.job.urlof the form<server>/<repo>/actions/runs/<run_id>/job/<job_id>— instead of the older<server>/<repo>/commit/<sha>/checksfallback.*_PR_NUMBERenv var stored as a JSON int instead of a string (the test harness coerces both to strings, so this was cosmetic but worth refreshing).buildkite.json'sci.node.labelsorder was refreshed from the canonical spec; the implementation emits labels in env-insertion order, which doesn't match the spec's order. Rather than coupling the test to either ordering, thegetCIMetadataspec test now comparesci.node.labelsorder-independently (matching the existing pattern in the sibling "reads env info for spec" suite).The
datadog-ci-specCI job for this repo doesn't catch the drift because itsMakefilecopies generated fixtures intogenerated/datadog-ci/src/helpers/__tests__/ci-env/, a path that no longer exists after the monorepo restructure topackages/base/.... So the override silently no-ops and the bundled (stale) fixtures are what get tested.How?
packages/base/src/helpers/ci.ts): addedJOB_CHECK_RUN_IDto the GitHub env destructure and introducedgithubJobID = JOB_CHECK_RUN_ID ?? fallbackGithubJobID. Bothci.job.idandci.job.urlnow consumegithubJobID, so theactions/runs/<run_id>/job/<job_id>URL is built whenever the runtime exposes the job ID — without relying on the log-scraping fallback.datadog-ci-specYAMLs.packages/base/src/helpers/__tests__/ci.test.ts): thegetCIMetadataspec test now destructuresCI_ENV_VARSandCI_NODE_LABELSout of the comparison and checks them viaJSON.parse+arrayContaining, so the test tolerates ordering differences in auto-generated fixtures. This mirrors the pattern already used by the sibling "reads env info for spec" suite.CI='' yarn test -t 'ci spec'→ 321 passed, 0 failed.Note on Windows e2e (Node 24) failure
The "End-to-end test the package (Windows) (24)" check fails on this PR with
Error: EBADF: bad file descriptor, fstatinside Node's ESM loader (node:fs:391→getSourceSync→createCJSModuleWrap). This is a Node.js 24.15.0 upstream regression (see nodejs/corepack#813, yarnpkg/berry#7065), unrelated to anything this PR changes — the crash fires while loadingjest.config-e2e.mjs, before any of our code runs. Master's last successful run used Nodev24.14.1; this PR's run picked up the freshly-releasedv24.15.0. The CI fix is being tracked in #2306, which pins/works around the Node 24 issue.Review checklist
ci specsuite, which now exercises theJOB_CHECK_RUN_IDpath via the refreshedgithub.jsonfixture.🤖 Generated with Claude Code