VCS: Concurrent plan branches gatekeeper strategy does not ensure merging from latest HEAD available

Jesus

Hi,

We're developing a VCS plugin for bamboo for Plastic SCM with plan branches + automatic merge support (Gatekeeper), but apparently we've been hit by a similar issue that Git already has. This issue prevents from implementing a Trunk Based Dev cycle with Bamboo and Gatekeeper workflow.

The scenario to reproduce my case is the following:
1- When bamboo starts, there are two plan branches ready, so bamboo queues both of them.
(Another equivalent and more realistic scenario is the following: plan branches are queued while another plan branch is running).
2- Once they are queued, bamboo creates two different workspaces (one per newly queued plan branch) to perform the source code checkout + merge from plan branch:
The checkout is performed using the last commit (vcsRevision in bamboo jargon) in the GateKeeper branch defined at this specific point in time, and the merges from the corresponding plan branch.
3- Let's suppose both merges are valid. Both workspaces remain stalled.
4- Then, bamboo picks the first plan branch and runs the build plan. The build plan creates ANOTHER workspace and re-runs the merge.
5- The build plan is successful, and bamboo commits the merged code created in step 2, the one where the merge was checked for this first plan branch.
6- Bamboo picks the second branch and runs the plan, creating ANOTHER workspace and re-running the merge.
7- The build is also succesful, and bamboo tries to commit the workspace created in step 2, the one where the merge was tested for this second plan branch.
8- But in this case, as there is another commit in the Gatekeeper branch coming from the first merged plan branch, the commit fails because we're not in HEAD anymore, ruining the build of the second branch.
(With the inconvenience also that the code built from this second plan branch is not the one merged from the latest HEAD available).



I saw there are still open tickets to workaround this issue and serialize the gatekeeper builds, but they are still opened... :
https://jira.atlassian.com/browse/BAM-12071\\ https://jira.atlassian.com/browse/BAM-14577\\
Any help about fixing/workarounding this issue would be appreciated.

Thanks,

 

- Jesús M.

 

PS: attached screenshot with a diagram of the faulty scenario for the second plan branch:

Jeyanthan I

Just to close the loop after following up on the support request you raised internally.

Summarising the actual issue:

 When there are two plan branches created in Bitbucket, Bamboo creates 2 plan branches and queues them to build subsequently (as we dedicate to 1 agent). When the Gate keeper merge option is configured, the first branch merges to master followed by the second branch that tries to merge but fails as the second merge commit is not done in HEAD (as the head is changed by the previous plan branch merge, thereby we're not in HEAD anymore).

We are aware that this issue exists when multiple plan branches do the merge simultaneously. The way it should work is that we make sure that pushes are successful, thereby not running 2 branches in parallel if gatekeeper with push is enabled. We should be able to fix them all once we redesign the workflow, which might take time. The following are all relevant to your issue and we recommend you to upvote and follow all the below.

• BAM-12146 - Branch merging with gatekeeper and push on causes git failures with concurrent builds
• BAM-11007 - Gatekeeper with push requires the commits into that repository to be serialized
• BAM-12071 - Add a way to limit concurrent builds across plan branches
• BAM-14577 - Serializing Gatekeeper branch builds