Currently, our pull request configurations are set to have 1 minimum approval prior to merging into a branch. Is it possible to approve my own pull request, or does an independent reviewer need to approve prior to merging into the branch?
Dear Brett,
I am afraid that this is not possible to do it yourself, it has been adressed in the past;
https://jira.atlassian.com/browse/BSERV-4462
https://jira.atlassian.com/browse/BSERV-9544
The general response was;
Thanks for the suggestion! Unfortunately this isn't something that we're likely to add to Bitbucket in the near future.If such a request persists, we'll be sure to reconsider.
Friendly Regards,
Jeremy Mooiman
Thank you for confirming, Jeremy!
No worries! You could still create a ticket with Atlassian and reference to the documentation that other people have requested it. Chance is that they will start working on the feature.
Jeremy
That sucks. The blocking functionality could be achieved by having 2 reviewers, It just feels stupid to hard limit that way. There are scenarios where you just want the approve to be "Yeah, I've double checked my code". For those branches you want independent reviews, you could use 2 reviewers. Even better would actually be a setting on groups that allows that particular group (for example senior developers) to approve their own pulls. Right now I can only achieve this through either disabling approve *or* adding that user to a group that can push directly to the branch.
That sort of defeats the purpose of peer review and merge checks if the requester can approve his/her own pull request. I for one, wouldn't want to see this ever implemented.
if developer_cnt > 1:
print "You are right Carl"
else:
print "I could use this"
As a single developer it's easy enough for me to merge a development branch to an integration or master branch on my local pc and push it. No problem. But I would prefer to go through the pull request process to force myself to check my own work; and to have a record on Bit Bucket
Blah blah blah. There are lots of reasons why you shouldn't review your own pull requests, yes. But that's not point. There are times when I need to merge something and I just need to get the job done.
On Github we can override as admin.
Useful when it's 3am and you need to merge a hotfix without waking up anyone else.
> I for one, wouldn't want to see this ever implemented.What a narrow-minded selfish thing to say. Bitbucket already contains like 100 things and settings I don't want to use or activate. Does it bother me that it's there? Of cause not! I'm surprised you even use git... ...guess you'll have a hard time making a list of all git features you wouldn't like to see implemented...VS DevOps or whatever it's called today has this feature, and it's great for small teams that normally do peer review but still needs work to get done when 2 out of 3 are on vacation etc. The pullrequest is normally triggered to a bunch of builds and autochecks, so it makes sense to have the pullrequest even though you are the only developer at work and want to approve it yourself.
Our current solution: Letting everyone be an admin so that they can turn off and on the approval requirement as needed... :-/
The lack of this feature - which would be a pr project setting for everyone to opt into - is a near deal breaker for our team.
"defeats the purpose of peer review" - who decided that pull requests are for peer review and peer review only?
The lack of this feature has forced us to completely turn off the "Review required" checks on BitBucket PRs.
Having self-review disabled by default is fine, but the combination of this feature being missing *and* there being no "Force merge" feature makes it impossible to recommend the use of BitBucket for small teams - it's completely inflexible, and clearly designed solely for large organisations that never have to cope with a lone developer handling an emergency patch.
Hello Everyone!
We have accomplished the "Emergency Patch" scenario with a combination of branch permissions, merge checks & command line git.
I'm the sole individual responsible for emergencies (I have a backup, but let's go with just me for now).
I have branch permissions setup so that we prevent "Changes without a pull request" to the master branch, and i have added the bitbucket-administrators as an exception to that rule.
We also have merge checks setup so that as a general rule, we require two reviewers in order for a pull request to be able to be merged.
Now if I need to push something through in an emergency, because I'm on the exception list of being able to push changes without a pull request, I can make the required change, create a pull request, then from a terminal/command prompt, I can run a git merge command to merge my change into master and I'm able to push that change.
In BitBucket the pull request will be marked as merged and it will act as though things went though the proper channels even though I forced it though.
I hope that might help some others with the "Emergency Patch" scenario.
-Jimmy
Is there another way?
Could you create a dummy emergency breakglass user that has permissions to review a merge? Then most of the time you could have someone in your team review the code, but in emergencies log in as the breakglass user instead so review the PR?
Not ideal, but I can't see why that wouldn't work. You then would have some sort of auditing for when the breakglass account was used.
Would be great to have the list of exceptional users/groups, who can merge without getting all necessary approvals (like in Branch Permissions section).
At the moment we also can't use this feature due to incompatibility with "Emergency Patch" scenario.
Leaving same comment here as I left to BSERV-446
We are a team of 2 developers where I'm the lead and the other is new in the company and quite junior. I want to approve his PRs before letting him merge, but I don't see the point of letting him approving mines, as he doesn't even know the code I'm working on.
Seems legit case to me and frankly I don't even understand all the fuss about it as it could/should be just a simple option.
Totally agree.
Kind of sucks that we need to resort to this kind of "trickery" to simply bypass the "best practice" due to perfectly valid exceptions to the rule.
But, I dig the solution focused thinking. Good idea, I'm going to do this right now. Ironically, I'm the system admin and dev team lead, but because of the way Bitbucket has locked this down to the "best practice" only, I need to get approval from someone who reports to me.
Presumably this is only for emergencies?
Having someone more junior review your code is a good thing. It gives them an opportunity to learn and also makes sure you stay on your toes.
I am also in a Similar situation. We are a team of 2 developers. Also me being the only person who is developing features and code for functionality etc while the other designs UI. he cant understand what I am writing. I do double check my code. previously I could approve my own pull requests but for the past 3 or 4 pull requests I have not been able to do that even though I am the only one with write access and my check is only 1 approval. Its baffling that I cant approve my own requests. Not everything requires a peer review and there are probably lots of similiar teams out there.
Same here - turned off review required.
Bitbucket should be agnostic workflow agnostic. GitHub allows this feature.
Sort of similar situation here - BitBucket should review and allow this
I said it down below and I'll say it again here. If you have permissions to push commits to the destination branch you have the ability to bypass the merge checks by using the command line. Do you want to do this all the time? No. But, in these emergency situations, this would be my recommended setup so that you "can" bypass merge checks if the situation calls for it.
This doesn't seem to be the case anymore (at least that the PR is not updated as if it were merged).
If you have the right to push straight to a branch, you should as well have the ability to merge no matter what checks have been bypassed. As for now, our only solution is to disable review checks because our high-ranking developers want to create PRs for pipelines, but not for peer reviews. The more we spend time with bitbucket, the more we regret the decision to move towards it. Actually, the worst decision I made, was to agree with migrating everything to atlassian.
Also Gitlab allows it.
Cant believe 4 years later and this is still not possible.
It looks like you're new here. Sign in or register to get started.
