Summary
The `publish` job in `.github/workflows/ci.yml` does `git commit` + `git push` directly to main to land a `chore: update bundles.lock` after every successful pipeline run. The repository ruleset on `main` (`Changes must be made through a pull request`) rejects that push:
```
remote: error: GH013: Repository rule violations found for refs/heads/main.
remote: - Changes must be made through a pull request.
```
The Promote-to-GHCR step itself succeeds — bundles publish correctly. Only the lockfile commit-back is blocked. Result: bundle publishing and bundles.lock drift apart, requiring a manual `phpup lockfile-update` PR after every catalog/builder change that triggers a real bundle rebuild.
Repro
Any push to main that produces a `bundles.lock` diff. Most recent example: post-merge run for #88, where Promote landed all 10 redis 6.3.0 canonical tags, Update lockfile regenerated bundles.lock with those entries, but `Commit lockfile (if changed)` failed with `exit 128`. Lockfile catch-up had to be done manually in #89.
Options
A — Bot-PR flow (preferred)
Replace the inline `git commit` + `git push` in `.github/workflows/ci.yml` (publish job, Commit-lockfile step) with `peter-evans/create-pull-request@v6` (or equivalent). The action commits the regenerated `bundles.lock` to a branch and opens/updates a PR titled `chore(lock): update bundles.lock from pipeline `. Maintainers merge it through the normal ruleset path.
Pros: no admin/ruleset change. Stays inside the PR-for-everything posture. Bot PRs are easy to review/squash.
Cons: extra PR per main publish run. May need labels/auto-merge to keep the queue tidy.
B — Ruleset bypass for github-actions
Add the `github-actions[bot]` (or a dedicated `buildrush-bot` PAT identity) to the main-branch ruleset's bypass list. The `publish` job's existing `git push` then succeeds.
Pros: no workflow change. Single auto-commit per main publish — no PR queue.
Cons: requires repo-admin settings change. Wider trust surface (anything triggering the publish job can push to main, not just bundle updates).
C — Switch to the GitHub-app PAT model
Provision a fine-grained PAT with `contents:write` and the `Metadata: read` + repository ruleset bypass. Set it as a secret `PHPUP_LOCKFILE_PAT`. Update the publish job to use that token for `actions/checkout` instead of `secrets.GITHUB_TOKEN`.
Pros: explicit, scoped credential.
Cons: secret rotation overhead. PAT-based bypass is per-repo manual setup.
I'd lean (A) — least admin friction, predictable behavior, no special trust elevation.
Out of scope
This issue is about the publish-job auto-commit gap. The `phpup push` correctness fix (canonical tags + annotation propagation) is in PR #87. The artifact-merge fix (per-cell layout walk) is in PR #88. Those are prerequisites; this is the closing piece.
Why now
Filed per CLAUDE.md "Deferred Work" rule. Discovered during the redis 6.3.0 bump (#38, PR #76) and tracked through the chain (#83 → #85 → #86 → #87 → #88 → #89). PR #89 documents this as outstanding follow-up; this issue makes it auditable.
Summary
The `publish` job in `.github/workflows/ci.yml` does `git commit` + `git push` directly to main to land a `chore: update bundles.lock` after every successful pipeline run. The repository ruleset on `main` (`Changes must be made through a pull request`) rejects that push:
```
remote: error: GH013: Repository rule violations found for refs/heads/main.
remote: - Changes must be made through a pull request.
```
The Promote-to-GHCR step itself succeeds — bundles publish correctly. Only the lockfile commit-back is blocked. Result: bundle publishing and bundles.lock drift apart, requiring a manual `phpup lockfile-update` PR after every catalog/builder change that triggers a real bundle rebuild.
Repro
Any push to main that produces a `bundles.lock` diff. Most recent example: post-merge run for #88, where Promote landed all 10 redis 6.3.0 canonical tags, Update lockfile regenerated bundles.lock with those entries, but `Commit lockfile (if changed)` failed with `exit 128`. Lockfile catch-up had to be done manually in #89.
Options
A — Bot-PR flow (preferred)
Replace the inline `git commit` + `git push` in `.github/workflows/ci.yml` (publish job, Commit-lockfile step) with `peter-evans/create-pull-request@v6` (or equivalent). The action commits the regenerated `bundles.lock` to a branch and opens/updates a PR titled `chore(lock): update bundles.lock from pipeline `. Maintainers merge it through the normal ruleset path.
Pros: no admin/ruleset change. Stays inside the PR-for-everything posture. Bot PRs are easy to review/squash.
Cons: extra PR per main publish run. May need labels/auto-merge to keep the queue tidy.
B — Ruleset bypass for github-actions
Add the `github-actions[bot]` (or a dedicated `buildrush-bot` PAT identity) to the main-branch ruleset's bypass list. The `publish` job's existing `git push` then succeeds.
Pros: no workflow change. Single auto-commit per main publish — no PR queue.
Cons: requires repo-admin settings change. Wider trust surface (anything triggering the publish job can push to main, not just bundle updates).
C — Switch to the GitHub-app PAT model
Provision a fine-grained PAT with `contents:write` and the `Metadata: read` + repository ruleset bypass. Set it as a secret `PHPUP_LOCKFILE_PAT`. Update the publish job to use that token for `actions/checkout` instead of `secrets.GITHUB_TOKEN`.
Pros: explicit, scoped credential.
Cons: secret rotation overhead. PAT-based bypass is per-repo manual setup.
I'd lean (A) — least admin friction, predictable behavior, no special trust elevation.
Out of scope
This issue is about the publish-job auto-commit gap. The `phpup push` correctness fix (canonical tags + annotation propagation) is in PR #87. The artifact-merge fix (per-cell layout walk) is in PR #88. Those are prerequisites; this is the closing piece.
Why now
Filed per CLAUDE.md "Deferred Work" rule. Discovered during the redis 6.3.0 bump (#38, PR #76) and tracked through the chain (#83 → #85 → #86 → #87 → #88 → #89). PR #89 documents this as outstanding follow-up; this issue makes it auditable.