Repository navigation
feat(version): add force-stable and create-rc-baseline inputs - #24
Merged
Merged
Conversation
Two new opt-in inputs on the reusable version.yml workflow, both defaulting to preserve current behaviour so existing consumers are byte-identical. - force-stable (default false): when true, non-default branches skip the --prerelease --maintained-version flags and cut a stable release the same way the default branch does. Enables a "dev cuts the version, default branch rubber-stamps the deploy" model where the RC line is not maintained. - create-rc-baseline (default true): gates the "Create next RC baseline" step on the default branch. Set to false when the RC line is not maintained (typically alongside force-stable=true on the RC-side workflow), preventing orphan vX.Y.0-rc.1 tags from piling up. Backwards-compatible minor change — no consumer needs to update inputs.
The condition-github plugin refuses a non-default branch with "configured to only publish from <default>" unless the config passed to it says otherwise. Semrel's main.go forwards repoInfo.DefaultBranch (fetched from the GitHub API) as the ci-condition's defaultBranch by default; the previous force-stable path didn't override it, so semrel exited with code 66 before cutting the tag. Fix: pass --ci-condition-opt "defaultBranch=$CURRENT_REF" when force-stable=true on a non-default branch. This makes the condition see branch==defaultBranch and proceed. The RC prerelease path was implicitly relying on --maintained-version setting defaultBranch to "*" inside semrel core, so it didn't need this workaround. Verified failure: ago-web-frontend run 32020117652 exited at the ci condition step with the "only publish from main" error.
Contributor
Author
|
Follow-up commit (eb22969) on Bug: Fix: when |
In the rubber-stamp release model, the default branch merges an already-tagged branch and semrel correctly exits with "no change" (the release exists via GH API lookup, no new bump needed). Downstream build/deploy/announce steps that fall back to \`git describe\` when outputs.version is empty can pick the WRONG tag: rev-list distance between HEAD and the actual latest tag can be huge across a divergent merge (all the docs: changelog auto-commits + hotfix merges on the default branch that aren't reachable from the tag's commit). Fix: opt-in input that populates outputs.version from GH's release list on no-op, using the same source semrel uses when it looks up the "latest release". Callers set expose-latest-on-noop: true on the default-branch's version job to guarantee outputs.version reflects the actual latest stable release, not whatever git describe returns. Default false preserves existing behaviour for all consumers. Verified failure: AmericanGunOwners/ago-web-frontend PR #645 merge — main pipeline no-oped correctly, but git describe returned v1.17.0 (6 commits away via first-parent) instead of v1.18.0 (58 commits away by rev-list distance, but only 1 hop via second-parent). Prod /version.json ended up stamped 1.17.0 despite v1.18.0 being the actual latest release.
gamechanger1s
force-pushed
the
feat/version-stable-mode
branch
from
August 17, 2026 11:24
4a4a6d4 to
0bdf9ba
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Three new opt-in inputs on
.github/workflows/version.yml, all defaulting to preserve current behaviour:force-stable(defaultfalse) — whentrue, non-default branches cut a stable release instead of a-rc.Nprerelease. Passes--ci-condition-opt "defaultBranch=<current-ref>"so semrel'scondition-githubplugin accepts the non-default branch.create-rc-baseline(defaulttrue) — gates the existing "Create next RC baseline" step on the default branch. Set tofalsewhen the RC line is no longer maintained (typical sibling toforce-stable: trueon the RC-side workflow).expose-latest-on-noops(defaultfalse) — when semrel exits with no new release (rubber-stamp merges where the tag already exists), populateoutputs.versionfromgh release listinstead of leaving it empty. Prevents downstream build/deploy/announce steps from falling back to a stalegit describeresult across divergent merges.Why
Support a "non-default branch owns version cutting, default branch rubber-stamps deploy" release model — one SemVer number per deployable artifact, born on the RC branch and consumed by the default branch. Today
version.ymlhardcodes--prereleaseon non-default branches, RC baseline seeding on the default branch, and only exposes a version when a new tag is cut. None can be opted out of. These three inputs let a caller adopt the model without changing anything for existing consumers.Verified
Piloted end-to-end on a downstream consumer:
force-stable: true.found version: <tag>/no change) — rubber-stamp confirmed.condition-githubguard for non-default branches (needed--ci-condition-opt).expose-latest-on-noopsaftergit describereturned the wrong tag on the default-branch merge commit (closer by rev-list distance than the actual latest tag on the divergent branch).