fix(ci): prefer GitHub Actions PR-event head SHA over GITHUB_SHA#1469
Conversation
This was referenced May 27, 2026
This was referenced May 27, 2026
Member
Author
|
This pull request is part of a Mergify stack:
|
This was referenced May 27, 2026
Contributor
Merge ProtectionsYour pull request matches the following merge protections and will not be merged until they are valid. 🔴 ⛓️ Depends-On RequirementsWaiting for
This rule is failing.Requirement based on the presence of
🔴 👀 Review RequirementsWaiting for
This rule is failing.
🔴 🔎 ReviewsWaiting for
This rule is failing.
🟢 🤖 Continuous IntegrationWonderful, this rule succeeded.
🟢 Enforce conventional commitWonderful, this rule succeeded.Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 📕 PR descriptionWonderful, this rule succeeded.
|
57bb83b to
bd85763
Compare
73d824f to
53e9e75
Compare
Member
Author
Revision history
|
53e9e75 to
eb452fa
Compare
bd85763 to
c994e93
Compare
eb452fa to
ab01533
Compare
8460659 to
de0921a
Compare
ab01533 to
dbb0765
Compare
dbb0765 to
edcef26
Compare
a823367 to
7a63271
Compare
edcef26 to
1573dd6
Compare
Second layer of the `mergify ci junit-process` port — turn the parsed `TestCase` values into an OTLP `ExportTraceServiceRequest` and ship it to `/v1/repos/<owner>/<repo>/ci/traces` as gzipped protobuf. Two new modules under `junit_process`: - `spans` builds one session span per upload, one suite span per `<testsuite>`, and one case span per `<testcase>`, all sharing a resource that carries the CI-env attributes the backend uses for routing (provider, pipeline run id, branch, head SHA, …). The test cases pin parent/child wiring, status-code mapping, attribute propagation, and resource scraping by feeding a deterministic RNG into a hidden seam. - `upload` POSTs the request with the same headers the Python `OTLPSpanExporter` sends (`Bearer` auth, `application/x-protobuf`, `Content-Encoding: gzip`) and matches the error wording so any log scrapers tracking Python output keep working. Wiremock covers the happy path, the empty-request short-circuit, and the 401 error surface. The detector grows the resource-attribute lookups Python emits (pipeline name, job name, run id/attempt/url, head/base ref, head SHA, repository URL, runner name) — sync env reads only, matching the Python sync path. The PR-event-aware async SHA fallback stays on the Python side for now and lands with the CLI dispatch in Phase C. `opentelemetry-proto` is the only otel dep we pull in, gated to `gen-tonic-messages + trace` so it boils down to the prost generated types plus the trace proto module — no tonic, no otel SDK, no exporter runtime. Compression is `flate2` and the HTTP layer reuses the existing workspace `reqwest` to keep the TLS / rustls flavour consistent. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Change-Id: Icbc727166711d76678877aa172ca47c2dcc07ebc
Third and final layer of the port: the orchestration that wires
the JUnit parser, OTLP encoder, uploader, and a new quarantine
API client together, plus the native clap dispatch that retires
the Python shim for this subcommand.
Two new modules under `junit_process`:
- `quarantine` POSTs failing test names to
`/v1/ci/<owner>/repositories/<repo>/quarantines/check` and
splits the response into quarantined / non-quarantined buckets.
The categorize step counts unknown names as non-quarantined to
match Python (an API that silently drops a name still blocks
the corresponding failure).
- `command::run` orchestrates the per-invocation flow: resolve
the token / repo / target branch (falling back to the CI-env
detector for the latter two), expand `**`/`*`/`?` patterns into
paths, parse every file, hit the quarantine endpoint, feed the
quarantined set into the OTLP builder so each case span gets
the right `cicd.test.quarantined` value at build time, upload
the gzipped protobuf, and render the report. Network failures
on quarantine or upload are non-fatal — the report calls them
out and the verdict still fires based on
`failing_tests_not_quarantined_count`.
The dispatch layer in `main.rs` promotes
`Subcommands::Ci(CiSubcommand::JunitProcess)` from
`ShimmedArgs` to a full clap variant, adds the
`("ci", "junit-process")` entry to `NATIVE_COMMANDS`, and routes
through `mergify_ci::junit_process::run`. `ci junit-upload`
(deprecated) keeps its shim.
The detector gains `get_tests_target_branch` (base ref OR head
ref) so the orchestrator can derive the branch the quarantine API
should look up tests on without round-tripping through Python.
Output is byte-for-byte the same as the Python implementation's
`process_junit_files` — same separators, same emoji, same
`Run ID`/`Exit code` lines, same `┌ … │ … └─` box-drawn failure
blocks. End-to-end smoke against the live `junit_fail.xml`
fixture exits 1 on a non-quarantined failure and 0 on an
all-pass run, matching Python's contract.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Change-Id: I6bd59de407ddcd4196bdd7e7b8ddb4a88885af7a
…ed alias `junit-upload` is the deprecated alias for `junit-process` — Python's `mergify_cli/ci/cli.py` declares it with click's `deprecated="Use \`junit-process\` instead"` decorator and delegates straight to the same `process_junit_files` body. The shim was still routing it through Python only because the orchestrator wasn't native yet; now that Phase C landed, we can collapse it down to a clap variant that reuses `JunitProcessCliArgs` and dispatches to `mergify_ci::junit_process::run` after printing a `DeprecationWarning: …` line to stderr (matches click's behavior on first invocation). This retires the last `ci` shim — `prepend_two` lost its only remaining caller and goes with it. `stack` is now the only shimmed top-level group left. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Change-Id: Ic316f55c5d8a834cefa5d30ffbf5ebabec0a4122
On GitHub Actions `pull_request` builds, `GITHUB_SHA` points at the synthetic merge commit GitHub creates by pre-merging the PR head into the base — not the actual code the tests ran against. The contributor's real head SHA lives in the event payload at `pull_request.head.sha`, and that's the value Mergify dashboards correlate with. Without this fix, every `ci junit-process` run on a PR was uploading the wrong `vcs.ref.head.revision` resource attribute. `get_github_actions_head_sha` now reads `GITHUB_EVENT_PATH`, looks for `pull_request.head.sha`, and falls back to `GITHUB_SHA` if the payload is missing, malformed, or the build isn't a `pull_request` event — matching Python's `get_github_actions_head_sha`. The PR-event JSON read is shared across the pull-request-number lookup (existing) and the head-SHA lookup (new); the number lookup stays strict about parse errors because it's load-bearing for `scopes-send` dispatch, while the SHA lookup stays lenient because `GITHUB_SHA` is a sane fallback. Three unit tests pin: payload-wins-over-env, no-PR-field-falls- back-to-env, and missing-event-file-still-uses-env. The CircleCI PR-build API fallback Python implements stays Python-side for now — it requires a GitHub REST API client we don't have on the Rust side yet. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Change-Id: I99912b552f5841c3364c1a84e29a73486d6c083e
1573dd6 to
560ddd8
Compare
7a63271 to
3f9ccca
Compare
3f9ccca to
07fd863
Compare
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
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.
On GitHub Actions
pull_requestbuilds,GITHUB_SHApoints atthe synthetic merge commit GitHub creates by pre-merging the PR
head into the base — not the actual code the tests ran against.
The contributor's real head SHA lives in the event payload at
pull_request.head.sha, and that's the value Mergify dashboardscorrelate with. Without this fix, every
ci junit-processrunon a PR was uploading the wrong
vcs.ref.head.revisionresourceattribute.
get_github_actions_head_shanow readsGITHUB_EVENT_PATH, looks forpull_request.head.sha, and fallsback to
GITHUB_SHAif the payload is missing, malformed, orthe build isn't a
pull_requestevent — matching Python'sget_github_actions_head_sha. The PR-event JSON read is sharedacross the pull-request-number lookup (existing) and the head-SHA
lookup (new); the number lookup stays strict about parse errors
because it's load-bearing for
scopes-senddispatch, while theSHA lookup stays lenient because
GITHUB_SHAis a sane fallback.Three unit tests pin: payload-wins-over-env, no-PR-field-falls-
back-to-env, and missing-event-file-still-uses-env.
The CircleCI PR-build API fallback Python implements stays
Python-side for now — it requires a GitHub REST API client we
don't have on the Rust side yet.
Co-Authored-By: Claude Opus 4.7 noreply@anthropic.com
Depends-On: #1468