Skip to content

merge queue: checking #1793 on main (249fbd4), stacked on #1801 and #1795 - #1815

Closed
mergify[bot] wants to merge 7 commits into
mainfrom
mergify/merge-queue/dd1f8c0eb0
Closed

merge queue: checking #1793 on main (249fbd4), stacked on #1801 and #1795#1815
mergify[bot] wants to merge 7 commits into
mainfrom
mergify/merge-queue/dd1f8c0eb0

Conversation

@mergify

@mergify mergify Bot commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

🎉 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 default for merge:

Required conditions to stay in the queue:

---
checking_base_sha: c8c3b67b598d20bed0a60e0c71cdacaa14e95115
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 1793
    scopes: []
scopes: []
...

sileht and others added 7 commits September 4, 2026 12:12
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
@mergify
mergify Bot deployed to Mergify Merge Protections September 7, 2026 13:49 Active
@mergify
mergify Bot deployed to func-tests-live September 7, 2026 13:49 Active
@mergify mergify Bot closed this Sep 7, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/dd1f8c0eb0 branch September 7, 2026 13:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants