As code reviewer with Azure DevOps you are able to leave feedback that can be marked with such statuses:
- Active: Comment is still under review.
- Pending: The issue in this comment will be addressed, but isn't fixed yet.
- Resolved: The issue brought up in this comment has been fixed.
- Won't Fix: The suggestion in the comment is noted, but won't make changes in this pull request to address it.
- Closed: Discussion for this comment is closed.
Is that possible to get notified when the status is changed? Right now I can receive notifications on new comments
We cannot get this notification, In the Azure DevOps default and supported notifications and supported event types have Changed by, Changes in folder, Code under review, Created by, Event type, Policy Bypass, Repository name, Reviewers, Source branch name, Status, Target branch name, Team project, Vote. And the comment will only Notify you about comments made to a pull request that you created or a discussion you're involved in.
This should be a good improvement, also I have helped you to submit the relevant suggestion ticket. To receive the notification about it in time, you can vote and follow this suggestion ticket.
Related
Azure DevOps lets a reviewer tell the developer that they have completed their review with the "waiting for the author" flag on a PR review.
But as the developer how can I tell the reviewer "I have finished addressing comments?" They may get a notification for every reply I make to a review comment but typically, we work that a reviewer won't re-review until I've finished addressing all their comments. I can send them a message but it seems like there should be a way to do it from the PR itself.
Unfortenately there is no out-of-the-box method to do this.
These are the only subscription that can be made for code (git) notification:
You could however come up with a process flow yourself, some examples:
Define that all fixes should be made in one push to the branch. The developer can fix the remark in several commits, but whenever he pushes these commits the notification is send out - triggering the reviewer to look again.
Another option is the agreement of a code word or sentence in the commit message, like: rework-complete.
The reviewer filters out these message in their mail client, to see what PR are up for review again.
Alternatively you could alter the status of a PR linked work item.
For example:
After review, the develop work item is set back to the status: Active.
Whenever this work item is closed, the review can be done again.
This will avoid unwanted, out of AzDo, message sending.
Again, no out-of-the-box solution afaik, but I hope this helps you.
PR authors and reviewers can communicate with each other by adding and responding to PR comments. When you review a PR, use comments to point out issues with the proposed changes, suggest changes, and respond to previous comments. Aim for constructive feedback that's precise and easy to understand. Address recipients directly by using their #username. Reference work items by using #workitemID and other PRs by using !pullrequestID.
Reply to comments
PR authors should reply to comments to let the reviewers know how they're addressing feedback and suggestions:
To reply to a comment, type your response in the Write a reply field. Address recipients directly by using their #username. Reference work items by using #workitemID and other PRs by using !pullrequestID.
After entering your response, select Reply & resolve if your response is final. Otherwise, select Reply.
If you select Reply & resolve, the comment status will change to Resolved. PR authors can also directly change a comment's status, as described in the next section.
Change comment status
New comments initially have an Active status, which PR authors update during PR the review process to indicate how they addressed reviewer feedback and suggestions. PR authors can select a comment status from the status dropdown list:
Active: the default status for new comments.
Pending: the issue in this comment is under review and awaits something else.
Resolved: the issue in this comment is addressed.
Won't fix: the issue in this comment is noted but won't be fixed.
Closed: the discussion in this comment is closed.
When you have finished addressing comments, you can change all the comment status to Resolved and let the reviewers know that you have responded to their suggestions.
You can refer to this document Review and comment on pull requests - Azure Repos | Microsoft Learn.
If you want a feature to highlight that all comments have been addressed in the PR, it's recommended that you could submit a suggestion ticket on Visual Studio Feedback. That will allow you to directly interact with the appropriate engineering team and make it more convenient for the engineering team to collect and categorize your suggestions. By the way, you can directly add your vote after you create the suggestion ticket and keep track of this progress there. Voting helps increase the priority of the issue by consolidating customer impact under one feedback.
I would like to ask for your help with steps to resolve a seemingly simple issue in regards with branch policies. We have the following requirement: Mandate at least 1 Pull-Request approval from a team member other than the code author. However, once the reviewer has added some comments for minor code changes to be made, and approved the PR, then for the next iteration on this PR we would like to retain the reviewer's previous approval vote so that the code author can complete the PR without waiting for any additional approvals for their latest code changes. We understand that if there are more critical code changes suggested by the reviewer, then they can simply vote to wait or reject the PR.
Could you please help provide steps to achieve this scenario to retain reviewer's approval votes over successive code iteration/s? Thanks.
Assuming you are using Github, do the following
Go to your repository
Click on the settings tab
Click on branches on the left
Edit the branch protection rules
Under "Require a pull request before merging" uncheck the box that says "Dismiss stale pull request approvals when new commits are pushed"
Edit: my bad, completely overlooked the azure devops tag. See if the following works for you
Under Branch Policies, set Require a minimum number of reviewers on, and uncheck the box that says when new changes are pushed.
Found documentation here.
When a user hits Resolve on a review comment I made in a PR, I would expect to see a notification in my emails but I do not seem to be getting them.
Here are the options available to me in DevOps:
Here are the options assigned to my user:
For reference, this is the section I'd expect to get updates for when set to Resolved:
I'd imagine it to work similar to how it works in GitHub. Currently I'm relying on team members to #mention me.
I am an employee of an organization. Could it be that the option has been removed from me in some group policy?
Could it be that the option has been removed from me in some group policy?
I am afraid there is no such specific settings to get the notifications for Azure DevOps PR review comment set to resolved.
We could only defined the notification for the Pull request changes. But the default and supported notifications and supported event types do not support to check the state of the PR review comment.
You could add your request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/content/idea/post.html?space=21 ), which is our main forum for product suggestions. Thank you for helping us build a better Azure DevOps.
Is there a way to set up a git hook to alert a developer when someone has commented on their pull request. It is frustrating that I stumble on a comment days after it has been posted
Check out the new github app in the Slack App Directory. It sends notification about almost every change on your git to Slack, including comments.
The main project for GitHub/Slack integration is github.com/integrations/slack.
It does include repository activity:
Subscribe to an Organization or a Repository On repositories, the app notifies of open, close, and re-open events on pull requests and issues in repositories you've subscribed to.
It also notifies of any push directly to the repository's default branch as well as comments on issues and pull requests.
However, regarding comments, see issue 578:
If issue is closed with a comment, the comment should be included in the Slack notification
A lot of times the final comment has some context on why the issue is being closed (e.g. fixed, duplicate, something else). If someone clicks the "comment and close" button, it seems helpful to include that comment to the "issue closed" Slack notification.
So you don't always have every comment every time.
Note: today, GitHub adds "New improvements to the Slack and GitHub integration", namely new Slack commands, but nothing regarding comments.
If I raise a Pull request and if I need to be notified by a mail saying --
You have created a Pull request for "bla bla" on "so and so" date.
On merge - I get a notification
On comment - I get a notification
So my question is...
Are there any such settings in github which sends a mail to PR creator?
Can I tag myself in the PR comment ?
Any help !!
Are there any such settings in github which sends a mail to PR creator?
There's currently no setting in GitHub that makes the platform work in that way. Note: You can send an email to support#github.com to request for such a feature.
Can I tag myself in the PR comment ?
Yes, you can. But that won't trigger an email sent to your mailbox
However, if what you're after is keeping track of your own activity on GitHub, there may exist another alternative: GitHub exposes atoms feeds for various endpoints. The user is one of them. Register your own feed in a RSS reader and you're done.
Syntax: https://github.com/{:user}.atom
Sample: https://github.com/mojombo.atom
I'm surprised that despite being up for so long, this question hasn't really been meaningfully addressed. Axibase designed a cool little tool which can do exactly what you're describing here: if a PR is raised in one of your repositories you'll be notified via email or third-party messenger service.
By default the rule will fire when anyone raises a PR, but it can be configured to only respond to specific users as that seems to be one of your requests.
The workflow here describes the underlying mechanics of the tool and this guide will take you through the entire set-up. The whole process should only take about 10 minutes from start to finish.
Disclaimer: I've worked for the team that develops ATSD, which is the database at work here.