Merging when build succeeds merges in subsequent unbuilt changes to source branch
When an open merge request is accepted after a successful build, the source branch as it is at that point is merged into the target, including changes made AFTER the build from the merge request creation started. This means unbuilt changes are merged in along with those that built successfully. Here are the actual events as we saw them:
- Developer pushes new source branch (8:58)
- Developer opens merge request (8:58)
- Build/Pipeline is started
- Developer pushes 1 other change to source branch (9:04)
- First build finishes (9:50)
- Dev Builder accepts merge request and merges both changes (9:50)
- Second build finishes (10:16)
In this scenario our second build was successful, so thankfully there was no fallout other than confusion for the developer. However, this is obviously risky behavior. If the subsequent build fails it's too late...the changes which failed the build have already been merged in and polluted the master branch.
Our scenario specifically involves the use of the Jenkins gitlab-plugin with the "Accept GitLab merge request on success" feature, but since it simply uses the GitLab API I would expect the same behavior if I were to manually accept the MR or click the button to Merge When Pipeline Succeeds. Haven't tested it though.
I can think of at least 2 options for dealing with this scenario:
- Default behavior (or configurable) to block a user from pushing changes to a source branch while a pipeline is in progress.
- Save off the state of the source branch (i.e. - tag) at the time of the build being triggered, so it could merge only the tagged changes when the build comes back with success. I think this would be more efficient and so preferable.