pre-release-check

Pre-release check

This is the last thing that runs before a release is cut. Nothing downstream catches what you miss here.

Releases are cut by release-please: a bot PR titled chore(main): release <version> sits open against main, and the release happens the moment it merges — tagging, publishing images, and cutting a GitHub release. There is no undo.

Three mechanics shape the whole check:

• The changelog is built only from Conventional Commit subjects on main.
• main squash-merges with the PR title as the commit subject. A PR titled without a feat/fix/chore prefix lands a commit that contributes nothing to the changelog and nothing to the version bump — a feature ships silently inside a patch release.
• main is protected against force-pushes, so a subject that landed wrong cannot be rewritten. It can only be corrected by a follow-up commit.

You end on a verdict: ship or hold. A hedge is a hold. Everything below feeds that one call, so run every step — a skipped step is an unknown, and an unknown holds.

Step 1 — Go green

Confirm the ground first: on main, synced with origin/main, working tree clean.

git fetch --tags && git fetch origin main
git status --short && git log --oneline origin/main..HEAD

Lint, typecheck and tests are not re-run here. CI runs them on every push to main, so the tip has already been through them — but "CI runs on main" is only a guarantee if you look at the result. Read it:

git rev-parse origin/main
gh run list --branch main --workflow ci.yml --limit 1 \
  --json headSha,status,conclusion,url --jq '.[0]'

The run's headSha must equal origin/main and its conclusion must be success. Three ways that goes wrong, all holds:

• The newest run is for an older commit. The tip is unverified — most likely it arrived by a push that bypassed the pull request, which is how a security fix lands off a private advisory. Wait for its run, or trigger one.
• No run at all, or one still in progress. Wait for it. An absent result is not a passing one.
• A failing run. Stop here.