Merges deploy themselves.
Code merges used to deploy only after a data change, so on 2 and 3 November 6 of 7 deploys were started by hand. Now every push to main that touches the site's code starts a deploy. When a deploy finishes, a check compares the live site with main and starts another if it is behind. A failed deploy has its failed jobs rerun once; a second failure turns the check red.
One frame for the header and footer.
Every page used to carry its own copy of the header and footer, so a one-word footer change re-rendered and re-uploaded about 760,000 pages, about $3.40 of storage writes each time. Pages are now stored as parts, and the Worker joins them with one shared frame per language. The same footer change now uploads 2 frames, the frame list and the 2 search pages.
Only the pages a change touches.
Each render now records which templates and interface strings every kind of page used. A change to a template, a string or a topic guide renders only the pages that used it: a test edit to the privacy and terms pages planned exactly 4 pages, both pages in both languages. A change to Go code still renders everything. Knowing which pages a Go function reaches would need a call graph, and a miss would leave a stale page online.
Faster renders.
Up to 5,000 pages now render on one runner instead of 24. Each render used to spend 3 to 6 minutes loading the database from data/; it now pulls the database image built from that exact data and starts in about 2 minutes. Re-rendering the About page in both languages took 6 minutes 34 seconds from start to upload. A full render of every page takes about 28 minutes.
Checks in 3 minutes.
Pull request checks ran twice per commit and loaded the whole database four times, 12 to 13 minutes each time. They now run once, without the data, in under 3 minutes. The full database check runs only when the data or the code that builds the database changes.