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
Related
I forked a repository A.. say B
I created a pull request from branch B.branch1 TO B.master
The pull request got some review comments.. I resolve them and so on..
I now want to change the base from B.master to A.master(parent repo)
How can I do this in case of an existing PR?
Since I am not seeing the option to change the base branch to another repo..
I know I can create a new pull request but that would lose all the review conversation.
A pull request is an entity that is tied to the repository it was created in. Other repositories (even if forked from the original repository) may have other rules regarding pull requests, code reviews or repository access in general. The developers giving you a code review in fork A might even not be able to do so in fork B.
Therefore you can not move your pull request to another repository.
I suggest you close your current pull request and open a new one. You can link to the old PR and explain the situation so people can still see the code review conversation that was going on in the original PR.
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.
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.
I'd like to automatically (i.e. from Jenkins) merge a GitHub pull request that has been approved by a person and has been tested successfully; in other words, when all THREE of these checkmarks are green:
Is this possible? I haven't found any documentation on an API for GitHub's new "changes approved" code review functionality.
There is a new PullRequestReviewEvent webhook that is triggered when a review is submitted in a non-pending state. The body of the webhook contains the ["review"]["state"] field, which will be approved when all reviewers have approved the changes (i.e. when you get the green "changes approved" tick in the UI).
Combine this with the StatusEvent for the head SHA of your pull request to get the status checks from CI and so on, then finally check the "merge-ability" of the pull by requesting the pull request from the API:
GET /repos/:owner/:repo/pulls/:number
Once you have all three things, you can merge the pull request with:
PUT /repos/:owner/:repo/pulls/:number/merge
and appropriate payload parameters. Note you'll need the Accept: application/vnd.github.polaris-preview+json for some of the payload parameters as they are in a preview period.
Official documentation: "Managing auto-merge for pull requests in your repository".
That is now (Dec. 2020, 4 years later) available:
Pull request auto-merge public beta
Pull request auto-merge is now rolling out as a public beta!
With auto-merge, pull requests can be automatically merged when all requirements for merging are met. No more waiting for long checks to finish just so you can press the merge button!
To use auto-merge, a repository maintainer or admin must first toggle on the repository setting to allow auto-merge (see steps).
Then any user with write permission can enable or disable auto-merge by navigating to the pull request page.
Keep in mind that auto-merge is only available for pull requests targeting a branch with required reviews or required status checks, and therefore is only available on public repositories and private repositories on Team and GitHub Enterprise Cloud plans.
Learn more about pull request auto-merge.
Update Feb. 2021:
Pull request auto-merge is now generally available
With auto-merge, pull requests can be set to merge automatically when all merge requirements are met.
No more waiting on slow CI jobs or tests to finish just so you can click the merge button!
To use auto-merge, first have an administrator allow auto-merge in the repository settings.
Then to enable auto-merge, navigate to the pull request on GitHub.com or GitHub Mobile and tap the button to enable.
Note that auto-merge can only be enabled by users with permission to merge and when there are unsatisfied merge requirements, like missing approvals or failing required status checks.
GraphQL APIs will be rolling out later this week. The pull request webhook event also now includes actions that indicate when auto-merge is enabled or disabled.
Learn more about pull request auto-merge
However, as The Godfather mentions in the comments:
The problem with this is that it doesn't do auto-update.
So as soon as your repo has "branches must be up-to-date" and some other PR got merged, this "auto-merge" doesn't work any more.
It should have been called the same way as Gitlab: "merge when pipeline succeeds", at least it's not as confusing... –
Update Aug. 2021:
Maintainers can now manage the availability of auto-merge in a repository
Maintainers can now manage the repository-level "Allow auto-merge" setting.
This setting, which is off by default, controls whether auto-merge is available on pull requests in the repository.
Previously, only admins could manage this setting.
Additionally, this setting can now by controlled using the "Create a repository" and "Update a repository" REST APIs.
I wrote an app that does this. It responds to the review, labelled, and commit status/checks events, and merges when the merge button is green.
The fact that it merges when the merge button is green means that you can configure the requirements for a mergeable PR in the GitHub settings, there's no need to write separate configuration for the app.
Mergery is:
Free, including for private repositories.
Fast. It's event-driven, it doesn't run on a schedule.
Simple. No configuration required. Just label your PRs with automerge.
You can use Mergify to do exactly this, since this is what it has been created for. Just set up a minimal .mergify.yml file in your repository:
rules:
default:
protection:
required_status_checks:
context:
- continuous-integration/travis/pr
required_pull_request_reviews:
required_approving_review_count: 1
And you'll be good to go.
(disclaimer: I'm one of the Mergify founders)
Using github actions which is one of the new ways, this can be done. I have written a blog about auto approving and auto merging PRs using github actions. However, if the intent is to just merge the PRs only, then then the second job in this work flow would be enough to do it.
https://github.com/bobvanderlinden/probot-auto-merge is a free GitHub app that does the job. It's configurable in .github/auto-merge.yml.
I have a branch in which I (automatically) apply some patches from pull requests.
I do so by committing the PRs' diff and have a commit message like this one
PATCHED | Apply patch https://github.com/randombit/botan/pull/386
Now every time I do that in a commit that is hosted on Github, the PR gets referenced.
In my case this does not add any value to the PR itself, as it is referenced multiple times and not part of any discussion. Can I suppress this referencing from my commit message?
This is what happens when I create a bunch of different commits that have a PR url in the commit message:
Here you can verify that totally unrelated commits create references just by commit message parsing:
https://github.com/webmaster128/dummy-github-ref-test
https://github.com/randombit/botan/pull/386
One simple thing you could do is, not write the reference to the PR # in a way that github will parse it as such.
So, instead of
https://github.com/randombit/botan/pull/386
or
#386
you could try writing just
Pull request number 386
The fanciest thing that I could imagine doing is,
https://myserver.com/botan/pull/386
and then setup your server to redirect such queries to your github page... That way, you still get a clickable hyperlink in the commit messages, but you subvert github's referencing. It's a lot more effort than the alternatives though.
Edit: This is the most complete documentation I could find about github references in gfm. Here is some additional info about the parsing they do for 'closing issues via commit messages'. I couldn't find any more detailed documentation.
Now every time I do that in a commit that is hosted on Github, the PR gets referenced.
This is what pull request is all about, any change made to the given branch is added to the PR and any contributor is being notified about it.
You will keep getting notification until you will do one of the following
Close the pull request
Once the pull request is closed it will not track changes made to the given branch
Unsubscribe
Click on unsubscribe option in the pull request
Close the pull request
Close the pull request by accepting or declining it