Issues

allow for pull requests to require approval (BB-6920)

We would like to modify our workflow to require that a pull request requires as least two approvals from the team in order to merge into our master tree. Is this is already possible with bitbucket?

Obviously we can simply tell our project leads not to accept a pull request until two approvals show up, but we try to maintain a team-based mentality where no single member has totalitarian control. Having said that, it is sometimes difficult to ensure that every single change that makes it in has indeed been reviewed by multiple parties.

I am often confused by Atlassian's offerings.. We have been moved from FeCru to Bitbucket, yet it seems that Stash provides the same features as Bitbucket plus some fine grained control?

Why was this not discussed in the migration documentation? Furthermore, why are there two products that provide git support from Atlassian instead of having, for example, an "enterprise" package for bitbucket? We'd probably pay for it.

Also, is Stash a hosted solution?

Finally, I'm a bit put off as a paying customer that the answer to this is simply "we're not going to do that." We're developers, can we help? Is there a way for me to get the community to upvote this feature to impress upon you that it may be worth the development time? In fact, because you already have the ability to approve a pull request, it occurs to me that something like this might not be such a technical hurdle. If not here, where does one go to pursue a feature like this?

Echoing everything said here.
Having this feature would be great.
The move to Stash does not help as its not available as part of the onDemand suite.
Atlassian should get its act together as far as treating its customers better

Our team could really, really use this feature, as well. With a growing team and lots of people trying to merge code, it would be very nice to be capable of putting some restraints on when people can merge to minimize the risk of breaking master.

Agreeing with previous comments. If I have to spin up Stash on local infrastructure just to use this feature, I'd much rather use GitHub Enterprise then dealing with that hassle. I imagine a lot of smaller business feel exactly the same way.

With 110 votes, this really should have higher priority. The plugin for Stash which required x number of approvals before merge was the only way I was able to even get git passed my security and compliance auditor at my last organization. Features like this will do nothing but increase your enterprise adoption.

all stash or (bitbucket server) functionality should be added to Bitbucket, two code bases shouldn't be an excuses. Both are paid solutions, the only difference to me is one hosted by Atlasssian and one hosted by your own, but the functionality of each shall be the same.

This would be very useful. The SAAS Bitbucket is what we need, not the hosted version, but we would like to have the ability to require two approvers, and to define the lists of people authorized for the first and second step of approval.

We're still working on this. We're planning to support both repo and branch level controls, so you can apply some settings to a whole repo but really lock down the most critical branches. Progress has been good, but as you all know, the devil's in the details.

@benechols - I'd love to see the PR author's self-approval optionally required as a condition for merge, though. We've been in situations where someone submits a pull request for review but doesn't intend for it to be merged quite yet and is just looking for early feedback.

Hey, guys. I made an extension some time ago that does just that. It's not perfect (anyone can re-enable the button lol) but it's something (btw, sorry for not having this functionality in the screenshots. I'll work on that later). I'm open to suggestions.

We need this feature so badly, currently we use an admin account to merge pull requests to make sure everyone has approved without a sneaky merge going on, it consumes way too much time, not to mention the build server then builds it twice because it's been merged by 2 users. @benechols, can you give us a rough estimate as to how much longer?

Also, are there any plans to introduce the "Requires a minimum of x successful builds" feature?

Navigate to "/admin/branch-permissions" within your repository, there's a new "Merge via pull request" option for branch permissions. I just set branch to master, don't give anyone access to write & set my developers group to Merge via pull request

Oscar Galvis - how do you reply to a comment? I am unable to do so - basically I too wanted to tell ICT-Team the same thing you said - this is such a basic feature that worked so well for CI/CD builds in gerrit. Heck, BB even has this feature in Stash - why aren't they offering it here. Same is the sad story for another BB issue - 7667

Lakshminarayanan Krishnan replying seems to be another missing feature of this forum, I just make a comment like you did. I think we can just look for alternatives to BB, this issue was created 4 years ago! and the last update from Attlassian 3 months ago is that it is delayed :( ... very dissapointing. What other options are you all considering, We are thinking AWS Codecommit + Gitlab.

Oscar Galvis - We're only partially into our migration from Perforce to Bitbucket, so if I suggest a shift to another hosted-solution, my CEO might possibly murder me :D .. We also picked up BB because it was like just a dollar extra per user over our existing JIRA license. Do AWS Codecommit & Gitlab offer same / similar solutions as BB? I'm sorry I haven't really checked other options thinking that selecting BB would be a good decision. I mean, it still is - BB doesn't charge based on number of repositories you host (unlike Github). Just that they are pretty slow to implement important features.

Why did you try to support it per branch level to begin with? It doesn't even have to be that granular for starters...

So many kittens have died and people started to kick babies in the last 4 years because of this missing feature.

Guys, OK, I know you've worked on this but did you really break this into smaller chunks and estimated them? Maybe I'm wrong, but to me, doing this on the repository level is a single developer's %20 time, so working on it on a Friday, testing & improving it on Monday and it could have been released to masses by Tuesday... Simple, require N many approvals before any pull request can be merged setting on the repository admin for a starting point. That's all. After all, you have all the information, there needs to be greyed out Merge button on the frontend side when there's not enough number of approvals set per repo and a validation on the backend side.

This is not a snarky comment whatsoever, I'm very happy to have been using your service for many many years now. But this should've been released long time ago with primitive features. After all, we've been advocating for being Agile for this particular reason, particularly to avoid long running frustration and customer dissatisfaction.

Hey everyone, for us today we noticed a new section in branch permissions when creating a rule for a specific branch, called merge checks. There was a note it requires a premium cloud account. So not free? Looks just like the merge checks for the bitbucket server.

Benjamin Echols
We have 18 users, we pay $25/month ($300/year). Our cost will go to $90/month for this feature ($1080/year)!? That's a a pretty dramatic cost increase for a straight forward feature. Whats the justification for the large price increase? What other features can premium users expect?
Can this feature be limited to only the reviewers in the team?

Benjamin Echols, completely agree with Philip O'Gorman, Jeff Stripling and others that the price becomes unreasonably high just for this feature, especially if you don't need (as in my and many other cases) neither additional GFS nor Pipelines.

We believe Premium is competitively priced for the features, performance, and uptime we offer. The Bitbucket Premium plan is for professional software teams who need better control and accountability over their workflow, so we will continue to add more administrative, security and auditing features.

Benjamin Echols in our case none of our code base is supported by Pipelines and we don't need GFS. If you plan to add more features in the future, that's fine, charge for them when you have them, or at least give us a roadmap. This has a feeling of "bait and switch". The simplicity and cost or your previous plans was what attracted us here in the first place.
This will most likely make us move to the server solution - maybe that's the intention?

there is nothing in the premium documentation about performance and uptime for this new service level. as far as I can see, we'll get billed +$3/user/month to use one feature (to require pull requests). that is not worth it. the other functionalities touted in the premium feature set are not applicable to me. Perhaps there are others that will be interesting if there is a roadmap available.

This is a pretty steep price increase for what should be regarded as core functionality. Like others I have absolutely no need for GFS or Pipelines, and even if I would be using that this price increase more than doubles the amount of money that goes to Bitbucket. That is rather disproportionate.

With the extremely slow uptake on this issue (and several others), the lack of communication about it and the general service level from customer support I don't feel like paying you anything more than we do already, let alone this much - especially if you're justifying this price increase with a lot of future feature implementations. Nothing about the way you handled this case suggests these features will be around before the next decade, so excuse me if I don't feel like paying you hundreds of dollars for several years awaiting those features which probably aren't even necessary for us.

I would also like to point out that this puts into perspective the fact you disabled comments on the blog recently, just before posting the announcement of this price hike on that same blog. Were you afraid for some negative comments and backlash? Because if you were, that was justified and pre-emptively silencing public feedback channels does not feel like you're very intent on handling any of it.

+1 on the price. The multiple-approvers feature is important, but so are a lot of others, and this step up in functionality is not worth a much-increased price. (If I understand correctly, the price is times-5)

Similar to what Philip O'Gorman said, we have 75 users and are on the 100USD per month plan (1200USD per year), and for just having the need for the only one useful feature that you have implemented - merge checks - our cost is going to jump to 75*5 = 375 USD per month (4500 USD per year) - EXTREMELY steep increase for a very basic feature that should have been implemented a long long time back. Pipelines - you do not even support the platforms we have, and GFS is something we have no need for.

This is as bad a money-making strategy as in-app-purchases for "free" games.

The more we think about this, the more we are thinking moving to Gitlab is a better option now. This bait-and-switch tactic was something we had hoped Atlassian wouldn't stoop down to, but now you have practically fooled us by becoming "just another company".

Here is one premium feature I would like to have (I think it would be worth to pay $5/user/month for it): I want to be able to like someone else's commit. And for each like, a little heart should be displayed next to commit.