You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
docs(ci-setup): the required "Allow GitHub Actions to create and approve pull requests" setting weakens a ≥1-approval ruleset #653
The standing-PR template (templates/workflows/standing-pr.yml:4-8) and packages/release/docs/ci-setup.md require the repository setting "Allow GitHub Actions to create and approve pull requests". GitHub ties creating and approving PRs to that one toggle, so with it on, any workflow's GITHUB_TOKEN can submit an approving review — including a workflow a write collaborator adds on their own branch.
That approval counts toward the ruleset ci-setup.md recommends as the merge gate — "Require a pull request before merging (≥ 1 approval)" on the default branch — for any PR not authored by github-actions[bot]. A feeder PR approved that way then ships in the next standing-PR release, whose own diff shows only version and changelog changes.
Proposal
Document the trade-off next to the setup requirement.
Recommend pairing the default-branch ruleset with required Code Owners review (or required team reviewers), which a workflow token can't satisfy. The CODEOWNERS file needs a * rule naming an owner with write access, and the ruleset should also dismiss stale approvals when new commits are pushed. None of it applies to bypass actors (Standing-PR setup: bypasses for the Actions bot and workflow-wide id-token: write reach every workflow #785).
Document creating the standing PR with a GitHub App token (e.g. actions/create-github-app-token) so the toggle can stay off.Dropped: the App's key would be a repository secret, which any workflow on any branch can read, so a collaborator's workflow could mint an App token and approve their own PR.
Optionally, recommend binding npm trusted publishing and registry secrets to a deployment environment restricted to the default branch — the template's publish job sets no environment:. A merged PR's closed run has the branch it merged into as its ref, so the merge-triggered publish jobs pass. A label-triggered retry may not.
Related: #619 (agent guidance already cautions against relying on "≥ 1 approval" alone).
Items 1, 2 and 4 are done in #758. The template's other least-privilege gaps are tracked in #785.
Activity
docs: note the sync notes-region gap and tighten the agent and rulese…
docs: document the standing-PR body as an interface, add agent guidan…