Bump version: push with a deploy key past a ruleset

.github/workflows/bump-version.yml

@@ -12,6 +12,11 @@ name: Bump version
 # Without a version file (version-file: "") the tag alone is the version: the highest vX.Y.Z tag is
 # raised and the current commit tagged, nothing is committed.
 #
+# A branch protected by a ruleset (pull request, status checks) refuses the GITHUB_TOKEN, and the
+# token cannot be put on the ruleset's bypass list. A deploy key with write access can: the secret
+# deploy-key pushes with it. Such a push starts `on: push` workflows like a push from a checkout,
+# so the release workflow then starts on the tag by itself and is not started a second time.
+#
 # Pre-releases: preminor on 1.2.3 gives 1.3.0-rc.1 (prepatch and premajor alike), prerelease then
 # 1.3.0-rc.2, and patch the release 1.3.0.
 on:
@@ -40,6 +45,10 @@ on:
         description: Workflow file started on the new tag; empty starts nothing
         type: string
         default: release.yml
+    secrets:
+      deploy-key:
+        description: Private SSH key of a deploy key with write access, for a branch whose ruleset lets deploy keys bypass it
+        required: false
     outputs:
       version:
         description: The new version (x.y.z or x.y.z-rc.N)
@@ -70,6 +79,9 @@ jobs:
           fi
 
       - uses: actions/checkout@v7
+        with:
+          # Empty: the GITHUB_TOKEN
+          ssh-key: ${{ secrets.deploy-key }}
 
       - id: bump
         name: Raise the version
@@ -292,6 +304,12 @@ jobs:
           GH_TOKEN: ${{ github.token }}
           TAG: ${{ steps.bump.outputs.tag }}
           WORKFLOW: ${{ inputs.release-workflow }}
+          DEPLOY_KEY: ${{ secrets.deploy-key != '' }}
         run: |
+          if [[ "$DEPLOY_KEY" == true ]]; then
+            # The tag pushed with the deploy key has already started its on: push workflows
+            echo "Tagged $TAG; pushed with the deploy key, so [$WORKFLOW]($GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/workflows/$WORKFLOW) starts on it by itself" >> "$GITHUB_STEP_SUMMARY"
+            exit 0
+          fi
           gh workflow run "$WORKFLOW" --repo "$GITHUB_REPOSITORY" --ref "$TAG"
           echo "Tagged $TAG and started [$WORKFLOW]($GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/workflows/$WORKFLOW) on it" >> "$GITHUB_STEP_SUMMARY"

.github/workflows/tested-on-main.yml

@@ -5,7 +5,8 @@ name: Tested on main
 # publishing.
 #
 # A release commit from "Bump version" changes only version numbers (and is pushed with the
-# GITHUB_TOKEN, which starts no CI), so the CI runs of the commit before it cover the code; several
+# GITHUB_TOKEN, which starts no CI; with a deploy key it does), so the CI runs of the commit before
+# it cover the code; several
 # release commits in a row without CI runs of their own (1.3.0-rc.1, then 1.3.0) are passed over
 # alike, a version-only commit with runs (a dependency bump) is not. Only
 # version numbers means: after replacing every x.y.z in the changed lines, the removed and the

README.md

@@ -123,7 +123,8 @@ jobs:
 
 [`.github/workflows/tested-on-main.yml`](.github/workflows/tested-on-main.yml) tells a release
 whether `main`'s CI already tested the code, so it doesn't run the whole CI again before building.
-A release commit from *Bump version* changes only version numbers (and starts no CI), so the green
+A release commit from *Bump version* changes only version numbers (and starts no CI, unless pushed
+with a deploy key), so the green
 push runs of the commit before it count, also over several release commits in a row without CI runs
 of their own (`1.3.0-rc.1`, then `1.3.0`); any other commit needs green push runs of its own, even
 one that only bumps a dependency's version.
@@ -414,6 +415,10 @@ jobs:
 | `tag-prefix` | `v` | |
 | `release-workflow` | `release.yml` | started on the new tag; `""` starts nothing |
 
+| Secret | |
+|---|---|
+| `deploy-key` | private key of a deploy key with write access, for a branch behind a ruleset (see below); then the tag starts the release workflow by itself |
+
 A `package-lock.json` next to a `package.json` and a `Cargo.lock` next to a `Cargo.toml` (the
 workspace's own crates) are updated along with it. In a Bun workspace the `bun.lock` in the
 `package.json`'s folder or the nearest one above it (up to the repository root) carries the version
@@ -433,7 +438,26 @@ at `.1`; `npm version preminor --preid rc` on a checkout would start at `.0`.
 commit tagged; nothing is committed. Without any such tag the first one is `v0.0.1` (patch).
 
 The commit is pushed to the branch the workflow runs on, so that branch must accept pushes from
-GitHub Actions (no rule that requires a pull request for every change).
+GitHub Actions (no rule that requires a pull request for every change), or the push needs a deploy key.
+
+**Behind a ruleset** that asks for a pull request or status checks on the branch, the push with the
+`GITHUB_TOKEN` is refused (`GH013: Repository rule violations`), and the token cannot be put on the
+ruleset's bypass list. A deploy key can:
+
+1. `ssh-keygen -t ed25519 -N "" -C bump -f bump` on any machine.
+2. *Settings → Deploy keys → Add deploy key*: the content of `bump.pub`, *Allow write access*.
+3. *Settings → Secrets and variables → Actions*: a secret `BUMP_DEPLOY_KEY` with the content of `bump`.
+4. The ruleset's *Bypass list*: *Deploy keys*, *Always*. Then delete both files.
+5. In `bump.yml`, next to `with:`:
+
+   ```yaml
+       secrets:
+         deploy-key: ${{ secrets.BUMP_DEPLOY_KEY }}
+   ```
+
+A push with the deploy key starts `on: push` workflows like one from a checkout: the release
+workflow then starts on the tag by itself (it needs `on: push: tags`), and the release commit runs
+the CI on the branch.
 
 ## GitHub release