ci(git-hygiene): run the branch guard instead of restating its rule - #69
Open
saagpatel wants to merge 1 commit into
Open
ci(git-hygiene): run the branch guard instead of restating its rule#69saagpatel wants to merge 1 commit into
saagpatel wants to merge 1 commit into
Conversation
This repository just landed scripts/git/guard-branch.sh, which accepts <type>/<slug>, codex/<type>/<slug> and <agent>/<task-slug>. The branch-name job still carried its own copy of the rule accepting only codex/<type>/<slug>, so a branch the local hook blessed failed here. One rule in two places, already drifted, and only the untested copy gates a pull request. The job now checks out the repository and runs the guard. The dependabot and renovate job-level exemptions stay; the guard covers dependabot and release-please itself. The job's permission drops from pull-requests: read to contents: read, because it reads files now rather than the pull request API. Trade-off worth naming: the guard is read from the pull request's own checkout, so a pull request could in principle weaken the check it is subject to. The inline copy could not be edited that way. This repository takes no external contributions and the pull_request token is read-only, and the commitlint job in this same workflow already runs against the pull request's checkout, so the exposure is not new. No untrusted input is interpolated into a run: step; the guard reads GITHUB_HEAD_REF from the environment. Verified: the workflow parses, and the guard was exercised in this checkout under CI environment variables against four branch names it must accept (including the two shapes that were failing here) and three it must reject. All seven behaved correctly.
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.
Makes the
branch-nameCI job run this repository's own branch guard instead ofcarrying a second copy of its rule.
This repository just landed
scripts/git/guard-branch.sh, which accepts<type>/<slug>,codex/<type>/<slug>and<agent>/<task-slug>. Thebranch-namejob still held its own regex accepting onlycodex/<type>/<slug>. So a branch the local pre-commit hook blessed failed inCI — one rule, in two places, already drifted, and only the untested copy gates
a pull request.
The job now checks out the repository and runs the guard. The
dependabot/andrenovate/job-level exemptions stay; the guard handlesdependabotandrelease-pleaseitself. The job's permission drops frompull-requests: readto
contents: read, because it reads files now rather than the pull request API.Trade-off worth naming. The guard is read from the pull request's own
checkout, so a pull request could in principle weaken the check it is subject
to. The inline copy could not be edited that way. This repository takes no
external contributions, the
pull_requesttoken is read-only, and thecommitlintjob in this same workflow already runs against the pull request'scheckout — so the exposure is not new, but it is real. Pinning the guard to the
base commit would close it, at the cost of breaking any repository where a
pull request is what first introduces the script.
No untrusted input is interpolated into a
run:step. The guard readsGITHUB_HEAD_REFfrom the environment.Verified. The workflow parses, and the guard was exercised in this checkout
under CI environment variables against four branch names it must accept —
including the two shapes that were failing here — and three it must reject. All
seven behaved correctly. Across the ten repositories getting this change that is
70 guard invocations, all correct.
CI only. No source, test, or configuration file outside
.github/workflows/istouched.