Repository navigation
Automated releases cannot push to a branch protected by the standard ruleset #13
Description
The default-branch ruleset in the standards requires a pull request, and the release-tag ruleset blocks tag updates. Several release workflows do neither: they push a version bump straight to main and move the release tag. Where both exist, the next release fails. We need to settle which side gives way before more repos adopt the rulesets.
Raised while bringing crowd-depth up to spec in openwatersio/crowd-depth#115, where the rulesets are the one item left unapplied.
Where this stands today
aiscast has both active rulesets and a release workflow that pushes to main. Its rulesets were created on 2026-09-08; its last successful release ran on 2026-09-01. No release has run under them, so the conflict is latent rather than observed.
crowd-depth has the same workflow shape and no rulesets. It also force-pushes the release tag onto the version-bump commit, which the tag ruleset's update rule blocks.
Both rulesets currently bypass only the repository admin role. A workflow pushing with GITHUB_TOKEN acts as the GitHub Actions app, which that bypass does not cover.
Tier 1 and tier 2 sharpen this: they require an approving review, and no bot can supply one for an automated push.
Options
Grant the GitHub Actions app a bypass on both rulesets. Smallest change and no workflow edits. The cost is that every workflow in the repo can then write to main unreviewed, so the protection holds for humans only.
Stop writing to main during a release. The tag becomes the source of truth for the version, and the workflow publishes without committing back. The tracked package.json version then trails the published one, which is a real cost for a plugin whose version users read from the repo.
Move the version bump ahead of the tag. A release pull request carries the bump, merges normally under the ruleset, and the tag is cut from the merged commit. This is the Changesets flow the standard already sanctions, and it needs no bypass, at the price of a second step per release.
To decide
- Which option becomes the baseline for tier 1 and tier 2 repos.
- Whether the standard records an explicit bypass actor for release automation, rather than leaving each repo to invent one.
- Whether release workflows that push to
mainare worth flagging in the audit checklist. - Apply the outcome to
aiscast, whose rulesets are live and untested against a release.
Activity
clarkbw commentedon Sep 8, 2026
We currently have 4 flows, would be nice to reduce down to 1 or 2 if possible. Monorepos need a different style, so Changesets can survive for neaps.
Here's an example that takes station-metadata's trigger and almanac's guard.
Releasing looks like:
gh release create vX.Y.ZIf we build a release agent or skill we could keep this a small / quick job a cheap model can manage.
Claude tells me these are the steps:
npm-releases.md, Changesets kept for monoreposclarkbw commentedon Sep 10, 2026
@bkeepers would love your thoughts here
bkeepers commentedon Sep 10, 2026
I don't feel strongly either way. I agree it would be good to standardize where it makes sense. But I also think it's easy to have the process documented and let agents do what they do.
This is probably the only thing I would vote against. Then the code is no longer the source of truth and you have to look at past releases to derive the version number.
clarkbw commentedon Sep 10, 2026
Oh, I think the other system creates release PRS. Those PRs are merged into main and then the version number is committed. In some of the actions a version gets pushed into main a part of the last step.