python-semantic-release icon indicating copy to clipboard operation
python-semantic-release copied to clipboard

multibranch release version incorrectly incremented

Open intex46 opened this issue 1 year ago • 7 comments

The problem

Hello , i have an issue with the incrementation of the patch version from pre-release to release using azure devops pipeline

Expected behavior

v0.3.0-rc.1 -> v0.3.0 -> (push fix commit en develop branch) v0.3.1-rc.1 -> (push en main)v0.3.1

Actual behavior

v0.3.0-rc.1 -> v0.3.0 -> (push fix commit en develop branch) v0.3.0-rc.2 -> (push en main)v0.3.1

Environment

ubuntu-latest

python --version
3.10.13 x64
pip --version
semantic-release --version
8.5.2
pip freeze

Python build tool(s) : pdm version 2.11.2

Configuration

pyproject.toml:

[tool.semantic_release]
logging_use_named_masks = true
tag_format = "v{version}"
commit_parser = "angular"
commit_message = "chore(release): release v{version} [skip ci]"
remove_dist = true
[tool.semantic_release.remote]
domain = "dev.azure.com"

[tool.semantic_release.branches.main]
match = "main"
prerelease = false

[tool.semantic_release.branches.develop]
match = "develop"
prerelease = true
prerelease_token = "rc"

[tool.semantic_release.branches.feature]
match = "^feature/"
prerelease = true
prerelease_token = "alpha"

[tool.semantic_release.changelog]
exclude_commit_patterns = [
    "^wip :.*",  # Exclude commits that start with "wip :"
    "^Merged PR.*", # Exclude Pull Request commits

]

[build-system]
requires = ["pdm-backend"]
build-backend = "pdm.backend"

dynamic = ["version"]
[tool.pdm.version]
source = "scm"

command :

semantic-release -vv version --push --no-vcs-release

intex46 avatar Feb 14 '24 18:02 intex46

@intex46, please provide the output (pip freeze & the semantic release stdout/stderr) to the commands above.

codejedi365 avatar Feb 15 '24 01:02 codejedi365

With my initial review I believe this is the same root cause as #789, which a fix is identified but under testing.

If you can provide a tree graph of the git repo that would be best. Make sure to include the 1 commit before the 0.3.0-rc.1.

git log --graph --decorate --oneline --all

codejedi365 avatar Feb 15 '24 02:02 codejedi365

hello @codejedi365, thanks for your feedback, i think i have the same issue that you mentioned, do you think that the fix will be integrate soon ? many thanks for your support

intex46 avatar Feb 16 '24 14:02 intex46

Likely in over the next month, I haven't quite completed the changelog testing overhaul that is the predecessor to ensuring this functionality is complete

codejedi365 avatar Feb 17 '24 02:02 codejedi365

Hello,

I have the same problem except I work with trunk base method and my releases are based on tag and not on a specific branch.

My configuration :

Python 3.12.3
git version 2.43.0
semantic-release, version 9.6.0

My git history:

* 0c9a615 (HEAD -> main, tag: 0.1.5, origin/main, origin/HEAD) chore(release): 0.1.5
* 20eec6c (tag: 0.1.4-beta.3) chore(release): 0.1.4-beta.3
* 7fb9f9d build: @2566 generate a build type commit before 0.1.4-beta.3 and 0.1.5 release
* c70b2d0 chore: @2566 generate a 0.1.4-beta.3 and 0.1.5 release
* c89e281 (tag: 0.1.4-beta.2) chore(release): 0.1.4-beta.2
* 37128a2 chore: @2566 generate a 0.1.4-beta.2
* 3341f10 (tag: 0.1.4-beta.1) chore(release): 0.1.4-beta.1
* 0a1ffcd chore: @2566 try to generate 0.1.5-beta.1
* 921d4ab (tag: 0.1.4) chore(release): 0.1.4
* a6fba3a (tag: 0.1.3-beta.2) chore(release): 0.1.3-beta.2
* 02c6f84 ci: @2566 fix ref project
* 1377009 ci: @2566 test with new release semantic image
* 66a43b4 (tag: 0.1.3) chore(release): 0.1.3
* fae672f (tag: 0.1.3-beta.1) chore(release): 0.1.3-beta.1

Regards.

JeromeCheviet avatar May 06 '24 14:05 JeromeCheviet

@JeromeCheviet, would you mind opening a new issue for your scenario? This issue and root cause is related specifically to multi-branch releases and merge handling which will not influence your results with a trunk based development strategy. Thank you for including your git history but I will also need your config, the command and log.

Let's copy the below answer to your new issue:

Initially looking at your git history, it looks like PSR is behaving as expected if the commits are parsed with the AngularParser (ie. Conventional Commit standard). build and chore do not trigger a version bump unless otherwise configured. By default only a fix and perf commit type trigger a patch bump.

Separately, I'm not sure what you meant by the statement: releases are based on tag and not on a specific branch. PSR selects the prerelease token & prerelease value and whether or not it should release based on which branch it is on. Common usage of trunk based developers use the default branch to release or use ReleaseFlow branching to have separate branches to perform releases. Ultimately though, PSR will not automatically be able to determine if it should be a prerelease or a regular release if you are releasing these from the same branch. Manual intervention via command line arguments can make this possible.

codejedi365 avatar May 07 '24 12:05 codejedi365