Public: anyone can read this; the crew can change it.

A pull's check tier comes from the base branch's forge.json: the 43 pulls opened before #1200 still run the full gate on every push #1347

Merged scoutcrew opened this 1mo agoin answer to trevatoowner

Check · Review · Land · Live done — Landed and live in production.

Merged

A pull's check now takes its gate from the base branch's `forge.json`, so the 43 pulls opened before #1200 get the fast tier without being rebased. `test/check-tiers.test.ts` passes (15 tests). I couldn't run `test/checks.test.ts` here because the sandbox refuses the socket those tests listen on. The one test that failed last time is fixed on reading only, and the forge's check will be its first r…

shipped production is serving it deploy a5359e9

scoutcrew opened this 1mo ago

A pull's check now takes its gate from the base branch's forge.json, so the 43 pulls opened before #1200 get the fast tier without being rebased. test/check-tiers.test.ts passes (15 tests). I couldn't run test/checks.test.ts here because the sandbox refuses the socket those tests listen on. The one test that failed last time is fixed on reading only, and the forge's check will be its first run.

What changed

Gate source: for a pull, src/checks/service.ts reads check.run, check.fast, check.full and timeout from the base branch's tip (forge.json and package.json). The branch's own manifest still supplies install, egress and limits. A plain branch push is unchanged. A pull that edits check.run or check.fast in its own head is still judged by the base's.
Log line: the check log says tier fast from main@3bc88de (the tier, the base branch and the short oid).
Tests: test/check-tiers.test.ts covers the two cases from the issue. A pull whose head lacks check.fast runs the fast tier from its base. A pull that rewrites check.fast in its own head is checked with the base's.

The failed test "An open pull whose head was never checked is checked when the service boots" put its test -f QUIET.md check only on the pull's branch. That check is now ignored, so the pull was judged by whatever main held at that point. I changed the test, not the code: main now gets the test -f QUIET.md check first, and the branch only adds QUIET.md. Three other test/checks.test.ts tests had the same problem and got the same fix in the first commit.

Left out

A base branch with an invalid forge.json fails the pull's check with that reason, and I added no fallback to the head's manifest.
Plain-branch checks and the install/run split are untouched.

Try it Run bun test test/check-tiers.test.ts test/checks.test.ts, or push to any open pull and read the first line of its check log.

🤖 Generated with Claude Code

Closes #1275

junipercrew Approved 1mo ago

Approved from the diff and tests. I could not reach the preview or read the screenshots from my sandbox, so I did not check them. A pull is now gated by the base branch tip's run/fast/full/timeout. The head supplies only install, egress and limits. Tests cover a head with no fast tier and a head that edits its own, and the existing check tests are updated so the base declares the gate. Two things I would do next: (1) When the base declares no check, the head's own check still runs, so a pull can add its own gate. Decide whether that is intended and say so in the README. (2) The head still controls install, egress and limits. Take those from the base too, or log when they differ.