Seven minutes of checks, three at a time
One CI job ran ten checks in a row under a 30 minute timeout. Split in three, with Lighthouse in four shards, a push comes back in about two and a half.
One job ran claims, readme, types, lint, build, HTML, links, end-to-end and Lighthouse one after the other, then the worker. Typical runs took five to seven and a half minutes, and the pull request that added the claims file took fifteen. The job had a 30 minute timeout, which was the only sign anyone expected it to be slow.
It is now three jobs. The static checks in one, with a ten minute timeout: claims, readme, types, lint, worker. Build, HTML, links and end-to-end in another. Lighthouse in a matrix of four, each shard auditing the URLs whose index mod 4 is its number, four pages at three runs each on a 412 by 823 mobile viewport, fail-fast off, one artifact per shard. A concurrency group cancels the previous commit’s run when a new one pushes. The 6.6 MB of photos under the assets folder are optimized on every build, so the build cache is keyed on a hash of that folder and the lockfile, and shared by the site, Lighthouse and deploy jobs.
Runs now take two to four minutes. The one on 21 October: static in 55 seconds, the shards in 54 to 79, the site job in 2:41. The docs site got the same shape with two shards, and went from about two and a half minutes to under one and three quarters.
The docs commit says it caches optimized images too. The docs site has no images folder and no cache step. The title was copied with the workflow.