Skip to content

ci(git-hygiene): run the branch guard instead of restating its rule - #69

Open
saagpatel wants to merge 1 commit into
mainfrom
codex/ci/align-branch-name-gate
Open

ci(git-hygiene): run the branch guard instead of restating its rule#69
saagpatel wants to merge 1 commit into
mainfrom
codex/ci/align-branch-name-gate

Conversation

@saagpatel

Copy link
Copy Markdown
Owner

Makes the branch-name CI job run this repository's own branch guard instead of
carrying 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>. The
branch-name job still held its own regex accepting only
codex/<type>/<slug>. So a branch the local pre-commit hook blessed failed in
CI — 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 handles 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, 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, 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 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. 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/ is
touched.

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant