A pipeline that tells the truth

The problem with a green pipeline

A pipeline that only proves the build succeeded is not very useful. It tells you the code compiles. It does not tell you the page renders, the links resolve, or the deploy actually replaced the old version.

This site runs a small pipeline with one rule: every stage has to answer a question I would ask during an incident.

What the pipeline does

1. Build — installs dependencies from a lockfile and produces a static bundle. The cache key includes the lockfile hash, so a dependency change never reuses a stale build.
2. Check — runs the type checker and a link check against the generated HTML. Broken internal links fail the build.
3. Preview — deploys every pull request to a temporary URL. The URL is posted back to the pull request so it can be reviewed on a phone.
4. Smoke test — requests the home page and the RSS feed from the preview, then checks for a 200 and an expected marker in the HTML.
5. Promote — deploys production only after the preview passes.

- name: Smoke test
  run: |
    curl --fail --silent --show-error "$PREVIEW_URL" > /dev/null
    curl --fail --silent --show-error "$PREVIEW_URL/rss.xml" > /dev/null

Rollback is a first-class path

Deploys are immutable. Each one produces a versioned artifact, and production points at one of them. Rolling back means pointing at the previous artifact and purging the cache — not rebuilding from an older commit and hoping the toolchain behaves the same way.

That distinction matters. Rebuilding is a new event with new inputs. Rolling back should restore a known state.

What I learned

The most useful stage is the smoke test, and it is also the cheapest. It caught a deploy where the build succeeded but the stylesheet 404'd because the asset path changed. The pipeline was green; the site was not.

Since then I treat "the build passed" as the start of the verification, not the end of it.