fix: version determination of 4 branch GitFlow repo

Hello everyone (and a happy new year to all),

I have been using python-semantic-release for 2 months now, and I still encounter problems setting it up for my current work flow.

I have a python package with 3 main branches (main, beta and development) and some feature branches (feat-*). I need to have a dependable versioning system on all these branches in order to generate a front end client in the CI. My workflow is as is :

For a new feature, create a feature branch from development
Iterate on this feature branch until everything works
Merge on development
[Optional] repeat with as many features as needed
Merging development into beta
When ready for production, merging beta into main
Merging main into beta and beta into development

I have the following conf file :

[tool.semantic_release]
version_toml = [
    "pyproject.toml:project.version",
]
commit_message = "Bump to {version} [skip ci]\n\nAutomatically generated by python-semantic-release"

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

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

[tool.semantic_release.branches.development]
match = "development"
prerelease = true
prerelease_token = "alpha"

[tool.semantic_release.branches.features]
match = "^feat-.*$"
prerelease = true
prerelease_token = "dev"

When creating a feature branch the versioning works well, however as soon as I merge into development and merge development into beta I run into some versioning problems.
Sometimes even if I'm on beta the output version is tagged alpha, sometimes the output version does not have a pre-release token.
Obviously, there's something wrong with my configuration for my workflow, but I can't seem to pinpoint what it is even after reading the whole docs. So here are my questions :

Can python-semantic-release work with the workflow I described ?
If so, what am I missing ?

Thank you !

@ZionStage

@ZionStage, Thank you for submitting your issue. I believe your branching strategy is almost exactly the Git Flow strategy with a slight variation to include a separate beta branch. Python Semantic Release is built to support Git Flow so the answer to your first question is yes, your workflow is supported. At first glance, I do believe your configuration file is also correct and complete.

The downside, Git Flow is a fairly complex workflow and we may not be covering all scenarios. In fact, as I was just yesterday refactoring the testing code for angular style repository scenarios, and the current testing does not cover merges of Git Flow branches. This gap in test coverage could have some bugs in it that you are experiencing.

To help isolate the problem further, can you provide the output log of one such circumstance where it creates the version with the wrong token but with debug level verbosity enabled. The option is -vv. You should be able to go to the commit directly and execute semantic-release -vv version --print. The output should be descriptive of how it interprets the tags of the repository.

Secondly, if you can confirm that you are using the included angular parser? If not, please specify which included parser or provide the code for your custom parser.

Lastly, what is your merging strategy? I suspect it is just merge --no-ff but if it is squash or rebase and merge, that could cause different outcomes. If you don't know, it would be helpful if you could take a snapshot of your git repo in graph form, which you can do with VSCode's Git Graph Extension, or in the terminal with git log --graph --decorate --oneline --all --topo-order. With the snapshot, please make sure to isolate the area where an incorrect tag was created.

@codejedi365

Hi @codejedi365, thanks for your quick answer

Here is an example of something I don't quite understand with the implemented logic. I just merged development into beta. The last tag of development is 1.2.0-alpha.5 and the last tag of 1.2.0-beta.2. What I would expect after the merge on beta is the creation of the tag 1.2.0-beta.3 yet the algorithm outputs 1.2.0-alpha.5. I provided the logs in this version_output.log file.

The parser I use is the included angular parser indeed, I did not change anything concerning the parser, and it is the default parser from what I understand.

As for my merging strategy, it is just merge. At first, I thought that squashing was a good idea, but it leads to more unexpected behavior, so we decided to start over again with a simple merge.

Here's the tip of the git graph I have.

Let me know if there are still some gray zones or if you need me to provide more info

That definitely sounds like the incorrect version determination. Thank you for the info, I didn't find anything yet but should have some time tomorrow. Would you be able to run the version determination again without the latest incorrect version? Right now it is hard to tell since it thinks it evaluated correctly and no new version is required

Steps:

clone repo into /tmp
Checkout beta branch at merge: git checkout -B beta v1.2.0-alpha.5
Delete tag: git tag -d v1.2.0-alpha.5
Execute version determination in debug mode semantic-release -vv version --print > next_beta_version.log

Of course, no problem. I followed your steps and here are the resulting logs : next_beta_version_stderr.log

Just so you know, I created a feature branch from development for a new feature. I just finished it today and the last version is v1.2.0-dev.1+feat-shelves.
I just happened to merge it into development and I get the same issue: next_dev_version_stderr.log

Here's the git tree.

@ZionStage

@ZionStage, The logs along with the picture were really helpful. I pieced apart logs to identify the flawed decision. Will start reviewing the code for optimizations and improvements. It seems to not to fully evaluate merges but only walks down the latest parent chain of commits until it reaches a tag and stops. It forgets to look down the beta branch for tags, and it also forgets to use the prerelease token configuration that it previously identified for the beta branch.

Lots of unintended behavior, thank you for bringing this to our attention!

Glad to know this was helpful to you.
Let me know if you want me to test some WIP when you have some time to tackle this.

Have a nice one !

Just for an update on this, I believe I have found a fix, I'm working on building a test case to prevent regression however it is taking a bit longer fitting into the newer test structure.

fix(algorithm): handle multiple prerelease token variants properly

Should be accomplished and released over the next week

fix(algorithm): handle multiple prerelease token variants properly

fix(cmd-version): handle multiple prerelease token variants properly

fix(cmd-version): fix handling of multiple prerelease token variants …

🎉 This issue has been resolved in version 9.15.2 🎉

The release is available on:

Navigation Menu

Repository navigation

fix: version determination of 4 branch GitFlow repo #789

19 remaining items

🎉 This issue has been resolved in version 9.15.2 🎉

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

fix: version determination of 4 branch GitFlow repo #789

Description

Activity

codejedi365 commented on Jan 2, 2024

ZionStage commented on Jan 3, 2024

codejedi365 commented on Jan 4, 2024

ZionStage commented on Jan 4, 2024

codejedi365 commented on Jan 4, 2024

ZionStage commented on Jan 5, 2024

codejedi365 commented on Feb 9, 2024

19 remaining items

codejedi365 commented on Dec 5, 2024

codejedi365 commented on Dec 16, 2024

🎉 This issue has been resolved in version 9.15.2 🎉

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions