We have 6 people on the project team: 1 Tech-lead and 1 Assistant Tech-lead.
In our branch policy we want to require that only the Tech-lead or Assistant Tech-lead can approve the pull request. We only need approval from one of them to avoid a bottleneck if the other one is on leave.
The problem is there are only 2 choices in the branch policy settings:
Specifying the number of required approvers (which will not work since normal developers would be able to approve as well)
Specifying the actual person to approve (which will not work since both of them will be required and cause a bottleneck when one is on leave)
Can someone please point us in the right direction?
You can provide required reviewers that are automatically added to each PR. These reviewers can also be groups.
Do this:
Create a group that contains your tech lead and assistant tech lead and.
Make that group a required approver under Automatically include code reviewers
You should get something like this:
Your statement normal developers would be able to approve as well is only true if the group that is required contains your normal developers.
This way at least 1 person from provided group (in this case Developers) must approve a PR. If you want you can also provide a path filter to require only reviews on certain changes or assign a different group for files or folders.
for those who are on Bitbucket:
These are available under Repository Settings->Workflow->Branch Permissions
Related
I have used a few code review programs. I am now using pull requests in Bitbucket. I am expecting a certain process:
Create review (ie pull request)
Comments are added by reviewers. ( am used to a graded system where someone can mark the change as a bug which needs to be fixed before being merged)
The review is sent back to the originator who fixes any problems that are marked
(!!)The originator pushes their changes to their branch and then the code review is done again by all reviewers who then approve or reject the new changes.
With all things being good, the review is approved and then merged.
What I am wondering about are steps 3 and 4. There seems no grading to the comments and there seems to be no way for the originator to see quickly the comments (in some condensed format). Also, how do new changes update a pull request? Is this just missing from the Bitbucket system or is there a way to achieve this?
"there seems to be no way for the originator to see quickly the comments (in some condensed format)". Open a pull request, and look over on the right hand side. I see 3 tabs: Details / Files / Activity. Under "Activity", I can filter to "All Comments".
"how do new changes update a pull request?" When creating a pull request, you are requesting approval from your colleagues to pull code from some source branch to some target branch. So, when the source branch is updated with changes, the pull request should automatically reflect that. In other words, you shouldn't have to take any extra action.
"There seems no grading to the comments" A reviewer can check a box that says "merge not allowed until the 'issue fixed' box is checked." The repo admin has some latitude to set how strict the PR / merge policies will be, including whether approval is needed from anyone or from specific individuals.
My boss come with a very unique requirement, below is the explanation.
Imagine there is 10 user for a particular project team.
And the work flow is like
Documenting -> Review -> Publish
Now, the requirement is like below.
If I create Ticket with Summary "Version 1.0 Documents" with the above explained workflow, then it should also allow us facility to manager for user regarding each state of workflow like
Documenting assign to User A
Review Assign to User B
Publish Assign to User C
Note: I know I can assign ticket to individual user while changing state, but I want something pre-planned so as soon as I change status of ticket it will automatically assign to user.
I know I can do this using post action of transaction but what I want is, the assignee should be specified at creation of ticket as the same workflow going to use by many project and ticket, and every project will have different team
So , I need something add-on which allow me to manage team for each ticket.
Also, User C should be able to see his/her upcoming work if ticket is in any previous state i,e Documenting or review.
I suggest you should create account role for this and group to each department/team for their flow. you can use account role for separating their works then the department/team is useful for which members/users can see the particular issue/ticket. we already build something like this we have 3 account roles each ticket so i can say this is possible. if you still have question just let me know thanks.
We are using Atlassian Crucible for code reviews. Every time I create a review, it shows me a list of about 40 reviewers from the entire project. But only about 5 people in my group within the project need to review my code, so every time I have to manually remove about 35 people from the list of reviewers.
Is there any way to create a default list of reviewers for my code reviews?
Yes, you can create a project and define default reviewers for a project. For ex you can have a default review group for Java projects and a different one fr DB projects
PS:- You would need admin privileges to do this
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I have a small team of developers that use bitbucket as our git repository.
I want to know how to limit who can merge code on a pull request in bitbucket? AND/OR force at least one approval before the merge can be done. Basically I am looking to force a code review.
As of now the creator of a pull-request (and everyone else) can not only approve but also merge the code in which can be an issue for quality purposes. Thanks in advance.
Update:
Bitbucket now allows for control over push permissions, branch deletion, and history re-writing. The full management instructions are here: https://confluence.atlassian.com/bitbucket/branch-management-385912271.html
There still is not a way to force a minimum number of approvals however.
I want to know how to limit who can merge code on a pull request in bitbucket? AND/OR force at least one approval before the merge can be done. Basically I am looking to force a code review.
This functionality is not available in Bitbucket right now, but Atlassian's behind-the-firewall version of Git hosting has it.
Stash allows you to:
limit who can change branches
enforce a minimum number of approvals before merging pull requests (it can do a similar thing for Bamboo builds - i.e. the code must compile before it can be merged)
reset approvals if a pull request changes
It's a curious asymmetry in Atlassian's own products.
Answer from attlassian:
Mary Anthony [Atlassian Technical Writer]
Hi,
So, a repository can have branches. Within that repository, you can't
set permissions on a branch that are different from the repository.
You can set permissions on the repository that would allow developers
to fork the repository and issue pull requests against it. To
configure this:
Create a group on your account and call it "developers".
Give the group read permissions.
Add all the developers to that group.
Edit the groups on the repository and add developers.
Hope this helps.
Mary
Here it is: https://confluence.atlassian.com/display/BITBUCKET/Work+with+pull+requests?focusedCommentId=321851850#comment-321851850
In other words, you can make your dev fork the project and issue pull requests from their fork. In your project , you can set the project to disallow public fork. I assume that they will fork the project and it will be hidden. That said, they will be able to issue pull request and edit their own repository. It looks quite akward but it should work.
I don't have the feeling that there is a good way to handle permissions on github/bitbucket and so on.
edit
Not really a solution to enforce it but still quite valid. Since approval of pull-request is quite optional. Doesn't mean that you're screwed and in fact, if I were you. I wouldn't try to enforce a system. The reality is that code review is important. Pull request makes it easier to review sets of commits.
I worked many months being the only one in my team to create/approve pull requests. The team in which I worked decided that pull requests was a waste of time and I guess that none of them did code review until I left. Last thing I heard is that my team mate is currently refactoring my code because he has no idea how it works.
What I'm trying to say is that code review shouldn't be enforced and your team should see it as a quite important thing to do. Each member of your team should work together and code review each others on their own. By doing code review, they will have the right to deny code that they feel is "ugly" or should be designed in a different way. Each member get to stay updated on what other devs are working and may not have much problem switching on anybody's work in case of illness, departure or death!
Enforcing the process in the system could be good from a manager's point of view. But I believe that having approval as optional isn't bad either. And then, the manager's job will be to check the merged pull request for the pull request with 1 or less approved person. Check who merged the pull request and who approved. Find someone to review the code anyway.
On the other hand, if a pull request is hanging around forever and nobody is reviewing it. It's the dev task to ask a mate to review it.
I want to make a TFS 2010 project read-only so users can view the info in work items but not add any details or new work items. I think I need to change the security permission on the project but it's not clear which permission I would change from the Contributors list.
In my opinion the right way is to alter the group memberships.
Remove all users from the constributors and higher groups and move them to the Readers group.
Two choices.
Choice 1: If this is a common pattern where the prevailing default is that folks are restricted, but some people have access (i.e. devs cannot change things but Tech Leads can), modify contributors and create a secondary group (for example, 'Tech Leads') that has the additional read rights. In this scenario, the Contributors group would contain tech leads, but only specific individuals with the extra rights would be in the Tech Leads group.
Choice 2: If the prevailing default is normal contributor access, but specific individuals (i.e. external contractors) need to be denied access, and you need to be 100% sure this goes through, regardless of any other group membership, then leave Contributors as is, and add a new group called (in this example) 'Contractors' and DENY specific access as needed.
Like before, everyone is a contrib, but contractors have some absolute limitations imposed on them, and the 'DENY' in the Contractors group overrides the 'Allow' from contrib. A use case for this would be cases where specific code has to be hidden from external vendors or some other sub-group and needs to be 100% rock solid - just be careful with denies as they will trump any number of allows you inherit from other groups.
Hope that helps!
Addendum: For restricting or changing rights on workitems, you need to do two things. First, set up appropriate group mempership (noted above), then in the project, under Team Project Settings -> Areas and Iterations, click the Security button to set this up on a node by node basis (or at the root if you want to do these restrictions project wide).