Chore: derive base release version from git tag instead of hardcoded YAML - #329
Merged
Conversation
…YAML The base version (3.3.4) was hardcoded in two spots of build_v3.yml, so bumping it required editing the workflow and landing that number into both eros-develop and eros through dedicated version-bump PRs. Resolve the base version at build time from the highest strictly-vX.Y.Z tag reachable from the building branch (git tag --merged + strict regex + version sort), falling back to VERSION_FALLBACK before any base tag exists. run_number stays the build counter, so the per-build release tags keep their X.Y.Z-develop.N / X.Y.Z-release.N shape that the updater parses. Assembly version becomes a prepare-job output threaded into the build action as a new assembly_version input. Bumping a version is now a single tag push (git push origin vX.Y.Z); no YAML edit and no version-bump PRs. deploy.yml is unchanged.
|
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
1 participant
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.
Database Migration
NO
Description
Moves the base release version out of
build_v3.yml. Today3.3.4is hardcodedin two spots (
VERSIONandWHISPARR_ASSEMBLY_VERSION), so bumping it meansediting the workflow and landing that number into both
eros-developanderosvia dedicated version-bump PRs.
Instead, the
preparejob now resolves the base version at build time from thehighest strictly-
vX.Y.Ztag reachable from the building branch(
git tag --merged HEAD+ strict^v[0-9]+\.[0-9]+\.[0-9]+$regex + versionsort), falling back to
VERSION_FALLBACK(3.3.4) until a base tag exists. Thestrict regex is deliberate: it rejects both the CI-minted
-develop.N/-release.Ntags and the ~370 legacy 4-part
vX.Y.Z.Btags inherited from upstream (glob /git describecan't separate 3-part from 4-part).git run_numberstays thebuild counter, so the per-build release tags keep their
X.Y.Z-develop.N/X.Y.Z-release.Nshape that the client updater parses — no client-facing change.The assembly version becomes a
prepareoutput threaded into the build action asa new
assembly_versioninput.deploy.ymlis unchanged; it keeps minting andGPG-signing the per-build release tags exactly as before.
Result: bumping a version is a single
git push origin vX.Y.Z— no YAML edit andno version-bump PRs. Branch-based triggering, the dual-branch layout, and the
eros-develop→erospromotion PR all stay as they are.Because no base tag exists yet, this build (and every build until a
vX.Y.Ztagis pushed) resolves the
3.3.4fallback and produces the same3.3.4-develop.Nversion string as today — the cutover is silent and only diverges once a marker
tag is pushed.
Screenshot(s) (if UI related)
N/A — CI workflow change, no UI.
Todos
shell was validated locally under
bash -eo pipefail(no-match → fallback;match → highest by numeric sort with minted/legacy tags excluded), and the
workflow passes
actionlint(incl. shellcheck on therun:block).Issues Fixed or Closed by this PR
N/A