I have noticed that when you modify a comment in a Pull Request, there doesn't seem to be a way to view the history of the comment. As well, comments still allow editing after someone responds to it. One of my colleges is editing comments after he gets a response and our pull requests are not making sense because of it. Is there a history or a way to prevent changes?
Sorry but as I know it's impossible. Besides, similar issue has been submitted in this earlier suggestion ticket linked here:
Disable comment editing (i.e. add, edit, delete, and state change) in completed pull request
In addition, we can use below API to get Pull Request Thread Comments to check lastUpdatedDate and publishedDate.
GET https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/threads/{threadId}/comments/{commentId}?api-version=5.1
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.
When reviewing PR on GitHub, the is a brilliant option for reviewer
to add multiple comments as pending, and then submit them to the author as a review with one notification.
Each comment has it’s own option Reply and Resolve Conversation.
E.g. if review has 10 comments, and author wants to reply for 9 of them ‘updated in commit 12345’,
reviewer will receive notifications for each of them, which can be quite annoying.
Is it possible to make pending such post-review comments and submit them as a single notification?
If not, I will submit a feature request to GitHub.
I found existing GitHub Feature request: writing PR comments in batch #1276
and posted a workaround
The problem you described is correct if an author is using main
“conversation” tab to reply to each reviewer’s comment. As a
workaround author can switch to “Files changed” tab, and there is an
option to keep all comments as “pending” and then submit all of them
at once(simulating review of own PR)
It’s definitely not intuitive, and I would appreciate if GitHub will
implement it properly for “conversation” tab
I'm building the Github PR comment to Travis build thing from my previous question (since it does not seem to exist), but I'm running into the problem:
Github sends a webhook call for Issue comments (which is how they call PR comments)
That comment payload has an issue object attached to it.
There is a lot of stuff in the issue but information about what branch the changes are in is not one of them.
I also don't see an obvious way of retrieving the branch.
Am I missing something here?
Turns out I wasn't missing anything, Github answered:
Thanks for sharing your thoughts -- I'll pass them along to the team
working on webhooks but I don't expect any changes here in the near
future. For now, for each pull request that's opened -- you can save
the head and base branch information on your end. Then, once you
receive an issue comment webhook delivery, you will know which pull
request and which branches it is about without needing to call the
API.
Running on GitHub Enterprise I have a small Jenkins job that looks for pull-request comments and triggers a script depending on the message.
Now I only want to trigger the script if review is already done from GitHub point of view, like all CODE_OWNERS and no additional person requested changes. I don't want to implement that logic myself. GitHub has different section for reviews and status checks. I only want review state, since I am going to set the status myself.
But I was not able to the correct value from the API endpoint. Neither from pull-request itself, nor from pulls/id/reviews.
Closest that i found was "mergeable_state", but this unfortunately takes the status check into consideration.
Is there another place to look for?
I don't think you can fetch the global review status. I think that the best you can do is to check that there are no review requests and fetch all reviews to check if there are no requested changes.
Finally we decided to make a Probot app in Github which was able to get all the required information.
Does anyone know of a way in GitHub to see pull requests were I am mentioned and either I have not yet commented or commits have been added since I last commented?
If you watch a repository like this, you'll be notified by everything that happens on that particular repo:
New commits will appear on your on-site dashboard and comments on commits/issues/PRs (by the way "PR" stands for "Pull Request) as well as opened/closed/merged PRs and issues will come up both by e-mail and on your dashboard.