The Gate That Couldn't Grade Itself

A continuous-integration gate is supposed to answer one question: should this merge? Ours answered a different one. It could tell you whether the code compiled, whether the lints were clean, whether the tests passed — an hour of careful work. What it never asked was whether the merge should happen at all.

That omission was expensive in a specific way. A branch opened weeks ago, sitting far behind a main that had since shipped thousands of lines, would enter the gate, compile everything, run everything — and only a human, afterward, would notice that merging it would quietly erase other people's work. The gate spent its most expensive resource proving something nobody should have asked it to prove.

The cheapest check was missing

The fix is embarrassingly small in concept: before compiling anything, ask how far behind the branch is. A merge-base and a commit count — sub-second, pure bookkeeping. If a branch exceeds its staleness budget, the gate fails in seconds with a message that says exactly why: rebase, then come back. The hour-long compile now only runs on work that's eligible to land.

There's a subtler check riding alongside it. When a branch deletes a file that main has since modified, the merge is already headed for a conflict — so the gate doesn't block it, but it does say so, early, in the log, while the context is still fresh. Warnings are for things the tooling already catches; failures are for things it doesn't. Keeping that distinction honest is what keeps a gate's failures meaningful.

Checks you can't vote on

The more interesting problem was structural. A gate whose checks live inside the repository is a gate a pull request can edit — propose a change to the checks themselves, and the gate will happily run your weakened version against your own branch. It's the honor system wearing a hard hat.

So the safety check now exists twice. One copy lives in the repo, where it protects manual runs and gives the feedback message a single source of truth. The other lives outside the repository entirely, in the runner's own configuration — the part a pull request can't touch — and it runs before the repo's suite is even invoked. The repo's copy is a convenience; the outer copy is the boundary. If a change ever removes the inner one, the outer one still says no.

Skipping work is also correctness

The gate also learned to say already done. A commit that's already an ancestor of main doesn't need gating — the work landed; running the suite again is just burn. Each runner now marks those and moves on. It sounds like an optimization; really it's the same principle as the staleness check. A queue's job is to spend its scarce, serial attention on the small set of things whose answer isn't already known.

And because a wedged build used to be able to park the queue indefinitely, the gate now runs inside explicit time budgets with cleanup semantics that reach the whole process tree — a timed-out compile can't leave orphaned processes holding locks for the next branch in line.

Testing the guard itself

None of this counts until the checks themselves are tested — a guardrail that silently never fires is worse than none, because it manufactures confidence. The staleness thresholds, the collision warning, the skip hatch, the missing-reference fallback: each one gets exercised against synthetic repositories where the right answer is known in advance. The gate's job is judgment, and judgment deserves a test suite like everything else.

The deeper lesson is about ordering. Correctness isn't only which checks you run — it's which ones you run first, and whether the cheapest question gets asked before the expensive one. In this case the cheapest question was also the most important one, and it was last in line. Now it's first — twice, in fact: once where anyone can see it, and once where nobody can touch it. The second copy is the whole point — a safeguard that lives inside the thing it guards is a safeguard by courtesy, and courtesy is not a control.