Skip to content

fix: make the release dispatch ask which bump it wants (ENG-9233) #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
johnsca merged 1 commit into from
Oct 20, 2026
Merged

fix: make the release dispatch ask which bump it wants (ENG-9233) #5

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 0 additions & 14 deletions .github/workflows/cut-release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -111,20 +111,6 @@ jobs:
echo "| Dry run | ${DRY_RUN} |"
} >> "${GITHUB_STEP_SUMMARY}"

# Only fires on the first release, where the baseline is 0.0.0. A patch
# from there lands v0.0.1 permanently, so this is enforced rather than
# left to the input description. Reads `previous_version` rather than
# `previous_tag`, which carries the action's tag prefix and would make
# this a second copy of a default owned elsewhere.
- name: Require the first release to be major
if: ${{ steps.version.outputs.previous_version == '0.0.0' && inputs.bump != 'major' }}
env:
BUMP: ${{ inputs.bump }}
run: |
echo "This repository has no releases yet, so the first one has to be a" >&2
echo "major bump to land v1.0.0. This run asked for ${BUMP}." >&2
exit 1

publish:
needs: version
# `success()` is implicit here, and it is what keeps the version job's
Expand Down
4 changes: 2 additions & 2 deletions .github/workflows/release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,11 +4,11 @@ on:
workflow_dispatch:
inputs:
bump:
description: Which part of the version to raise. The first release has to be major, because the count starts from 0.0.0.
description: Which part of the version to raise.
required: true
type: choice
default: patch
options:
- (choose one)
- patch
- minor
- major
Expand Down
12 changes: 8 additions & 4 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -63,11 +63,11 @@ on:
workflow_dispatch:
inputs:
bump:
description: Which part of the version to raise. The first release has to be major, because the count starts from 0.0.0.
description: Which part of the version to raise.
required: true
type: choice
default: patch
options:
- (choose one)
- patch
- minor
- major
Expand Down Expand Up @@ -95,8 +95,12 @@ jobs:

The workflow refuses to run against anything but the calling repository's default
branch, refuses any re-run of a run it has already started, and refuses to publish over
a tag it did not create. A retry means dispatching again. The first release has to be a major bump, because the version
walk starts from 0.0.0 and a patch from there spends `v0.0.1` permanently.
a tag it did not create. A retry means dispatching again.

The `bump` dropdown opens on `(choose one)`, which the workflow rejects. The version
walk starts from 0.0.0, so on a repository with no tags patch opens at `v0.0.1`, minor
at `v0.1.0` and major at `v1.0.0`. Which of those a repository wants is its own call,
so the workflow asks rather than assumes.

`STEP_SECURITY_API_KEY` is optional. Without it the Harden Runner step is skipped and
the rest runs unchanged.
Loading