Commits from Merge-Commits are not considered for a release when using provider git or gitlab

[simon-weimann]

I noticed a strange behaviour/bug with the git provider when running semantic-release for a git repository that looks the following:

*   b76a513 - Merge branch 'feature'  (HEAD -> main)
|\
| * dd87ac7 - feat: feature  (feature)
|/
* fdc9e7b - feat: initial commit  (tag: v1.0.0)
(END)

As you can see, the tip of the repo is a merge-commit, that merges a branch with commit that complies with the conventional commit syntax (feat: feature).
Running semantic-release --provider git --no-ci should add a tag v1.1.0 at the merge-request but it doesn't:

 semantic-release --provider git --no-ci
[go-semantic-release]: version: 2.29.0
[go-semantic-release]: trying to prefetch plugins...
[go-semantic-release]: all plugins were prefetched!
[go-semantic-release]: ci-condition plugin: default@1.9.0
[go-semantic-release]: provider plugin: git@1.9.0
[go-semantic-release]: getting default branch...
[go-semantic-release]: found default branch: master
[go-semantic-release]: found current branch: main
[go-semantic-release]: found current sha: main
[go-semantic-release]: getting latest release...
[go-semantic-release]: found version: 1.0.0
[go-semantic-release]: getting commits...
[go-semantic-release]: analyzing commits...
[go-semantic-release]: commit-analyzer plugin: default@1.12.0
[go-semantic-release]: calculating new version...
[go-semantic-release]: no change
[go-semantic-release]: stopping plugins...

It does not detect any changes related to the branch that is being merged. However when using the github provider this works as expected.

As recently a change was implemented, that the gitlab provider uses the git provider internally when not providing a GITLAB_TOKEN and instead using the CI_JOB_TOKEN, I also experience the same behaviour above for the gitlab provider. (go-semantic-release/provider-gitlab#7, #141)

As a workaround, we have to change the default merge strategy for gitlab from merge-commit to fast-forward which is not desired.

When changing the commit message for the merge commit to the conventional commit syntax, it does create arelease, however it still does not respect the commits from the branch to be merged:

*   e09ec9c - fix: merge branch 'feature'  (HEAD -> main)
|\
| * dd87ac7 - feat: feature  (feature)
|/
* fdc9e7b - feat: initial commit  (tag: v1.0.0)

Running semantic release produces a release v1.0.1 which should be a v1.1.0 as the feature branch contains a comit with feat:

❯ semantic-release --provider git --no-ci
[go-semantic-release]: version: 2.29.0
[go-semantic-release]: trying to prefetch plugins...
[go-semantic-release]: all plugins were prefetched!
[go-semantic-release]: ci-condition plugin: default@1.9.0
[go-semantic-release]: provider plugin: git@1.9.0
[go-semantic-release]: getting default branch...
[go-semantic-release]: found default branch: master
[go-semantic-release]: found current branch: main
[go-semantic-release]: found current sha: main
[go-semantic-release]: getting latest release...
[go-semantic-release]: found version: 1.0.0
[go-semantic-release]: getting commits...
[go-semantic-release]: analyzing commits...
[go-semantic-release]: commit-analyzer plugin: default@1.12.0
[go-semantic-release]: calculating new version...
[go-semantic-release]: new version: 1.0.1
[go-semantic-release]: generating changelog...
[go-semantic-release]: changelog-generator plugin: default@1.13.0
[go-semantic-release]: creating release...

Steps to reproduce:

git init --initial-branch=main
git remote add origin <url to remote>
git commit -m "feat: intial commit" --allow-empty
semantic-release --provider git --no-ci    # will create a version v1.0.0
git switch -C feature
git commit -m "feat: feature" --allow-empty
git switch main
git merge --no-ff feature
semantic-release --provider git --no-ci  # does not create a release, but should

Expected behaviour:
Semantic-Release does respect both parent for a merge-commit when running the commit analyzer.

I hope the problem is clear and can be fixed.

[simon-weimann]

I am pretty sure, that the problem is related to the code at https://github.com/go-semantic-release/provider-git/blob/90e05cb6343f0c539a01337f4edf1aeb73dbfa4c/pkg/provider/git.go#L108

It seems to break the forEach too soon. I have also checked the underlying go-git implementation and it seems that it does not have support for something easy like git log from...to. What a pity.

I tried to test and fix this myself, however my go skills are very limited (basically non-existing).

Hope someone can join the issue.

[yanehi]

Iam facing the same error.

[yanehi]

@simon-weimann - We have found the problem in our case. It was an unset GITLAB_TOKEN variable. Strangely enough, there was no error message in our CI, only the same message that you received in the logs above.

Perhaps your token has also expired?

[dannylongeuay]

There are log_order options available now to help achieve the same affect when using the CI_JOB_TOKEN instead of the GITLAB_TOKEN.

log_order=dfs (Default) - Ordering by depth-first search in pre-order

log_order=dfs_post - Ordering by depth-first search in post-order (useful to traverse history in chronological order)

log_order=bfs - Ordering by breadth-first search

log_order=ctime - Ordering by committer time (more compatible with git log)

i.e. semantic-release --provider gitlab --provider-opt log_order=<ctime or dfs_post> would detect changes from commits in the merging branch.