My colleague submitted a pull request on a repository. I made a recommendation on renaming a function but I clicked "Approve with recommendations". However, from here I cannot do anything. I cannot "Complete" the pull request. The Complete button remains disabled.
We made a team and we gave the team Project Contributors. WHat else do we need to do? I've used Github for years and I cannot figure out why Azure DevOps UI is so terrible.
Do you have any merge conflicts in the pull request? Make sure to resolve them first.
Also, make sure that your user is not part of any group that has a Deny-policy possible overriding your Project Contributor rights.
Lastly, check the branch policies (link) to see if anything is hindering you from completing the request.
Related
I'm trying to find a way to stop users who have worked on a branch (who have committed changes on a branch) form being able to approve in a pull request on that branch. The idea that a dev can't approve their own work.
I haven't been able to find anything in the devops documentation and was hoping someone might have found a way that I've missed.
Anyone come across a solution?
Out of the box, you can prevent the creator of the pull request and the most recent pusher from approving their own changes, but you can't prevent every user who's committed to the branch from approving their changes. You likely won't want to prevent every developer who's committed to a branch from approving, because eventually, that will be nearly the entire development team.
You'll want to head to Project Settings > Repositories > Policies and update your branch policy to adjust the following settings:
Unchecked: Allow requestors to approve their own changes
Checked: Prohibit the most recent pusher from approving their own changes
Here's Microsoft's documentation on how to enable approval restrictions:
https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#require-a-minimum-number-of-reviewers
The feature Prohibit the most recent pusher from approving their own changes just prohibit the pull request creator from approving their own changes.
For example, user A create branch and push commit, then user B create the pull request.
The user B can vote Approve but the vote will not count toward the Minimum number of reviewers. And user A vote approve the pull request and the vote will count toward the Minimum number of reviewers
Prevent a user approving request if they have worked on the branch
You could add your request for this feature on our UserVoice site, which is our main forum for product suggestions. Thank you for helping us build a better Azure DevOps.
In addition, as a workaround, we could configure the branch policy and enable the feature Automatically included reviewers-> add admin as request reviewer and set the option Policy requirement to Required. Then after the administrator checks and approves the pull request, then developers can complete the pull request.
Also, If there are fewer developers, we can let each developer create his own branch, they can only work on their own branch and create pull request for their own branch, then enable the branch policy Prohibit the most recent pusher from approving their own changes to do this.
After hours of googling and search, I can't find how to add a required reviewer when people of a given team create a pull request in DevOps.
Some people will be able to contribute to our repository, but they are external to our company, that's why we want to enforce this control.
Does anyone ever did it?
Thanks.
It seems that you want to conditionally set the required reviewers according to which team the pull request creator comes from. If so, I think there is no such built-in function currently provided.
Currently only the filter condition of "based on which files changed" is provided.
You could add this feature request on our UserVoice site , which is our main forum for product suggestions. After suggest raised, you can vote and add your comments for this feedback. The product team would provide the updates if they view it.
You can do this with a branch policy in Azure DevOps Repos. In ADO, go to project settings and click Repositories in the menu in the Repos section of the project settings page. Click the repository you would like to protect with code reviews and then select the Policies tab. Next select the git branch needing reviews.
On the bottom of the branch policies page you can select Automatically included reviewers. Click the + button to add reviewers. When adding the reviewers you can select if these selected reviewers are required or optional. This is actually something of a rule-builder, you can add multiple 'rules' by repeatedly going through click + and add reviewers
There is also some documentation on branch policies that might be helpful
This is my solution, this has been work for year
Azure DevOps: Automatically add different Reviewers based on Pull Request author using Microsoft Power Automate
When we create a new Pull Request in Azure DevOps, we've recently noticed that the Reviewer is Optional by default.
This has caused some confusion, as far as I recall, reviewers were always Required by default in the past.
Has this changed?
To make the Reviewer required, I know we can do this via the 'Add Required Reviewer' option but it would be nice if we could make the Reviewer Required by default...
For recent changes you may be seeing, see the this user voice request and the blog post about the new pull request experience.
One thing we've done in the past to ensure a pull request always gets a review is create teams within the project adding a set of users of which at least one will have to approve the pull request and then update the target branch policies to add the team as a required reviewer.
you can do that by using branch policies, the bit thats called add automatic reviewers: https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#automatically-include-code-reviewers
We have an abandoned pull request which we would like to permanently remove. How can this be done? There doesn't seem to be a 'delete' or 'remove' option. Thanks.
How to permanently delete an abandoned pull request in Azure DevOps?
Sorry for any inconvenience.
I'm afraid there is no such way to permanently delete an abandoned pull request in Azure DevOps at this moment.
Microsoft thinks that data retention and traceability is important to a lot of our customers - it's not as simple as always providing CRUD operations for every artifact. But more and more customers are requesting delete pull requests, or at least the ability to delete abandoned pull requests.
Just like Spevacus comment, this feature is under Review, and Microsoft replied:
Your suggestion has been queued up for prioritization. Feature
suggestions are prioritized based on the value to our broader
developer community and the product roadmap. We may not be able to
pursue this one immediately, but we will continue to monitor it up to
90 days for community input
You could vote and add your comments for this feedback. When there are enough community votes and comments with reliable feedback, the product team members will take this feature request seriously.
Hope this helps.
While an abandoned pull request cannot currently be permanently deleted in Azure DevOps, it can be closed. The comment/update history will remain, but the pull request will not show up in the "Abandoned" list.
Delete the pull request's source branch if it still exists.
Create a new branch based on the main branch with the same name as the original source branch.
Reactivate the pull request
Close the pull request
The new status will be "Completed"
I also wanted to do this so that I wouldn't have an open pull request showing in open pull requests forever. So you can't delete the pull request, but at least you can get it marked as closed/completed. As a workaround until the delete feature is added you can do the following:
Create a temporary branch, let's say we call it "DeleteMe"
In your pull request, change the destination branch to DeleteMe
Complete the pull request.
In DeleteMe branch, if you want this updated with any new changes then you can make it updated to current. Otherwise just make any change to a file. You can add in a space on a comment for instance.
Create a new pull request to merge DeleteMe back into the original branch.
Complete the pull request and delete the DeleteMe branch.
Now the pull request will be closed/completed.
My priority was to prevent an inadvertent merge to Prod.
Hence you can:
add yourself as reviewer, then Reject; Save
as above, change the target branch to a dummy branch; Save
place [DELETED} at start of the title; Save
set the PR to Draft - that resets your rejected review
https://learn.microsoft.com/en-us/azure/devops/release-notes/2018/sprint-143-update#draft-pull-requests
or "Abandon" the PR
Two partners are building a software project. They want that each change made by one partner must be approved by the other partner.
If one of them opens a GitHub repository and makes the other one a collaborator, then both of them can change the repository without consent from the other partner. They can also ask for consent by doing the change in a branch and then doing a pull-request on the branch, but the system does not force them to do it, so they might forget.
If one of them opens a GitHub repository and does NOT make the other partner a collaborator, then the second partner must make a pull request for each change, but the first partner can still make changes without the other partner reviewing them.
Is it possible to create a repository such that, each change by one of the partners only becomes public after the other partner approves it?
I don't think such feature exists yet in Github AFAIK. But I think something like this works.
Create another account either a dummy or a bot account
Create repository from the dummy/bot account
Since you both are not collaborators, you need to fork the repository and issue pull requests no matter what.
There is a minor correction to what you said though
If one of them opens a GitHub repository and does not make the other partner a collaborator, then the second partner must make a pull request for each change, but the first partner can still make changes without the other partner reviewing them.
If you make your partner a collaborator then he too can push code to master without a pull request.
PS: Honestly, I don't think this question is supposed to be on StackOverflow.