Rethink CI as a whole: what runs when, how long a merge may wait, and the path to prod

[Devski]

Asked by Dawid on 12.09.2026: CI runs too often and takes too long, and prod is still ahead of
us — so the shape of the pipeline is worth rethinking as a whole rather than shaving a step off
it.

Where it stands today, measured

Measured on 12.09.2026 from the runs of 05–12.09.

• The triggers are already lean. A run starts on a push to main, on a v*.*.* tag, and on
  a pull request; superseded pull-request runs are cancelled (concurrency). Nothing obvious
  is being started for nothing.
• Volume: about 30 CI runs a day.
• Wall clock: 6.2 minutes from the start of a run to the last of the five required
  checks, 6.5 for the whole run. Since 12.09 a merge waits for that, because the ruleset
  requires check, e2e-smoke, e2e-full, image and deploy-config.
• Billable time: ~11.9 minutes a run — e2e-full 3.4, check 2.6, image 2.2,
  e2e-smoke 1.9, deploy-config 1.0, preview 0.6, deploy-dev 0.6.

What a rethink should weigh

1. e2e-full waits for check (needs: [check]), so ~2.6 minutes of the 6.2 are spent
   waiting rather than testing — about 40% of the wait before a merge. e2e-smoke starts at
   once and does not wait. Was the dependency there to avoid spending minutes on a tree that is
   already broken? If so, it buys minutes while the repository is public and they are free, and
   it costs wall clock on every single change.
2. The browsers are installed on every run: playwright install chromium --with-deps in
   both e2e jobs, uncached, while the pnpm store is cached. The same download and the same apt
   step, thirty times a day.
3. The image is built from scratch every time — no layer cache from the registry or from
   the Actions cache.
4. What must run on every push, and what only before a merge or a deployment. Today every
   push to a pull request runs everything. Weigh it against Tighten the release process: two identical faults reached dev and were found by hand #40's lesson: dev received a broken
   registration precisely because the full journey had not run. Whatever moves later must not
   move past the point where it would have caught that.
5. Prod (SPEC §8): the release path is a manual approval or a vX.Y.Z tag. Decide whether
   a release promotes the image that already passed on dev or builds a new one, and what has to
   be green for a release whose commit is older than main's last run.
6. Retention: build artifacts and container images. Free while the repository is public,
   billed the day it is private — see Take the repository private again — what it costs and what must be in place first #163.

What the answer should look like

A short written decision in SPEC §6/§8 — what runs on a push, on a pull request, before a
merge, on a release — and the workflow changed to match. Reported with the two numbers that
matter, before and after: minutes to a merge-ready verdict and billable minutes a month.

Labels: infra, decision