fix: version determination of 4 branch GitFlow repo

[ZionStage]

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 !

[codejedi365]

@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.

[ZionStage]

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

[codejedi365]

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

[ZionStage]

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.

[codejedi365]

@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!

[ZionStage]

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 !

[codejedi365]

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.

[mac-vtl]

Hi @codejedi365, facing the exact same issue. I've tried your fix in https://github.com/codejedi365/python-semantic-release/commit/7f65a78ee00fa1493fe12538a821f0d10895f628 and it was able to correctly compute the next version as expected. Do you know when you will be able to release the fix? thanks

[codejedi365]

Do you know when you will be able to release the fix?

Hi @mac-vtl, thanks a bunch for validating my fix worked for you. As for when it will be released, I got a bit stuck with the testing earlier. I want to validate that it doesn't break other git branching strategies before release. I'll circle back around to this fix and see if I can get it in over the next two months. Hopefully sooner than later but life has thrown me a curve ball and my time is limited at the moment.

[jbw-vtl]

Hey, we are also quite keen on this feature to enable some of our more advanced CI cases. Is there something we can help in validating this feature?

[codejedi365]

@jbw-vtl, thank you for being willing to help. I've just been very busy and unable to put much time into this project for the past month.

I believe the fix resolves the merge commit to separate release branch problem as it adds a filter to only match on prereleases of the same token rather than all prereleases within the HEAD's ancestry.

I have not thought through all the alternative branching strategies nor finished the test case for a 4x release branch Git Flow branching strategy. So as of this time it's more of a comfort level that it doesn't break other things. And while doing that most of the other test cases don't have any merge commits which makes me more worrisome. That's what I have been working on in a different branch as the precursor to this resolution.