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.
Related
In Bitbucket, on any Pull Request, reviews are disabled after the PR is merged.
I'd like to continue to allow reviews after a PR is merged. Is this possible?
NOTE: I am not asking about requiring review approval pre-merge, though I may or may not have those requirements as well. I want post-merge reviews.
In Github, by way of comparison, it is possible to "review" a PR even after it is merged.
I tried clicking the greyed-out "review" button after merging, which obviously did nothing. If the page is reloaded the "review" button is entirely gone.
I have been in contact with a wonderful Product Manager at Atlassian, and he let me know that this used to be an accidental "feature" of BitBucket, which they considered a bug, and fixed as of several months ago. This is why people have a memory of post-merge reviews, which seem to no longer be possible (because, they indeed are no longer possible).
He explained that once they "fixed" the bug they heard from users who had built workflows around it, and wanted the "bug/feature" back.
There is a public issue tracker for this if you are interested in weighing in on it!
https://jira.atlassian.com/browse/BCLOUD-22396
Atlassian has not yet decided if/when/how they will bring the "bug/feature" back.
So I understand that once I open a pull request, I automatically get a code review for the code that's about to be merged, that's great! But is there a a way to create a Code review without creating a Pull Request? For example, let's say I am working on a feature and I would like to do a code review with peers, but I don't want to do a Pull Request as the feature is still Work In Progress.
I understand that I can use the "compare" feature in BitBucket to see the code diff, but I needed the "Codereview" kind of feature explicitly so that I can:
Share the code review link with my peers so that they can see it
They can comment and open "tasks" on the code
and all of it while not creating a Pull Request. Is that possible?
Question is already asked here.
The usual process is to start code review based on a pull-request (this is how I understand the usage in BitBucket).
It is acceptable to create the pull-request and mark it as in progress and you can always add more commits on the PR later.
This is explained in the official doc:
But, the pull request is more than just a notification—it’s a dedicated forum for discussing the proposed feature. If there are any problems with the changes, teammates can post feedback in the pull request and even tweak the feature by pushing follow-up commits. All of this activity is tracked directly inside of the pull request.
Your peers must be aware that you don't need immediate approval but just comments until you finish the feature (PR ready to be merged)
I would like to check in code after a code review is approved. I came across this stack about creating code reviews and checking in, but my question is a little different.
My issue is that I want to create a code review; however, I do not want to check in the code until it is approved. That limits me from being able to start another code review with removing related work items. What I would like to do is create code reviews and check in from the code review tab in the Team Explorer
Is that possible? It is the same principle as creating a code review after the check in, but with Code reviews and checking in. I do not want to go to pending changes and check in there because I may have removed the related items. But I do want a check in to be tied to my code review.
Unfortunately, there is no "proper" way to do what you are trying to do. You could have your working directory on a shared drive and just notify your reviewer when you are ready for them to start their review process, but that side-steps the accountability by not having each development/review iteration officially logged within TFS. This means you should check in your work and let the reviewer do their job, then continue on in that fashion to make any changes requested by the reviewer, check in, and get another code-review.
For completeness I will mention my suggestion from my comments here as well.
My suggestion would be to create a self-contained, short-lived development branch where you will do your development and have your code reviewed. Then once the development and reviewing has been completed to satisfaction, that branch can be merged back up and destroyed. This provides a much cleaner and safer approach. 1) It reduces the clutter in the history within TFS. 2) It prevents multiple unnecessary automated builds/tests/etc... from being triggered.
In your comment you suggest that this changes the "structure of your branching methods". I don't see how doing this changes anything in any way that matters. Your merge would be just like your final development check-in except that by this time all reviews have been completed and you are performing a single, clean check-in. It will still contain all of your check-in and review information, however instead of a cluttered chain of check-ins, you will have a single collapsed node which contains every single thing that was done for that particular task.
I would check with your manager, your code reviewer and/or anyone you have that is in charge of TFS and creating/maintaining your TFS policy. This approach really doesn't change anything in regard to how the rest of your process works. You would have simply abstracted your development cycle to a self-contained environment. The second you perform your merge you are right back into your normal process as you have it now.
Okay, so for documentation purposes. I did not fully understand the shelving that TFS allow me to do. After reading Shelve and Unshelve Pending Changes, it makes more sense to me. I can shelve what I am working on, unshelve the code that I have done a code review for, then check in that code. That way I can create a code review and continue working until that code review is approved. Once approved, I can go unshelve the changes and check it in.
Question
How do you search for commits which have ever received CodeReview-2 in the past from a given reviewer?
Context
Basically I want to do a retrospective on every commits I've ever rejected so that I can share those the comments to more people.
It's very easy to get the commits I'm currently rejecting using the search terms reviewer:self label:CodeReview-2.
But once the owner of the commit fixes the issue with a new patchset and I put a +2 on it, I won't be able to search for that commit anymore.
So I'm looking for something like had-label:CodeReview-2.
At our local installation we get an email from gerrit at each scoring.
Thus, as a workaround, you can search for emails from gerrit containing "< your login > has posted comments on this change." and "Code-Review-2".
We recently started using Team Foundation Server 2012 and are using the code-review feature to have other developers review code changes. It seems to work great; however, as a project lead I would like to be able to see that a given changeset has been reviewed by someone else.
For example, say Developer Bob makes changes and requests a review on those changes. This generates a shelveset for the changes and creates a code-review work item for the requested review. Developer Alice reviews the changes, makes some comments, and finishes the review. Bob incorporates Alice's suggestions and checks in the changeset.
As a project lead, I search for changesets and see that Bob checked in changeset 123. If I look at this changeset, there is an associated work item for the task Bob was working on, but no indication that the changeset was reviewed by anyone else.
If I look at code-review work items, I can find the things that have been reviewed and see the comments. This is cumbersome as I have to sift through work items and find the one that happens to be related.
How can I tell from a given changeset that it was reviewed, as well as see the review comments?
Changesets can be linked to any kind of Work Item, including Code Reviews. When you request a review on a set of pending changes, they are automatically associated to the new review Work Item. When you double click on the changeset you should be able to see under Related Work Items something like this:
In this case there were 2 reviews for this changeset, the second one was automatically there when it was requested. The first one had to be manually linked, just like the Task.
If you double click on the review item, you can see all the comments.
Tip: If you want to do a review post-checkin: go to the History view --> double click on the changeset --> Actions --> Request Review.
Tip2: It is a bit annoying that you have to manually check that each changeset has a review. If lack of review is really a problem for your team, I would suggest setting up a check-in policy.
You can make queries searching for code review work items and you will find associated changesets on the field Associated Context (Changeset id or Shelveset Name)
Inside the Code Review, you can check the changeset via the link at the top of the work item view.
Of course, there is another option that is querying directly to TFS Database (Warehouse) but it's tricky and requires access to that database and knowledge on the schema.
from work item history u can check out all the change sets ....changeset was reviewed by anyone else this functionality TFS does Not provide!
may be i have lost Something but i don't see any answer regarding to change set that is was reviewed.
but you can check the change through (history , and sort the source control by date ).
good luck!