Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

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



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... :\\\\
Any help about fixing/workarounding this issue would be appreciated.



- Jesús M.


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

1 answer

0 votes
Jeyanthan I Atlassian Team Apr 08, 2018

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.

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events