No commits found to generate a pre-release #415
Description
Activity
Thanks for reporting! This seems to be designed this way. See if this comment helps. #307 (comment)
Ok, I see the issue at hand.
Our intention is to generate pre-releases automatically from the master branch in CI. If there are no corresponding changes it should just not do anything. Since we rely on commitizen to determine the kind of bump, it would be problematic to explicitly configure the increment.
hmmmm
@woile I kinda don't get the idea of the original design. Would there be any issue if we check the pre-release commits as usual?
Hmm ... I am not sure yet.
If any release (alpha, beta, rc, prod) would bump the version if and only if there is a version increasing commit then we would not have a problem, no?
I kinda expect the following behaviour when there is no version increasing commit:
alpha -> alpha: do nothing alpha -> beta: only create beta tag alpha -> rc: only create rc tag alpha -> release: only create relase tag beta -> alpha: do nothing beta -> beta: do nothing beta -> rc: only create rc tag beta -> release: only create release tag rc -> alpha: do nothing rc -> beta: do nothing rc -> rc: do nothing rc -> release: only create release tag release -> alpha: do nothing release -> beta: do nothing release -> rc: do nothing release -> release: do nothingBasically we need to consider the different types of releases in a hierarchical order and only create a tag when we increase the level of release. And we'll never increase the version if there is not version increasing commit.
I think it's quite common to first release something as RC and later release the same code as release. 🤔
Does this make sense?
Reacted by Nils Brugger, joan-ll, Axel Wegener and Henry DobsonHi,
i basically run into the same issue (not being able to release a RC as PROD).
Is there a recommended workflow/workaround to go from RC to PROD without commits in between?Thanks
Triage from #1964: Reviewed against master (4.15.1). The current behavior in
commitizen/commands/bump.py(lines 217-225) still raisesNoCommitsFoundErrorwhen--prereleaseis given without bumpable commits and the current version isn't already a prerelease. This appears to be intentional (the workaround is--increment). Marking as a long-standing design choice — closing recommended unless someone wants to change the default.Verification update (re #1964)
Reproduced against current master (4.15.1):
Starting from
v1.2.1with only aci: tweakcommit:cz bump --dry-run→ exits 21 with[NO_COMMITS_TO_BUMP] The commits found are not eligible to be bumpedcz bump --prerelease rc --dry-run→ exits 3 with[NO_COMMITS_FOUND] No commits found to generate a pre-release. To avoid this error, manually specify the type of increment with--increment``
Verdict: STILL VALID — the asymmetric behavior reported in 2021 still exists today.
The two exit codes / messages aren't quite parity:
- Without
--prerelease, you getNO_COMMITS_TO_BUMP(21). - With
--prerelease, you getNO_COMMITS_FOUND(3) — a different error.
This is documented behavior in
commitizen/commands/bump.py:217-225, and arguably intentional (prerelease forces a decision; you can use--incrementto override). But two valid changes worth considering:- Make both paths exit with the same code (21) since semantically both mean "nothing to bump".
- When
--prereleaseis given but the current version isn't already a prerelease and there are no eligible commits, fall through to the sameNoneIncrementExitbranch rather than the specialNoCommitsFoundError.
Closely related to #688.
Description
cz bump --prerelease rcshould handle missing "bumpable" commits the same way ascz bump.Steps to reproduce
ciorbuild)cz bump --prerelease rc --dry-runCurrent behavior
The command terminates with an error:
Desired behavior
It should behave like running
cz bumpwithout--prereleaseflag.Environment