nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Merge queue in bitbucket

unknown

I'm looking for a way to implement the following - increment (commit to repository) app's version on successful merge (build from jenkins). This increment step is part of jenkins pipeline, but I faced a problem when developers merge multiple pull requests in short period of time, so that build could not finish. The only solution I see is to have some sort of merge queue, so that bitbucket would actually merge branches when there is no ongoing build on source branch. Looking for any kind of advice / guide on how I can achive that. Couldn't find that functionality nor available plug-ins. Thank you in advance!

Accepted answers

Rajkumar Singh

Hi everyone 👋

I’m jumping in with an update, since this thread has had a few folks asking for “native” merge queue support in Bitbucket Cloud.

Back when this question was asked, the only options were custom Jenkins gating, REST scripts, or third‑party apps. Bitbucket Cloud now has built‑in merge queues, currently in open beta for Standard and Premium plans. 🎉

You can read more here:

Blog: Merge Queues for Bitbucket Cloud, now in open beta - Work Life by Atlassian
Community article: Introducing merge queues for Bitbucket Cloud [open beta]

What you get out‑of‑the‑box now

Merge queues are built to solve exactly the problem discussed here:

Queue instead of race‑to‑merge – developers add PRs to a queue; Bitbucket merges them in order once checks pass.
Keep main green – each PR is validated against the latest target branch (plus queued PRs ahead of it), reducing broken builds and subtle post‑merge conflicts.
No extra tooling – this is native Bitbucket Cloud; no custom Jenkins logic or separate apps needed.

Getting started

At a high level:

On a Standard or Premium Bitbucket Cloud workspace with Pipelines enabled, go to your repo:
Repository settings → Workflow → Merge queues
Configure a queue for your target branch (e.g. main or develop), then add the corresponding merge-queues section to bitbucket-pipelines.yml.
Developers use “Add to merge queue” on PRs targeting that branch; Bitbucket takes care of sequencing and validation.

Full step‑by‑step docs (including YAML examples and options) are here:
Manage pull requests with merge queues | Bitbucket Cloud | Atlassian Support

We’d love your feedback (or a quick call)

Because merge queues are in open beta, your feedback is especially valuable:

Does this cover the cases you’re currently solving with Jenkins/custom scripts?
Are there specific CI or repo patterns where the current merge queue behavior doesn’t quite fit?

If you’d like to talk through your setup or share more detailed feedback, you can grab a slot for a quick call here:
Bitbucket Pipelines: Product Discussion

Or feel free to reply in this thread with your use case and what you’d like to see next

All comments

Mikael Sandberg

Instead of doing your build on the target branch, you could do it on the source branch and then set up your repository to not allow a merge to happen unless there is a successful build. That would avoid the scenario of having multiple pull requests being merged at the same time.

unknown

Hi, @Mikael Sandberg!

At the moment that is how my development is set - I trigger the build when pull request is opened, check if its build is successful, then the merge button is enabled. On the merge event the build is triggered on the source branch (resulting merge commit). My bitbucket is in corporate setup, so I might not have all options that you are referring to, but at the moment I dont see any that would say something like "successful build on source branch". Please confirm if that is what you meant.

Also, even if I resolve it this way I would still look for some queue implementation, as our team really loves merging a lot during the day, so checking back and forth if merge button is enabled or not would be really time consuming and distracting.

Mikael Sandberg

Once you do a merge there is no option to roll it back in Bitbucket, and I do not think there is an app that allows you to check if the target branch is being used in a build or not to prevent the merge.

How do you handle builds that fails on the target branch? Are you rolling back the merge from the source branch? If so, please be aware that Git do not remove that merge from history, as explained by Linus Torvalds:

Reverting a regular commit just effectively undoes what that commit did, and is fairly straightforward. But reverting a merge commit also undoes the _data_ that the commit changed, but it does absolutely nothing to the effects on _history_ that the merge had.
So the merge will still exist, and it will still be seen as joining the two branches together, and future merges will see that merge as the last shared state - and the revert that reverted the merge brought in will not affect that at all.
So a "revert" undoes the data changes, but it's very much _not_ an "undo" in the sense that it doesn't undo the effects of a commit on the repository history.
So if you think of "revert" as "undo", then you're going to always miss this part of reverts. Yes, it undoes the data, but no, it doesn't undo history.

So, here is how I would do it. In Jenkins, instead of running the build on both the source branch and then later on the target branch after the merge, why not merge the source branch to the target, and then run the build. The merge is done locally in the repository that Jenkins is using, so you can simply just revert the merge after the build is done.

unknown

Thank you very much for bringing in the case, I will definitely consider it in the future to improve the pipeline. It's just I haven't encountered build failures on target branch just yet, so your comment made me think it can happen.

The reason I have two builds is the following - build on the source branch lets the team be sure everything is okay on this particular pull request (it does couple analysis as well among other things) and adds some confidence it can be merged to the target branch without bringing in any problems, while build on the target would update some metrics of the artifacts, send it to testers... and update the version that in my vision should reflect the pull requests being made. The versioning thing should make it easy to know how many features are added (merges have been made) and coordinate where to look when there is a need.

I am curious to know if what I am trying to do is very rare case, if there is no implementation in Bitbucket. Can you, please, share how you would achieve it (I am talking about incrementing version on each pull request being made)? Happy to explain it more or add details of why we need this, if it is still not that clear.

The local merge in Jenkins before actual merge in server is very good idea to avoid some nasty problems in the future. Thank you again for the tip.

Abhin Chhabra

I've recently had my Bitbucket Cloud add-on mergetastic.com approved for the Bitbucket Marketplace. It's a Merge Queue for Bitbucket Cloud and if that's what you're using, it might be able to help you.

Steve Taylor_64sy68

Atlassian has an open source product that does this: Landkid. They use it in their frontend monorepo which has a large number of daily pull requests. It would be nice, however, it if was part of Bitbucket Cloud.

Rajkumar Singh

Hi everyone 👋

I’m jumping in with an update, since this thread has had a few folks asking for “native” merge queue support in Bitbucket Cloud.

You can read more here:

Blog: Merge Queues for Bitbucket Cloud, now in open beta - Work Life by Atlassian
Community article: Introducing merge queues for Bitbucket Cloud [open beta]

What you get out‑of‑the‑box now

Merge queues are built to solve exactly the problem discussed here:

Queue instead of race‑to‑merge – developers add PRs to a queue; Bitbucket merges them in order once checks pass.
Keep main green – each PR is validated against the latest target branch (plus queued PRs ahead of it), reducing broken builds and subtle post‑merge conflicts.
No extra tooling – this is native Bitbucket Cloud; no custom Jenkins logic or separate apps needed.

Getting started

At a high level:

On a Standard or Premium Bitbucket Cloud workspace with Pipelines enabled, go to your repo:
Repository settings → Workflow → Merge queues
Configure a queue for your target branch (e.g. main or develop), then add the corresponding merge-queues section to bitbucket-pipelines.yml.
Developers use “Add to merge queue” on PRs targeting that branch; Bitbucket takes care of sequencing and validation.

Full step‑by‑step docs (including YAML examples and options) are here:
Manage pull requests with merge queues | Bitbucket Cloud | Atlassian Support

We’d love your feedback (or a quick call)

Because merge queues are in open beta, your feedback is especially valuable:

Does this cover the cases you’re currently solving with Jenkins/custom scripts?
Are there specific CI or repo patterns where the current merge queue behavior doesn’t quite fit?

If you’d like to talk through your setup or share more detailed feedback, you can grab a slot for a quick call here:
Bitbucket Pipelines: Product Discussion

Or feel free to reply in this thread with your use case and what you’d like to see next

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

bitbucket

bitbucket-server