rob thijssen ef8521b9fb fix(ci): prerender the web bundle after the api/worker deploy, not beside it ...

`build-web` had no `needs:`, so it ran in parallel with the binary build
and both deploy jobs. The prerender fetches VITE_API_BASE at build time,
which means the job baked whatever the api happened to be serving at the
moment it ran — old binary or new, depending on which runner finished
first.

Both outcomes showed up on consecutive runs. Run 68 won by ~25 seconds
and the repo-visibility fix reached the api and the crawler snapshot
together. Run 69 lost: the api served the new activity/summary private
aggregate while the baked /activity/ snapshot had none, so the 15 August
card read "47 changes in 3 repositories" where the api said 54 with 7
private. Browsers hydrate and refetch, so a visitor saw the right page —
but curl, which is what crawlers and AI screeners get, saw the stale one
until refresh.yml was dispatched by hand. Nothing in the pipeline noticed.

deploy-worker is in the needs list alongside deploy-api because the
worker owns migrations: a schema change isn't live until it has
restarted, so an api that depends on one isn't answering correctly before
then either.

The graph is now serial — binaries -> api/worker -> web — which costs the
overlap between the web build and the binary build. Worth it: the
alternative is a published snapshot whose correctness depends on runner
scheduling, failing silently and for a whole day.

Job graph verified acyclic with every `needs:` resolving to a real job.

Closes #8

2026-08-17 12:58:17 +03:00

18 KiB

Raw Blame History

View Raw