Incorrect semver calculation after failed release pipeline

Question

Incorrect semver calculation after failed release pipeline

roulettedares opened this issue 2 years ago · 5 comments

If a release pipeline fails after the next-version but before the promote-changelog step, the new github tag has been pushed, but the new Github release is not created. This can lead to issues where jx-release-version cannot determine the correct semver during subsequent release pipelines.

for example:

Github tag v0.4.1 was created at the beginning of a release pipeline, but the pipeline failed because of an intermittent artifactory issue before the Github release was created
dev files a new unrelated pr with the commit message "feat: Add new endpoint to get xyz"
new PR is merged
during the release pipeline, jx-release-version sets VERSION to 0.4.2 instead of 0.5.0. no interesting logs
promote-changelog creates release notes for Github release v0.4.2 instead of 0.5.0

Is this something to do with the way the jx-release-version auto strategy determines the previous git tag? Would it fail in this scenario if the Github release for v0.4.1 didn't exist?

Expected - Increment minor version (0.5.0)
Actual - Incremented patch version(0.4.2)

Answer 1 · 2022-09-12T22:22:29.000Z

What version of jx-release-version is used?

Does the changelog contain the commit message "feat: Add new endpoint to get xyz"?

Would it fail in this scenario if the Github release for v0.4.1 didn't exist?

No. Unless you configure it otherwise jx-release-version only cares about the the value of the tag representing the highest semantic version.

Answer 2 · 2022-09-12T23:11:36.000Z

What version of jx-release-version is used?
ghcr.io/jenkins-x/jx-release-version:2.5.2

jx-release-version --version
Version 2.5.2 - Revision '83784a8' - Date '20220525-06:46:35'

Does the changelog contain the commit message "feat: Add new endpoint to get xyz"?

The first commit in the PR is titled 'feat: Add new endpoint to get a xyz'. Here's a list of the commits in the PR:

Commits on Jul 13, 2022

feat: Add new endpoint to get a xyz
@Dev2
dev2 committed on Jul 13

Commits on Jul 15, 2022

Merge branch 'main' of https://github.com/my-org/my-app in…
@Dev2
dev2 committed on Jul 15

preparing changes for dev1's merge
@Dev2
dev2 committed on Jul 15

Merge branch '3625-POST-xyz' of https://github.com/j…
@Dev2
dev2 committed on Jul 15

Adding changes after merging with the refactoring of zyxOn…
@Dev2
dev2 committed on Jul 15

Commits on Jul 26, 2022

Merge branch 'main' of https://github.com/my-org/my-app in…
@dev1
dev1 committed on Jul 26

Commits on Jul 29, 2022

feat: 3626-GET-xyz
@dev1
dev1 committed on Jul 29

Commits on Aug 1, 2022

feat: 3626-GET-xyz
@dev1
dev1 committed on Aug 1

Merge remote-tracking branch 'origin/3626-xyz' i…
@dev1
dev1 committed on Aug 1

Commits on Aug 3, 2022

feta: 3626-GET-xyz
@dev1
dev1 committed on Aug 3

Merge remote-tracking branch 'origin/3626-xyz' i…
@dev1
dev1 committed on Aug 3

Commits on Aug 9, 2022

Merge remote-tracking branch 'origin/3626-xyz' i…
@dev1
dev1 committed on Aug 9

Commits on Aug 10, 2022

Merge remote-tracking branch 'origin/3626-xyz' i…
@dev1
dev1 committed on Aug 10

Answer 3 · 2022-09-12T23:21:15.000Z

Since this issue was initally filed, we have another example of a PR containing 2 "feat: " prefixed commits that trigged a patch version increment (0.5.4) instead of a minor version increment (0.6.0). the common denominator is that there are 26 other commits in the pull request which are not semantic. ex:
Merge remote-tracking branch 'origin/3626-xyz' i…

Maybe the behaviour that I am seeing has something to do with the interaction parseCommitsSince has with a large number of merge commits in the PR.