merge queue: checking #1793 on main (249fbd4), stacked on #1801 and #1795 - #1815
Closed
mergify[bot] wants to merge 7 commits into
Closed
merge queue: checking #1793 on main (249fbd4), stacked on #1801 and #1795#1815mergify[bot] wants to merge 7 commits into
mergify[bot] wants to merge 7 commits into
Conversation
A test name arrives from JUnit unbounded and goes straight onto the wire: `build_traces` copies it into the span name and two attributes. INC-2436 was a Vitest title interpolating stringified React source at 31,207 characters, and nothing between the runner and the backend refused it. Skip a case whose name exceeds 65,536 bytes and report it through the path already built for cases too large to upload: the human report and, on GitHub Actions, a `::warning::` annotation. The CI outcome is untouched, so a skipped result never breaks a customer's build. A suite left with no cases emits no span rather than an empty suite. Skipped rather than truncated on purpose. The backend identifies a test by `uuid_generate_v5` of its name, so a truncated name is a different test: the result would split its history, flakiness and quarantine state in two. Not uploading it says so plainly, and names it so the owner can rename the test. Names are cut to 120 bytes for display in both surfaces, since the name is itself what made the case too large. Fixes MRGFY-8951 Related to MRGFY-8902 Change-Id: I224cd6b770d1228bc0ae884ec546b05a94102e3d
The module header promised this file "deliberately mirrors the Python version 1:1 ... so the port can't drift the contract by accident", and named `func-tests/test_live_smoke.py` and `func-tests/conftest.py` as what it mirrors. Both were deleted when the port completed. Four helpers made the same promise individually (`Mirrors conftest.py::cli`, `Mirrors Python subprocess.run`, `Matches Python result.stdout + result.stderr`, and `live_token`'s "Mirrors Python `live_token` fixture"). AGENTS.md: "There is no Python: the port is complete ... If you find a doc, comment, or rule mentioning [it], it is stale — fix it." The harm is concrete rather than cosmetic: a maintainer auditing which secret each test needs goes looking for the fixture the header says pins that mapping, and there isn't one. The header now states the invariant that actually holds — tests are grouped by credential under a banner, and a test belongs under the banner matching its helper — which is the thing a reader needs and the thing the previous commit had to correct. It also spells `LIVE_TEST_MERGIFY_TOKEN_ADMIN` out rather than abbreviating it to `_ADMIN`, so grepping for either secret finds this file. Left alone: the in-body notes recording which wire contracts were preserved across the Python → Rust port. Those are provenance for why a contract is shaped the way it is, not claims about a file that no longer exists. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JBz3hxMUDCuWftT6qAHtnn Change-Id: Idd9e1e28bfc50b8b71d07c5938b4fa89af2745ff
`RELEASING.md` documents the two-stage flow for a human driving the Actions UI. This adds the agent-facing counterpart: the `gh` commands for each stage, the pre-flight checks, and the guardrails. It lives in `.claude/skills/`, not the published `skills/` tree — that one ships as the `mergify` plugin for CLI users, where a runbook for releasing *this* repo would fire on anyone asking to release their own project. Content beyond what `RELEASING.md` already covers: - Up front: there is no version to bump in any file, so no "release prep" PR. The workflow stamps the tag at build time. - Pre-flight: main is green, no leftover draft, what ships since the last tag. - Stage 2 is irreversible and outward-facing (immutable release, PyPI push), so the skill stops after the draft and requires an explicit go-ahead. Stage 1 is marked safe and repeatable. - Post-publish verification of the Homebrew tap, which was undocumented: the `homebrew-tap-sync` workflow in `Mergifyio/mergify-ci-bot` opens a formula-bump PR against `Mergifyio/homebrew-tap` within ~20 min of publish, and it still needs a human to merge. The why — GitHub's immutable-releases policy and the reason stage 1 runs from `workflow_dispatch` — stays in `RELEASING.md`, which the skill points at, so the two can't drift on the rationale. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RVKnCd4MKakhVJJiJTfZcD Change-Id: I588ca3b86af6143c8440af6cab0b968f80e1a0f7
MRGFY-9001 dropped `ci_application_key` from `POST` and `DELETE` on
`/ci/{owner}/repositories/{repo}/quarantines` at the same time it
dropped it from `search/tests`. Only `search/tests` had a live
test, so only `search/tests` turned red; `mergify tests quarantines
add` and `remove` broke for every `ci` key with no signal at all.
The first two commits of this stack documented that. This closes
it.
The 20-odd wiremock tests in `tests_quarantine.rs` cannot cover
this: a mock server never authenticates, so no scope change is
visible to them. It has to be the live suite or nothing.
Shape follows `freeze_create_update_delete_roundtrip`, the existing
create-and-clean-up test in this file: a `Drop` guard removes the
entry so a failed assertion mid-test still leaves the canary
repository clean, and it warns rather than panics, because
panicking in `Drop` during an unwind aborts the process and buries
the assertion message that explains the failure. The guard is
registered before the response is parsed — an unparseable body
still means the row exists server-side.
Two details specific to quarantines:
- The quarantined name is `__mergify_cli_smoke_quarantine_<rand>__`
and matches nothing any real suite reports, so even a completely
skipped cleanup cannot suppress a genuine failure on the canary
repository. A leaked row is inert.
- Removal goes by name rather than by the id `add` returned, so one
run covers the list read that resolves the name *and* the delete.
The guard tolerates exactly two outcomes: exit 0, when the body
failed before its own remove, and `MergifyApiError` carrying
`not_found`'s `'<name>' is not quarantined`, when the body already
removed the row. Both halves are load-bearing — that exit code is
every Mergify API error including a 403 on a narrowed scope, and
the message on its own would swallow any failure whose text
happened to contain the phrase. It reads the code off
`mergify_core::ExitCode` rather than a literal, so a renumbering
cannot silently widen what cleanup calls success.
The 8-char entropy the freeze test generated inline is now
`unique_suffix()`, shared by both.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Change-Id: I20ed0098fe86acd633ad6864eed035f6e5f47dd1
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.
🎉 This pull request has been checked successfully and will be merged soon. 🎉
#1793 is queued for merge on branch main (249fbd4).
Stacked behind 2 pull requests queued ahead of this batch, not part of it. These checks run on a tip that also carries their commits, so a failure here can come from them as much as from #1793.
Queued ahead of this batch:
This pull request has been created by Mergify to speculatively check the mergeability of #1793.
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]github-review-approved[🛡 GitHub repository ruleset ruleRequire pull request for default branch]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]github-review-approved[🛡 GitHub repository ruleset ruleRequire pull request for default branch]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