Very strange behaviour when merging branches

[igordertigor]

The problem

When working with a team, different team members typically work on branches and merge their work afterwards. Semantic release appears entirely confused by this pattern and either does not find it's own past versions (see example below) or skips over the commits inside the merged branch. I observed this behaviour with v7.x.x and wasn't able to even get my (offline) example to work with v8.x.x. For semantic-release 8.x.x it appears impossible to test anything out locally (or I just didn't find it in the documentation).

Expected behavior

I expected semantic-release to correctly walk back along a merged branch to identify the commits that go into that branch and then decide on the correct version bump based on all parent branches.

Environment

The following is formatted as a cram and can thus be replicated by just running the example using cram. Of course, last couple of example calls are probably not the desired behaviour. I'm running on Ubuntu 20.04.

Create empty repository
  $ git init
  Initialized empty Git repository in /tmp/cramtests-uu74tao7/bug-report.t/.git/

And setup a pyproject toml
  $ echo '[project]' > pyproject.toml
  $ echo 'name = "mypack"' >> pyproject.toml
  $ echo '' >> pyproject.toml
  $ echo '[tool.semantic_release]' >> pyproject.toml
  $ echo 'version_variable = "version.py:version"' >> pyproject.toml
  $ echo 'version_source = "tag_only"' >> pyproject.toml
  $ git add pyproject.toml
  $ git commit -m "chore(pyproject): Add pyproject.toml"
  [master (root-commit) 5a4294b] chore(pyproject): Add pyproject.toml
   1 file changed, 6 insertions(+)
   create mode 100644 pyproject.toml

We want a virtual environment here
  $ python3 -m venv environment
  $ python --version
  Python 3.8.10
  $ . environment/bin/activate
  $ pip install 'python-semantic-release<8.0.0'  > /dev/null
  $ pip freeze | grep semantic-release
  python-semantic-release==7.34.6

Now create some code
  $ echo 'def func(x, y):' > mypack.py
  $ echo '    return x + y' >> mypack.py

Create first version
  $ git add mypack.py
  $ git commit -m "feat(func): Basic adding functionality"
  [master 053c2d3] feat(func): Basic adding functionality
   1 file changed, 2 insertions(+)
   create mode 100644 mypack.py
  $ git tag v1.0.0

Write one feature in a branch
  $ git checkout -b feature/support-for-strings
  Switched to a new branch 'feature/support-for-strings'
  $ echo 'def func(x, y):' > mypack.py
  $ echo '    return int(x) + int(y)' >> mypack.py
  $ git add mypack.py
  $ git commit -m "feat(func): Support stringified numbers too"
  [feature/support-for-strings d7a783e] feat(func): Support stringified numbers too
   1 file changed, 1 insertion(+), 1 deletion(-)
  $ git checkout master
  Switched to branch 'master'

Write other feature in another branch
  $ git checkout -b feature/support-for-multiple-inputs
  Switched to a new branch 'feature/support-for-multiple-inputs'
  $ echo 'def func(*args):' > mypack.py
  $ echo '    return sum(args)' >> mypack.py
  $ git add mypack.py
  $ git commit -m "feat(func): Support for multiple inputs"
  [feature/support-for-multiple-inputs 4ee7d8f] feat(func): Support for multiple inputs
   1 file changed, 2 insertions(+), 2 deletions(-)

Now go to master and merge the second branches (create release)
  $ git checkout master
  Switched to branch 'master'
  $ git merge feature/support-for-multiple-inputs
  Updating 053c2d3..4ee7d8f
  Fast-forward
   mypack.py | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)
  $ semantic-release version
  Creating new version
  Current version: 1.0.0, Current release version: 1.0.0
  Bumping with a minor version to 1.1.0

Let's verify that everything is correct.
Yes, we have a new tag with the correct version
  $ git tag | cat
  v1.0.0
  v1.1.0
Yes, the tag points at the correct commit
  $ git rev-list -n 1 --abbrev-commit v1.1.0
  4ee7d8f
  $ git log --oneline
  4ee7d8f feat(func): Support for multiple inputs
  053c2d3 feat(func): Basic adding functionality
  5a4294b chore(pyproject): Add pyproject.toml

Next merge the first branch. 
  $ git merge feature/support-for-strings
  Auto-merging mypack.py
  CONFLICT (content): Merge conflict in mypack.py
  Automatic merge failed; fix conflicts and then commit the result.
  [1]
We fix the merge commit, by simply rewriting the confliced file and committing with the default merge commit message.
  $ echo 'def func(*args):' > mypack.py
  $ echo '    return sum(int(x) for x in args)' >> mypack.py
  $ git add mypack.py
  $ git commit -m "Merge branch 'feature/support-for-strings'"
  [master a0ea47f] Merge branch 'feature/support-for-strings'

Ok, the new commits are there
  $ git log --oneline
  a0ea47f Merge branch 'feature/support-for-strings'
  4ee7d8f feat(func): Support for multiple inputs
  d7a783e feat(func): Support stringified numbers too
  053c2d3 feat(func): Basic adding functionality
  5a4294b chore(pyproject): Add pyproject.toml

Now I want to create a new version that includes the support for strings feature. However, semantic release
isn't aware of the new commits. It isn't even aware that there was a release after 1.0.0 yet!
  $ semantic-release print-version --current --noop
  1.0.0 (no-eol)
  $ semantic-release print-version --next --noop
  1.1.0 (no-eol)
  $ semantic-release version
  Creating new version
  Current version: 1.0.0, Current release version: 1.0.0
  Bumping with a minor version to 1.1.0
  error: Cmd('git') failed due to: exit code(128)
  error:   cmdline: git tag -m v1.1.0 -a v1.1.0
  error:   stderr: 'fatal: tag 'v1.1.0' already exists'
  [1]

[codejedi365]

@igordertigor, if you are still experiencing this problem, please try upgrading to our latest version and trying again. There were significant improvements to the version determination algorithm in v8+.

Since you are coming from v7 you will need to review the docs about migration to v8 (especially configuration).

v8 is locally testable using commands:

semantic-release version --print

# or

semantic-release -vv --noop version

I believe the problem you are experiencing was due to a bug in the tag finding algorithm that I fixed in v9.0.3.

[github-actions[bot]]

This issue has not received a response in 14 days. If no response is received in 7 days, it will be closed. We look forward to hearing from you.

[github-actions[bot]]

This issue was closed because no response was received.