Skip to content

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

Closed
mergify[bot] wants to merge 5 commits into
mainfrom
mergify/merge-queue/5b42df45b8
Closed

merge queue: checking #1795 on main (249fbd4), stacked on #1801#1814
mergify[bot] wants to merge 5 commits into
mainfrom
mergify/merge-queue/5b42df45b8

Conversation

@mergify

@mergify mergify Bot commented Sep 7, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

🎉 This pull request has been checked successfully and will be merged soon. 🎉

#1795 is queued for merge on branch main (249fbd4).

Stacked behind 1 pull request queued ahead of this batch, not part of it. These checks run on a tip that also carries its commits, so a failure here can come from it as much as from #1795.

Queued ahead of this batch:

This pull request has been created by Mergify to speculatively check the mergeability of #1795.
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: d007e1b310bacec8dee05e87f7a139a60ea4d149
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 1795
    scopes: []
scopes: []
...

jd and others added 5 commits September 7, 2026 14:08
@jd
docs(live-tests): drop the mirror claims for deleted Python files
7c091c7 
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
@jd @claude
docs(release): add a maintainer skill for cutting a release
d1cc0dc 
`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
@jd
test(live): cover the quarantine add/remove round-trip
4c11a93 
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
Merge of #1801
d007e1b
@mergify
Merge of #1795
2358c5d
@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 mentioned this pull request Sep 7, 2026
Merged
@mergify mergify Bot closed this Sep 7, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/5b42df45b8 branch September 7, 2026 13:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@jd