Skip to content

merge queue: checking #12647 on main (7f718b5), stacked on #12673 and #12595 - #12682

Closed
mergify[bot] wants to merge 8 commits into
mainfrom
mergify/merge-queue/ba4023f2d1
Closed

merge queue: checking #12647 on main (7f718b5), stacked on #12673 and #12595#12682
mergify[bot] wants to merge 8 commits into
mainfrom
mergify/merge-queue/ba4023f2d1

Conversation

@mergify

@mergify mergify Bot commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

✨ Pull request #12595 ahead in the queue was removed (reason: checks timeout). The pull request #12647 has been requeued. ✨

#12647 is queued for merge on branch main (7f718b5).

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

Queued ahead of this batch:

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

jd and others added 8 commits August 28, 2026 17:08
`getOgImageUrl` strips the leading and trailing slashes off the pathname to
build the image filename. For the homepage that pathname is `/`, so stripping
left an empty string and the lookup missed — every docs page had an OpenGraph
image and the homepage shipped `<meta property="og:image">` with no content.

The homepage's collection id is `index`, which is what `getStaticPaths` names
its image, so fall back to that when the slug comes out empty.

Covered by a regression test that fails against the old expression. The
generated-image set comes from the content collection and needs the Astro build
pipeline, so the test stubs it and exercises the derivation, which is the half
that was wrong.

Change-Id: Ifb9a23ea2caa20d28489a4f21363d85ed5e3342c
Docset cards rendered their title as `h4`. Almost every grid sits directly
under an `##`, so the outline jumped h2 to h4 — including on the homepage,
whose whole body is the "Products" grid. Screen readers and anything parsing
the document outline read that as a missing level.

Default the card heading to `h3` and make it a prop, because one grid does
belong at h4: the "Components" grid in `ci-insights.mdx` is nested under an
`### Components`, where h3 would make the cards siblings of their own section
heading instead of children.

Change-Id: Ie01f4c2b03f1f2b7f798ae89b056135a5b00800e
The Mergify OpenAPI 3.1 document is already deployed — it is what the API
Reference pages are generated from — but only at `/api-schemas.json`, a
filename that exists nowhere outside this repository. Every OpenAPI client,
SDK generator and crawler probes `/openapi.json`, so nothing finds it and the
docs read as a site with no API at all.

Serve the same bytes at `/openapi.json`. The route does not transform the
document: the spec is synced from the engine repository, and two spellings of
it that could disagree would be worse than one obscure path.

Alongside it, three other entry points that were undiscoverable:

- `<link rel="service-desc">` in every page head, the IANA relation for "the
  description of this site's API" (RFC 8631), plus one for `llms.txt`.
- `robots.txt` had no `Sitemap:` line, so crawlers had to guess
  `sitemap-index.xml` rather than be told.
- `/developers` is the path people and tools guess for a developer portal and
  was a 404; it now redirects to the API reference.

Change-Id: I1b625f960363c8427d5282c052fee74111bf07fa
`<GitGraph>` was a second Graphviz pipeline running beside the `dot` fences,
with its own `COLORS` map, its own `EDGE_COLOR`, and its own string-replace for
dark mode. `<StackMapping>` was a third, with five more hex literals. Three
surfaces, three private palettes, all drifting apart — which is how a page like
merge-queue/stacks ends up rendering a themed diagram and a baked one side by
side.

All three now name roles. `src/util/diagramSvg.ts` holds the post-processing
both Graphviz surfaces share — drop the canvas, strip the inline paint, mark a
borderless shape as a caption — so there is one place to change and no second
list of hex strings to fall out of date. The hand-placed SVG in GitGraph's
linear mode and in StackMapping emits the same `node` / `edge` groups and the
same role classes, so `.dg` paints all four kinds of diagram from one
stylesheet. `--theme-diagram-edge` is deleted: it was the old surfaces' single
diagram token and `--dg-a-chrome` now says the same thing.

This also fixes the bug that made the case for it. GitGraph marks every node
`style=filled`, which reaches a `shape=plaintext` node too, so the `main`
branch label sat on an opaque pale box — barely noticeable in light mode and
glaring in dark, on seven pages. It is a caption, so it now carries `plain` and
the box is gone.

Two things changed while I was in there:

- `<StackMapping>` sizes its columns to their content. They were fixed at
  160px and the generated branch names did not fit; the overflow was invisible
  while the label was white on a solid fill, and would have been plainly
  visible once the label became dark text on a tint.
- Graph-mode commit graphs are typeset at the same sizes as the fences (13/10
  rather than Graphviz's default 14 and a hand-set 9), so the two kinds of
  diagram on one page no longer disagree about how big a label is.

A call site names a role rather than a color: `color: "green"` becomes
`role: "queued"`, `commitColor="green"` becomes `commitRole="queued"`. The
prop is typed as `DiagramRole`, so a color name no longer compiles.

Change-Id: I6bdb5b9fbd6574a37172fa067e81b0103282725f
The six images under /enterprise/ all landed in one commit on 2025-12-10 and
none has been touched since. This replaces the two that are furthest from what
the installer looks like now, and fixes the one paragraph the reshoot proved
wrong.

The installer was redesigned — lowercase wordmark, light ground, black buttons —
and step 1 gained a GitHub Server URL field. The prose already described that
field; only the screenshot predated it. Both shots are retina 2x, captured off
the installer the on-premise image actually serves: the engine monorepo's
installer directory, built the way its Dockerfile builds it and served the way
the entrypoint serves it, a plain static server over the build output.

Step 2 downloads mergify.env on its own as soon as the App is created. The page
said "Download the generated mergify.env, then click Install", which reads as a
manual step. It now says what the installer does, what the file is for, and
which button to use when a browser blocks the download.

Four screenshots are not here yet: the two GitHub pages in the creation flow,
the installer's own step 2, and the webhook deliveries view on the
troubleshooting page. GitHub rejects an App manifest whose hook URL is not
reachable over the public Internet, so none of those states can be reached
without a public HTTPS origin serving the installer.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014f8ta8pKiB2g5TnS6PLTBY
Change-Id: I3ab9cba7a25e46f282c0f74d7a604a03e3b929cc
@mergify
mergify Bot deployed to Mergify Merge Protections September 4, 2026 09:36 Active
@mergify mergify Bot closed this Sep 4, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/ba4023f2d1 branch September 4, 2026 09:47
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