Automated releases cannot push to a branch protected by the standard ruleset

[clarkbw]

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 main are worth flagging in the audit checklist.
• Apply the outcome to aiscast, whose rulesets are live and untested against a release.

[clarkbw]

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.

name: publish
on:
  release:
    types: [published]
permissions:
  contents: read
  id-token: write # npm trusted publishing + provenance
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          registry-url: https://registry.npmjs.org
      - name: assert the tag matches the committed version
        env:
          TAG: ${{ github.event.release.tag_name }}
        run: |
          version="$(node -p "require('./package.json').version")"
          [ "$TAG" = "v${version}" ] || { echo "tag $TAG does not match package.json v${version}" >&2; exit 1; }
      - run: npm ci
      - run: npm test
      - run: npm pack --dry-run
      - run: npm publish

Releasing looks like:

• bump the version in a PR (collapse docs), merge
• gh release create vX.Y.Z

If 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:

• Make this the one flow in npm-releases.md, Changesets kept for monorepos
• Decide whether aiscast's tag prefix is a parameter or an exception
• Build the release agent/skill
• Migrate aiscast first, its rulesets are live and the next release hits this
• Then crowd-depth, Adopt the Open Waters repository standards crowd-depth#115

[clarkbw]

@bkeepers would love your thoughts here

[bkeepers]

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.

Stop writing to main during a release.

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]

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.