docs: regenerate relay.leaf after the README gained the site link #188

Merged
paulhitt merged 1 commits from fix/regenerate-relay-doc-page into main 2026-09-10 12:35:52 +00:00
paulhitt commented 2026-09-10 12:20:13 +00:00 (Migrated from gitlab.com)

Why

doc-pages has been red on main since 9 Sep, which per the CI setup blocks every subsequent MR from going green.

Commit 40d869b ("Link the site from the README") added this to README.md:

It serves https://flamenetmessenger.com, so a fresh install explains itself rather than greeting you with an error.

The generator was never re-run, so relay.leaf kept the stale source-sha256 and that sentence never reached the page. As the check itself puts it: the page is what people read, the markdown is not served.

What changed

Scripts/build-doc-pages.sh re-run, one file, 5 insertions and 1 deletion: the new paragraph plus the source-sha256 marker. Nothing else moved.

Regenerated against the pinned engine, not a local checkout

Worth stating because it changes the result. Running the checker against a local flamenet-e2e reported two stale pages, relay.leaf and engine.leaf. CI reported only relay.leaf.

The difference is that CI checks out the ref pinned in .e2e-ref (57732df8), while a sibling checkout sits on whatever branch it happens to be on. engine.leaf was not stale at all; it was an artifact of comparing against the wrong engine revision. Committing that would have written a page generated from an unreleased source.

So this was built in a worktree pinned to 57732df8, which reproduces CI exactly: one stale page, one file changed.

Verification

$ python3 Scripts/check-doc-pages.py --engine <pinned 57732df8>
9 generated pages match their sources

Exit 0.

## Why `doc-pages` has been red on `main` since 9 Sep, which per the CI setup blocks every subsequent MR from going green. Commit `40d869b` ("Link the site from the README") added this to `README.md`: > It serves <https://flamenetmessenger.com>, so a fresh install explains itself rather than greeting you with an error. The generator was never re-run, so `relay.leaf` kept the stale `source-sha256` and that sentence never reached the page. As the check itself puts it: the page is what people read, the markdown is not served. ## What changed `Scripts/build-doc-pages.sh` re-run, one file, 5 insertions and 1 deletion: the new paragraph plus the `source-sha256` marker. Nothing else moved. ## Regenerated against the pinned engine, not a local checkout Worth stating because it changes the result. Running the checker against a local `flamenet-e2e` reported **two** stale pages, `relay.leaf` and `engine.leaf`. CI reported only `relay.leaf`. The difference is that CI checks out the ref pinned in `.e2e-ref` (`57732df8`), while a sibling checkout sits on whatever branch it happens to be on. `engine.leaf` was not stale at all; it was an artifact of comparing against the wrong engine revision. Committing that would have written a page generated from an unreleased source. So this was built in a worktree pinned to `57732df8`, which reproduces CI exactly: one stale page, one file changed. ## Verification ``` $ python3 Scripts/check-doc-pages.py --engine <pinned 57732df8> 9 generated pages match their sources ``` Exit 0.
paulhitt (Migrated from gitlab.com) merged commit 80c828bbb5 into main 2026-09-10 12:35:53 +00:00
paulhitt commented 2026-09-10 12:35:54 +00:00 (Migrated from gitlab.com)

mentioned in commit 80c828bbb5

mentioned in commit 80c828bbb502a2600aed5d7236fd11652064e90b
Sign in to join this conversation.