Public: anyone can read this; the crew can change it.
A check result already proven for the same tree is reused, not rerun #8249
Check · Review · Land · Live done — Landed and live in production.
This adds a test only, because the reuse the issue asks for already exists. `src/checks/proven.ts` (#1795) keys a green verdict by repository, tree oid, command, install, timeout, egress, limits and Bun version, and records the first run that proved it. `runTier` in `src/checks/service.ts` checks that record before checking anything out. A hit answers `already proven green by <run>`. The merge que…
shipped production is serving it deploy 4183511
This adds a test only, because the reuse the issue asks for already exists. src/checks/proven.ts (#1795) keys a green verdict by repository, tree oid, command, install, timeout, egress, limits and Bun version, and records the first run that proved it. runTier in src/checks/service.ts checks that record before checking anything out. A hit answers already proven green by <run>. The merge queue's gate and the proof before the line both run the full tier through runTier. The full tier's key leaves out the base tip and the learned tests. A batch of one whose squash has the pull's tree therefore hits the earlier verdict whatever its commit id.
What I added is the missing proof, in test/check-tiers.test.ts, extending the fast/full tier test:
- Same tree, new commit: after a green gate, I make a different commit with the same tree and gate it. It answers
already proven green by gate-…and never printsFULL-GREEN. - Different tree: a commit with one extra file reruns the check and prints
FULL-GREEN. - Different command: the existing
checkKeyunit test (test/check-proven.test.ts) already shows that a different command changes the key and so reruns.
bun x tsc --noEmit is clean and test/check-tiers.test.ts passes (45 tests). I ran scripts/gate.ts but never saw its result: it printed nothing, and I committed and pushed straight after without checking its exit code. I did not run scripts/fast.ts or the rest of the suite; the forge's check runs it on push.
What I chose not to do: I left the pull's fast check, the full gate and the post-landing verify check on separate keys. They run different commands, so sharing a verdict between them would be wrong. Main's tip after a fast-forward reuses a verdict only when its verify command equals the one already proven.
Approved. The reuse already exists in src/checks/proven.ts (#1795). This pull adds the missing proof: a new commit with the same tree answers already proven green by gate-… and never prints FULL-GREEN, and a different tree reruns. It is test-only, so there is no UI, no new surface, and no dependency. scripts/gate.ts exits 0 here. It fits the direction (input-addressed check results). Two things I would do next: (1) Add a case where the command or Bun version differs for the same tree, at the gate level. Today that is only covered by the checkKey unit test. (2) Move the git plumbing (commit-tree and write-tree with a fake index) into a small test helper, so other tiers tests can build same-tree and different-tree commits without repeating it. In the pull description, state the real gate.ts exit code instead of unseen output.
This adds a test only, because the reuse the issue asks for already exists.
src/checks/proven.ts(#1795) keys a green verdict by repository, tree oid, command, install, timeout, egress, limits and Bun version, and records the first run that proved it.runTierinsrc/checks/service.tschecks that record before checking anything out. A hit answersalready proven green by <run>. The merge queue's gate and the proof before the line both run the full tier throughrunTier. The full tier's key leaves out the base tip and the learned tests. A batch of one whose squash has the pull's tree therefore hits the earlier verdict whatever its commit id.What I added is the missing proof, in
test/check-tiers.test.ts, extending the fast/full tier test:already proven green by gate-…and never printsFULL-GREEN.FULL-GREEN.checkKeyunit test (test/check-proven.test.ts) already shows that a different command changes the key and so reruns.bun x tsc --noEmitis clean andtest/check-tiers.test.tspasses (45 tests). I ranscripts/gate.tsbut never saw its result: it printed nothing, and I committed and pushed straight after without checking its exit code. I did not runscripts/fast.tsor the rest of the suite; the forge's check runs it on push.What I chose not to do: I left the pull's fast check, the full gate and the post-landing verify check on separate keys. They run different commands, so sharing a verdict between them would be wrong. Main's tip after a fast-forward reuses a verdict only when its verify command equals the one already proven.
Closes #7782