JevGate 0.31.0: the commit moment, and the release (Git hooks judge what a push sends or a commit records) - #48
Merged
Merged
Conversation
`check --pre-push` judges what a push sends: the refs Git passes a pre-push hook, or the one pre-commit and prek pass as PRE_COMMIT_TO_REF, each compared with the last commit on its first-parent line that a remote has, or with the commits a remote has that the push merges in, merged as Git merges them. `check --staged` judges what a commit records: the index against HEAD, never untracked files, and a merge commit for its resolution. The files the change touched are read from Git, and so are the source recheck and the allow comments. A Git hook's check that cannot finish lets the change through and says so (`on_incomplete`, pass by default for the hooks, fail elsewhere), stops asking after 60 seconds (`max_seconds`) or a dollar budget (`max_cost`), waits out a provider failure for five minutes as the agent hook does, and can be skipped with Enter on a terminal. A stopped commit or push tells a coding agent to fix the findings and never to bypass the hook. `jevgate init --git-hook pre-push|pre-commit` writes the hook, and the pre-commit hooks run the new checks.
…nd husky A Git hooks page says what each hook judges, what happens when a check cannot finish, and how to run the hooks from pre-commit, prek, lefthook, husky or any hook runner; each recipe ran end to end. The CI, configuration, output, stability, coding-agent and troubleshooting pages and the README point to it, and the pre-commit snippet moves there from the CI page.
The release check asked, in considers, for members of requests.rs, output/mod.rs and docs/references.rs to move to modules of their own: the dollar budget and the bill go to requests/billing.rs, the headline to output/headline.rs, and the inline code spans and fences the references rule reads to docs/spans.rs. Nothing else changes.
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.
This pull request is the release too: its last commit is
Release 0.31.0(version, lockfile, packages, pins, CHANGELOG), after the release check's three considers were fixed inGive billing, the headline and Markdown spans modules of their own. JevGate's check of the whole repository with every rule then passed with no review or consider left, apart from the one already baselined in 0.30.0 and one on a gitignored local note. Merged,maingets taggedv0.31.0.The roadmap's commit moment, to be released as 0.31.0. A Git hook runs the gate before each push or commit, on what the push sends or the commit records, read from Git rather than the working tree. A check that cannot finish lets the change through and says so, instead of holding a commit while its retries run.
jevgate init --git-hookwrites the hook.What changes
check --pre-pushjudges what a push sends.PRE_COMMIT_TO_REF; on a terminal, the current branch.git merge-treemerges them, conflict markers included. Aftergit merge origin/main, the first-parent comparison judged main's changes as the push's own; this one judges the push's commits and its conflict resolutions.check --stagedjudges what a commit records: the index against HEAD, never untracked files.check --base HEAD, which judges the working tree plus untracked files. A file staged in part withgit add -pwas judged with lines the commit didn't hold, and an untracked file could stop a commit it wasn't part of.GIT_INDEX_FILE, socommit -aandgit commit PATHSwork). So are the stale-source rechecks and thejevgate: allowcomments, which read the working tree and would have failed or misplaced findings on a partly staged file.on_incomplete = "pass" | "fail"(--on-incomplete). It passes by default with--stagedand--pre-push, and fails everywhere else, so CI still exits 2.max_seconds/--max-seconds: 60 by default for the hooks. No request starts and no retry waits past it, and an attempt under way gets only the time left.max_cost/--max-cost: dollars. Each request is priced once from its size before it is sent, with notices at 75% and 90%..jevgate/turns/outage.json.use_stdin: true(the pre-push recipe) orinteractive: true: other jobs run in lefthook's own pseudo-terminal, which gets no keys. The docs say so.--no-verify, an allow comment or the baseline.jevgate init --git-hook pre-push|pre-commit [--remove] [--dry-run]:.git/hooks/pre-pushorpre-commit, never over a hook it didn't write.core.hooksPath(husky) keep the hooks, it names what to add there instead.jevgateisn't on the PATH..pre-commit-hooks.yaml:jevgateandjevgate-systemnow runcheck --stagedat the pre-commit stage only. Before, they ran--base HEADat every installed stage. Newjevgate-pushandjevgate-push-systemruncheck --pre-push. All four areverbose, since pre-commit hides a passing hook's output, and they would otherwise hide the not-checked notice. They need pre-commit 3.2 or later."staged": trueandpushed_revisionare additive fields. The headline readsstaged lines since …orchanged lines from … to ….Measurements
Latency, uncached. On the last commits of the 83 corpus projects whose last commit asks something (the release build,
--base HEAD~1 --refresh, the content a one-commit push sends), run one at a time as a hook runs:Recipes, end to end. Each tool ran in a scratch repository against a local mock provider. A review stops, and a 402 lets the change through with the notice shown.
jevgate init --git-hookuse_stdin: true)Self-check. With every rule, on this branch's diff: the gate passes with no review or consider. Four considers from an earlier run were fixed:
configured;Report::incomplete_reason;Done when
staged_judges_what_the_index_holds_at_the_lines_it_holds_themgets the finding at the index's line 1, while the working tree holds another function two lines lower and an untracked copy.staged_reads_the_index_git_commits_fromcovers a temporaryGIT_INDEX_FILE.on_incomplete = "fail". Tests:a_commit_or_a_push_goes_ahead_when_the_check_cannot_finish_and_says_so,budgets_stop_the_asking_and_leave_the_run_incomplete(a 5 s provider cut at 1 s), anda_provider_failure_is_waited_out_by_the_next_commits.a_push_of_several_refs_checks_each_distinct_change_oncecovers several refs.the_hooks_stop_a_commit_and_a_push_and_let_through_what_they_cannot_checkruns a realgit commitandgit pushthrough the installed hooks.Decisions
on_incompletepasses by default only for the two hooks.--staged, and the new push IDs are what the docs lead with. Moving the old IDs to pre-push would quietly stop them for anyone who installed only the pre-commit hook.init --git-hookis in.verbose.on_incomplete = "fail"also stops a push that cannot be compared, because none of its history is on a remote.