GitLab merged results pipelines

[RyanMnM]

Fully understand this might not technically be an issue with MinVer

Version(s)

6 & 5

To reproduce

Steps to reproduce the behaviour:

When the "Enable merged results pipelines" feature in GitLab is enabled and there is no merge conflicts between the current branch and the main branch a merged results pipeline will run instead of a merge results.

The issue this presents is that a "merged results" pipeline creates a virtual commit with parents of both the current branch and the the main branch.

As MinVer walks the git-tree it will parse the main branch as one of the direct parents of this virtual commit meaning that once it gets to the main branch at the end of having walked the commits in the MR it will ignore it for the second time.

The end result is that the height will always be that of the number of commits on the main branch and not the number of commits in the MR.

1. Have a demo project with some commits on the main branch with a tag at some point
2. Create a MR from the main branch, create some demo commits but make sure no conflicts are present
3. Make sure the "Enable merged results pipelines" setting is enabled
4. Run the MinVer cli in a GitLab CI pipeline

Expected behaviour

MinVer will walk the commits in the MR branch then the main branch and produce a height to the last tag

Actual behaviour

MinVer walks the git-tree it will parse the main branch as one of the direct parents of this virtual commit meaning that once it gets to the main branch at the end of having walked the commits in the MR it will ignore it for the second time.

Workarounds

Turning off the setting or having a merge conflict will false GitLab to not use these virtual commits

Additional context

Probably not the easiest to test without a GitLab instance setup with CI/CD etc, although the free SASS version might support, this description might not be straightforward to understand as well, apologies.

[adamralph]

Interesting. The "problematic" behaviour is in fact exactly the same with GitHub Actions when a workflow is triggered by the pull_request event since, in that case, GitHub also creates a virtual commit which is a merge from the PR branch to the base branch and builds that commit.

E.g. this PR has two commits in the PR branch, yet both the build from commit 1 and the build from commit 2 have the same height.

I'm not yet sure how to change the behaviour so that the height on the PR branch is used instead of the height on the base branch, or even if that's feasible.

[RyanMnM]

Ahh that is annoying! I didnt even think to check if it was something wider than Gitlab as i'd been scratching my head long enough trying to figure out what was suddenly happening after having made no changes to the build process.

It is definitely an odd one - nothing comes to mind as a quick fix either which is annoying.

[adamralph]

@RyanMnM after more thought, I think a reasonable solution for GitHub Actions is to trigger the workflow for the PR branch as well as for the virtual merge commit.

I pushed another commit to the branch for adamralph/simple-exec#670 which removes the branch restriction on the push event, and the build for the push event does indeed have the height from the PR branch.

Can you do something similar in GitLab?