Skip to content

fix: report new version when commit is false and no version files update#114

Open
bearomorphism wants to merge 1 commit intocommitizen-tools:masterfrom
bearomorphism:fix/94-output-version-with-commit-false
Open

fix: report new version when commit is false and no version files update#114
bearomorphism wants to merge 1 commit intocommitizen-tools:masterfrom
bearomorphism:fix/94-output-version-with-commit-false

Conversation

@bearomorphism
Copy link
Copy Markdown

@bearomorphism bearomorphism commented May 10, 2026

Why

outputs.version (and next_version, next_version_major,
next_version_minor) are sourced from cz version --project
after the bump runs. That works fine when the bump updates a
tracked version file or creates a tag.

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 (scm reads version from git tags),
  • does not create a git tag (since commit: false implies no
    bump commit, and without a commit there is nothing to tag).

So cz version --project keeps reporting the previous version,
even though cz bump itself printed bump: version X -> Y
correctly. The action then exposes the old version on every
version-shaped output, defeating the documented use case in #94
of 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-next before
running the actual bump. --get-next is a pure computation -- it
does not change any state -- so it is safe to run as a second pass.
Reuse the same CZ_CMD array (minus --changelog /
--changelog-to-stdout) so the captured value honours
--increment, --prerelease, --build-metadata, etc.

After the bump, if cz version --project still equals the previous
version and --get-next produced a different version, fall back
to the captured value for version, next_version,
next_version_major and next_version_minor. Major and minor are
parsed from the captured version string so they match.

If --get-next itself 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.sh only, no input/output schema
changes:

  1. After CZ_CMD is fully built and before the actual bump runs,
    build a filtered GET_NEXT_CMD that drops --changelog and
    --changelog-to-stdout (see Compatibility note below), then
    compute NEXT_REV_PRE="$("${GET_NEXT_CMD[@]}" --get-next 2>/dev/null || true)".
  2. After the bump, populate REV, NEXT_REV_MAJOR and
    NEXT_REV_MINOR from cz version --project as before, then
    override them with the captured value when REV == PREV_REV
    and a non-empty different NEXT_REV_PRE is available.

Compatibility note: --get-next + --changelog

In commitizen < 4.10.1, --get-next combined with --changelog
or --changelog-to-stdout raises NotAllowed
(commitizen-tools/commitizen#1640). Since the action defaults to
commitizen_version: latest but allows pinning to older releases,
the simplest forward- and backward-compatible solution is to strip
those two flags before calling --get-next. --get-next does
not 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's
config (version_provider = ""scm""), simulating the relevant
section of entrypoint.sh with commit: false:

Before (current master):

PREV_REV=0.0.0
bump: version 0.0.0 -> 0.1.0
tag to create: 0.1.0
increment detected: MINOR
Post-bump: REV='0.0.0' MAJOR='0' MINOR='0'
=== Final outputs ===
version=0.0.0
next_version_major=0
next_version_minor=0

After this fix:

PREV_REV=0.0.0
CZ_CMD: cz --no-raise 21 bump --yes --changelog --files-only
GET_NEXT_CMD: cz --no-raise 21 bump --yes --files-only
NEXT_REV_PRE='0.1.0'
bump: version 0.0.0 -> 0.1.0
tag to create: 0.1.0
increment detected: MINOR
Post-bump: REV='0.0.0' MAJOR='0' MINOR='0'
Fallback applied!
=== Final outputs ===
version=0.1.0
next_version_major=0
next_version_minor=1

I also re-checked the other cases:

  • commit: true (default) with file-based version_provider -- bump
    updates .cz.toml and creates a commit, so cz version --project
    already reflects the new version, the fallback condition
    REV == PREV_REV is false, and behaviour is unchanged.
  • commit: false with file-based version_provider -- --files-only
    updates .cz.toml, cz version --project returns the new
    version, fallback also skipped.
  • No bumpable commits -- --get-next exits with empty stdout,
    fallback skipped, INPUT_PUSH is still set to false as today.

Closes #94

`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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

outputs.version is set only if commit is true

1 participant