fix: report new version when commit is false and no version files update#114
Open
bearomorphism wants to merge 1 commit intocommitizen-tools:masterfrom
Open
Conversation
`outputs.version` is sourced from `cz version --project` after the bump. When `commit: false` is combined with a `version_provider` that does not write to any tracked file (notably `version_provider = "scm"`), the bump does not update any version file and does not create a git tag, so `cz version --project` keeps reporting the previous version. The action then exposes the old version on `outputs.version`, `outputs.next_version` and the major/minor variants, even though the bump command itself printed `bump: version X -> Y` correctly. Capture the next version with `cz bump --get-next` before running the actual bump (it is a calculation, no state change), and use it as a fallback when `cz version --project` still equals the previous version after the bump. Major/minor are derived from the same value so they match. Failures of `--get-next` (e.g. no bumpable commits) are tolerated and leave the existing behaviour untouched. Closes commitizen-tools#94 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2d07d6e to
b83b888
Compare
6 tasks
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.
Why
outputs.version(andnext_version,next_version_major,next_version_minor) are sourced fromcz version --projectafter the bump runs. That works fine when the bump updates a
tracked version file or creates a tag.
When
commit: falseis combined with aversion_providerthatdoes not write to any tracked file -- notably
version_provider = ""scm""-- the bump:commit: falseimplies nobump commit, and without a commit there is nothing to tag).
So
cz version --projectkeeps reporting the previous version,even though
cz bumpitself printedbump: version X -> Ycorrectly. The action then exposes the old version on every
version-shaped output, defeating the documented use case in #94of running the action purely to compute the next version (no commit,
no push) for downstream steps.
What
Capture the would-be next version with
cz bump --get-nextbeforerunning the actual bump.
--get-nextis a pure computation -- itdoes not change any state -- so it is safe to run as a second pass.
Reuse the same
CZ_CMDarray (minus--changelog/--changelog-to-stdout) so the captured value honours--increment,--prerelease,--build-metadata, etc.After the bump, if
cz version --projectstill equals the previousversion and
--get-nextproduced a different version, fall backto the captured value for
version,next_version,next_version_majorandnext_version_minor. Major and minor areparsed from the captured version string so they match.
If
--get-nextitself fails (e.g. no commits eligible to bump,exit 21) the captured value stays empty and the fallback is skipped,
preserving today's behaviour for that case.
How
Surgical change to
entrypoint.shonly, no input/output schemachanges:
CZ_CMDis fully built and before the actual bump runs,build a filtered
GET_NEXT_CMDthat drops--changelogand--changelog-to-stdout(see Compatibility note below), thencompute
NEXT_REV_PRE="$("${GET_NEXT_CMD[@]}" --get-next 2>/dev/null || true)".REV,NEXT_REV_MAJORandNEXT_REV_MINORfromcz version --projectas before, thenoverride them with the captured value when
REV == PREV_REVand a non-empty different
NEXT_REV_PREis available.Compatibility note:
--get-next+--changelogIn commitizen < 4.10.1,
--get-nextcombined with--changelogor
--changelog-to-stdoutraisesNotAllowed(commitizen-tools/commitizen#1640). Since the action defaults to
commitizen_version: latestbut allows pinning to older releases,the simplest forward- and backward-compatible solution is to strip
those two flags before calling
--get-next.--get-nextdoesnot produce a changelog regardless, so the flags have no effect on
the captured value. In commitizen >= 4.10.1 (commitizen-tools/commitizen#1645)
they are tolerated as no-op warnings; the strip keeps the action's
log output clean as a side benefit.
Verification
Repro on a fresh test repo with one
feat:commit and the user'sconfig (
version_provider = ""scm""), simulating the relevantsection of
entrypoint.shwithcommit: false:Before (current
master):After this fix:
I also re-checked the other cases:
commit: true(default) with file-based version_provider -- bumpupdates
.cz.tomland creates a commit, socz version --projectalready reflects the new version, the fallback condition
REV == PREV_REVis false, and behaviour is unchanged.commit: falsewith file-based version_provider ----files-onlyupdates
.cz.toml,cz version --projectreturns the newversion, fallback also skipped.
--get-nextexits with empty stdout,fallback skipped,
INPUT_PUSHis still set tofalseas today.Closes #94