Skip to content

merge queue: checking #12717 on main (e8e1d66), stacked on #12648 - #12741

Closed
mergify[bot] wants to merge 4 commits into
mainfrom
mergify/merge-queue/88eff72af1
Closed

merge queue: checking #12717 on main (e8e1d66), stacked on #12648#12741
mergify[bot] wants to merge 4 commits into
mainfrom
mergify/merge-queue/88eff72af1

Conversation

@mergify

@mergify mergify Bot commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

✨ Pull request #12648 ahead in the queue was removed (reason: checks failed). The pull request #12717 has been requeued. ✨

#12717 is queued for merge on branch main (e8e1d66).

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 #12717.

Queued ahead of this batch:

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

jd and others added 4 commits September 8, 2026 14:38
The Pull Request Dependencies section said a `Depends-On:` header could point
at "other repositories with Mergify installed within your organization". The
constraint is the same repository *owner*, which may be a user account rather
than an organization. A reference to another owner is rendered with a
"depends-on conditions must have the same repository owner" warning and never
satisfies.

The section was also silent on what happens to a reference Mergify cannot
resolve — another owner, a repository without Mergify, or a pull request that
does not exist. None of those ever reach the `depends-on` attribute, so the
condition stays unsatisfied and blocks the merge rather than being skipped,
which is the behaviour a reader most needs to be told about.

This brings the page in line with the same rules already documented for the
`depends-on` merge protection in /merge-protections/builtin, which was
corrected and left this page behind.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019V4gXwb2UucysW4xmB7bAw
Change-Id: I790b2c0c6e38ed5eff9ac587378765c72939f264
The migration shim recolored the diagrams without touching them, which was the
point of landing it first — but a table that infers intent from a hex can only
be as good as the colors it reads, and those colors were four dialects that
disagreed. Two datastores came out the same color because both were pastel
greens; "tests passed" and "merged to main" fused because both were greens.
Each fence now says what it means, and the inference goes away.

The 19 fences drop from 713 lines of DOT to 286, because most of what they said
was color. What is left is structure, plus a role per element and a layout kind
per fence — `queue`, `flow` or `arch`, which set direction and spacing and
nothing else. A few things the diagrams had wrong get fixed on the way through,
since the rewrite makes them visible: batches.mdx had a pull request that was
grey rather than queued only because it was declared implicitly by an edge and
so missed the fill every other node got.

The emoji come out of the lifecycle and two-step diagrams. They render
differently on every platform, Graphviz cannot measure them, and they carried no
meaning that the color does not now carry.

`pnpm check:diagram-tokens` is what makes this permanent — the same shape as
`check:internal-leaks`, a deterministic scan wired into CI. Nothing about a
hardcoded color fails a build on its own: the diagram renders, it just renders
wrong on half the site, which is exactly how 63 of them accumulated unnoticed.
It reads inside Graphviz fences only, so a color in prose or a CSS example is
untouched, and it reads the three hand-drawn diagram components end to end,
since those have no fence to scan and are where two of the four dialects lived.

A CI job that nothing waits on is decoration, so `diagram-tokens` joins the
`CheckRuns` anchor in `.mergify.yml` — the list the merge protection, both queue
rules and the review-request rule all share. Note this leaves `actionlint`,
`config-examples` and `internal-leaks` outside that anchor, which they were
before this change; whether they belong there is a separate question from this
diff.

`enterprise/architecture.mdx` keeps its click-to-zoom overlay. The diagram is
945pt now rather than 1736pt, which is what makes it legible at all, but at 80%
of the prose column that still scales its labels to roughly 8px — so the overlay
is still doing something.

Change-Id: I6cfa48c833499804a082a59bf6199236172cdcca
@mergify
mergify Bot deployed to Mergify Merge Protections September 9, 2026 08:13 Active
@mergify mergify Bot closed this Sep 9, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/88eff72af1 branch September 9, 2026 08:16
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.

1 participant