Repository navigation
docs: forbid bypassing a gate - #10
Closed
kieronlanning wants to merge 1 commit into
Closed
kieronlanning wants to merge 1 commit into
kieronlanning wants to merge 1 commit into
Conversation
A hook, a required status check and a pipeline step are run by the party being checked, so none of them may be skipped by that party: no --no-verify on a commit or a push, no LEFTHOOK_EXCLUDE or SKIP, no continue-on-error or trailing || true, no force-push over a protected ref. The failure is not the one skipped run. A failing check stays visible on the pull request; a bypassed one is indistinguishable from a passing one afterwards, so the next reader cannot tell the gate was ever honoured. That is what makes it a never, rather than a judgement call weighed against a good reason - and 'it passed elsewhere' is always a claim about a different run, made by whoever wants the exemption. Records the concrete forms, the incident that earned the rule (a pre-push chain that hung in a network-dependent sync), and the honest enforcement: review, with a required status check as the backstop, because a hook cannot enforce its own non-bypass.
Contributor
Author
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
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
I used
git push --no-verifyin a clone whosepre-pushhook ranjust validate. The hook hung inits network-dependent data sync, so I skipped the gate and reasoned that the same chain had passed as
ci:buildminutes earlier and that CI would run it again.Both of those statements were true, and the reasoning was still wrong. A failing check stays visible on
the pull request forever; a bypassed one is indistinguishable from a passing one afterwards. The next
reader — or the next agent — has no way to tell the gate was honoured, and "it passed elsewhere" is
always a claim about a different run, made by the party who wants the exemption. That is why this is a
never rather than a judgement call.
What this adds
A gate is not bypassed in the Verification
Model, with the concrete forms —
--no-verify,-n,LEFTHOOK_EXCLUDE/SKIP/HUSKY=0, force-pushover a protected ref,
continue-on-erroror a trailing|| true, deleting the failing step — theincident above, and the honest enforcement: review, with a required status check as the backstop,
because a hook cannot enforce its own non-bypass.
AGENTS.mdcarries the same rule as the first item of the completion checklist, so an agent reads itbefore it reads anything else about verification.
Verification
dotnet csharpier check .→ cleandotnet test→ 90 total, 85 passed, 5 skipped, 0 failed (theDocumentationTestsnavigation andfence rules apply to the changed page)
No hook was bypassed in producing this branch.