Open simon-weimann opened 8 months ago
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.
Iam facing the same error.
@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?
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.
I noticed a strange behaviour/bug with the
git
provider when running semantic-release for a git repository that looks the following: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: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 thegit
provider internally when not providing aGITLAB_TOKEN
and instead using theCI_JOB_TOKEN
, I also experience the same behaviour above for thegitlab
provider. (https://github.com/go-semantic-release/provider-gitlab/pull/7, https://github.com/go-semantic-release/semantic-release/issues/141)As a workaround, we have to change the default merge strategy for gitlab from
merge-commit
tofast-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:
Running semantic release produces a release
v1.0.1
which should be av1.1.0
as the feature branch contains a comit withfeat
:Steps to reproduce:
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.