You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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?
I am afraid that this is not possible to do it yourself, it has been adressed in the past;
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.
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.
if developer_cnt > 1:
print "You are right Carl"
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
> 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... :-/
I understand why having code reviewers is a good idea. The thing is, some scenarios need to allow for bypassing the "best" process. For example, if working on a mission critical bug on a Friday night and need to merge the code to fix the bug and the reviewer is asleep and won't see the PR until 2 days later on Monday.
For me, right now, it is Saturday afternoon, and all the devs are off. I am the only one on and I am scrambling to get this bug fix pushed to production. So ya, this is a real Bit Bucket use case. At least allow a few top level admins to push without an approval from a second dev so that the single dev bug fix work can be done pushed from within the pipeline.
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.
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.
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.
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.
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.
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.
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.
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.