ci: promote E2E_REF to pins.env and let a job keep it current - #38
Merged
Conversation
e2e.yml gates every commit here against a pinned harness revision, and nothing noticed when that pin went stale: a harness fix lands over there, this gate keeps testing the version before it, and the runs stay green while saying less and less. It happened the day the gate was built, and again for the eight nights after 0.1.0 was cut. The counterpart repository used to report this by failing its own nightly job. That is replaced by a pair of workflows that file the work instead — this is the half that lives here. e2e-pin-bump.yml reads provin-line/e2e's nightly crosscheck (whose conclusion now means exactly "did the pair work" — the harness moved its own bookkeeping out of it for this reason), and when a harness revision has been proven green against this product's then-current HEAD it prepares the bump on chore/bump-e2e-pin and files an issue linking the run that proved it. e2e.yml on the bump pull request re-verifies the pairing against the actual merge target. When no proven revision exists, or the proven one is not strictly ahead of the pin, it does nothing: a bump nobody has tested is worse than a stale pin, and a backwards bump would weaken the gate while looking exactly like progress. The bumper refuses to touch a branch with an open pull request or a tip it did not write (committer checked as well as author — --amend preserves bot authorship), pushes with a force-with-lease pinned to the tip it inspected, and treats any non-default-ref dispatch as a forced dry run. E2E_REF had to leave the workflow file for any of that to work. Its comment anticipated a promotion "when a second pin appears"; a second pin has not appeared, but a harder constraint did — GITHUB_TOKEN has no `workflows` scope, so nothing running in CI can edit a pin that lives inside a workflow file, and a pin only a human can move is a pin that goes stale. The move costs one real property, stated plainly in pins.env rather than left for someone to discover: in the workflow file the pin was immune to pull request edits; as an ordinary file a pull request can change it. e2e.yml bounds that twice — exactly one E2E_REF line, a literal 40-hex commit id — and then re-asserts the checkout landed on the pinned revision after the fact, the same backstop the harness's own ci.yml gets from `make verify-pin`. The residual exposure is a pull request naming an OLDER harness, which every check passes and only review catches; pins.env says so in those words. This commit deliberately does not move the pin. It is the structural change only, so the first bump arrives through the mechanism rather than alongside it.
Contributor
Author
|
Rehearsal note: GitHub cannot |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
e2e.ymlgates every commit against a pinned harness revision, and nothing noticed when that pin went stale — it happened the day the gate was built, and again for the eight nights after the harness cut 0.1.0. The harness used to report the staleness by failing its own nightly job; that channel is being retired (provin-line/e2e#11) in favour of each repository filing its own bump.What
E2E_REFmoves frome2e.yml'senv:block to a rootpins.env. Not because a second pin appeared (the old comment's promotion trigger) — because GITHUB_TOKEN has noworkflowsscope, so no automation can ever edit a pin living inside a workflow file, and a pin only a human can move is a pin that goes stale.pins.envrather than left to be discovered: in the workflow file the pin was immune to PR edits; as an ordinary file a PR can change it.e2e.ymlbounds that twice — exactly oneE2E_REFline, literal 40-hex only — and then re-asserts the checkout landed on the pinned revision after the fact (the same backstop the harness'sci.ymlgets frommake verify-pin). Residual exposure: a PR naming an older harness passes every check; that is a review question, andpins.envsays so.e2e-pin-bump.yml(nightly): finds the newest greenoss-crosscheckrun in provin-line/e2e, and only if its harness revision is on main and strictly ahead of the pin prepares the bump onchore/bump-e2e-pin+ files apin-bump-labelled issue with a one-click PR link. Same refusal set as the harness's mirror: open PR → untouched; foreign tip (committer checked too) → untouched;--force-with-lease; non-default-ref dispatch → forced dry-run.Verification
bash -nclean; branch-step paths and lease rejection exercised against a scratch remote; the evidence/decide steps run against the live GitHub API (current state resolves toreason=not-ahead→ correctly proposes nothing).workflow_dispatchrehearsal on this branch (forced dry-run) — run link to follow in a comment.🤖 Generated with Claude Code