diff --git a/.github/workflows/bump-version.yml b/.github/workflows/bump-version.yml index 8ad9dea..f636600 100644 --- a/.github/workflows/bump-version.yml +++ b/.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" diff --git a/.github/workflows/tested-on-main.yml b/.github/workflows/tested-on-main.yml index 4f1ff9e..a77a243 100644 --- a/.github/workflows/tested-on-main.yml +++ b/.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 diff --git a/README.md b/README.md index 202fcd0..f2a5742 100644 --- a/README.md +++ b/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