merge queue: checking main (a32dfe1), #1723 and #1722 together#1728
Closed
mergify[bot] wants to merge 4 commits into
Closed
merge queue: checking main (a32dfe1), #1723 and #1722 together#1728mergify[bot] wants to merge 4 commits into
mergify[bot] wants to merge 4 commits into
Conversation
`mergify ci junit-process` builds every parsed JUnit report into one OTLP `ExportTraceServiceRequest`, gzips it, and POSTs it in a single request. A large report (tens of thousands of cases, or a few with huge stack traces) can gzip past what the ingest endpoint accepts, and the whole upload is lost. Cap the compressed body at a named constant `MAX_GZIPPED_UPLOAD_BYTES` (10 MiB) and split an oversized payload into several uploads that each gzip under the cap. The cap is on the *gzipped* bytes actually sent, not the raw XML or the uncompressed protobuf: gzip ratios swing wildly between a run of short case names and one of megabyte stack traces, so only the compressed size is meaningful. A normal report stays a single upload, byte-identical to before. How the split works (new `junit_process::split`): - Decompose the built request into its session / suite / case spans, then recursively halve the case list — by encoded size, so one giant case is isolated fast — verifying each candidate chunk with an actual gzip. - Each chunk is a self-contained trace: the session span, the suite spans for the cases it carries, and those cases. Every chunk keeps the original trace_id and span_ids, so the backend reassembles one trace from N uploads. - Each chunk carries the gzipped bytes it was sized against, so the upload step posts them directly instead of compressing a second time. Oversize single case (one test whose trace alone exceeds the cap gzipped): skip-and-warn. There is no upload it can fit into, so it is dropped and listed in the report under "Some test results were too large to upload". The CI verdict is unaffected — it is computed from the parsed cases, not the upload — so no test's blocking status is lost, only its telemetry. Upload semantics: a transient failure on one chunk does not abandon the rest (each chunk is a self-contained, idempotent trace, so delivering as many as possible is best), but a permanent rejection stops the loop. When nothing reaches ingest (every case oversized, or gzip fails) the run reports test_results_upload=failed rather than a false success, and dropped oversize cases emit a GitHub Actions warning naming them. Backend support: the split relies on the ingest endpoint accepting several same-test_run_id uploads and merging them additively/idempotently by (trace_id, span_id). That landed in monorepo #36926 (MRGFY-8051); without it the backend would drop every chunk after the first. This CLI change is inert until that backend is deployed. Fixes MRGFY-8050 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Change-Id: Iacd21260a73b5e249e32a88f931cd95a7a8ff57a
…y renames `queue_metadata::parse_yaml_block` modeled the MQ draft-PR-body payload with a rigid serde struct whose `draft_pr_number` was required. The engine (MRGFY-8075) renamed that key to `batch_pr_number` and dual-emits both for one release window before dropping the old spelling. A missing required field fails the *whole document*, and the caller's `.ok()` swallows that into `None`, so once the alias is gone every batch body with a non-empty `previous_failed_batches` would silently cost `git-refs` its `checking_base_sha` and diff against the wrong base, with no error surfaced anywhere. That struct has been dead code since #1600: its only reader, `git_refs`, uses just `checking_base_sha`; every other field is parsed and discarded. So rather than a `#[serde(alias)]` band-aid on one key, parse the payload into a generic `serde_json::Value` — exactly how the git-note twin (`git::read_note`) already reads the identical payload — and pull `checking_base_sha` out with the existing shared helper. The CLI is now immune to any engine key rename in this block, with no schema left to drift and no call-site churn. While here: warn instead of silently falling through to the PR base when MQ metadata is present but carries no `checking_base_sha`, so a future rename of that key can't degrade the base silently either; and share the YAML-mapping parse between the note and PR-body readers so they can't diverge in what they accept. Fixes MRGFY-8104 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Change-Id: I6732b7057db0c98a7bb275d95fbd6470e39bad8b
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
1 participant
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.
🎉 This pull request has been checked successfully and will be merged soon. 🎉
Branch main (a32dfe1), #1723 and #1722 are queued together for merge.
This pull request has been created by Mergify to speculatively check the mergeability of #1722.
You don't need to do anything. Mergify will close this pull request automatically when it is complete.
Required conditions of queue rule
defaultfor merge:github-review-approved[🛡 GitHub branch protection] (documentation)github-review-approved[🛡 GitHub repository ruleset ruleRequire pull request for default branch] (documentation)Enforce conventional commit]:title ~= ^(fix|feat|internal|docs|style|refactor|perf|test|build|ci|chore|revert|ui)(?:\(.+\))?!?:👀 Review Requirements]:#approved-reviews-by>=2author = dependabot[bot]author = mergify-ci-botauthor = renovate[bot]📕 PR description]:body ~= (?ms:.{48,})🔎 Reviews]:#changes-requested-reviews-by = 0#review-requested = 0#review-threads-unresolved = 0🤖 Continuous Integration]:check-success=ci-gateRequired conditions to stay in the queue:
base=maingithub-review-approved[🛡 GitHub branch protection] (documentation)github-review-approved[🛡 GitHub repository ruleset ruleRequire pull request for default branch] (documentation)label!=manual mergeEnforce conventional commit]:title ~= ^(fix|feat|internal|docs|style|refactor|perf|test|build|ci|chore|revert|ui)(?:\(.+\))?!?:👀 Review Requirements]:#approved-reviews-by>=2author = dependabot[bot]author = mergify-ci-botauthor = renovate[bot]📕 PR description]:body ~= (?ms:.{48,})🔎 Reviews]:#changes-requested-reviews-by = 0#review-requested = 0#review-threads-unresolved = 0🤖 Continuous Integration]:check-success=ci-gate