⚠ 🛠I think we can revise this page completely. We now use merge requests in a way that is much closer to what Gitlab intends.
—nickm, 14 August 2020
NetworkTeam's Gitlab Code Review Workflow
This is how the network team uses Gitlab to do code reviews.
Marking something for review
When you write code that you need reviewed, you create a Gitlab Merge Request and a Github Pull Request (for CI to work until we get GL CI). Within that MR, you reference the GH PR.
You should also make your branch against the target maint-0.x.y branch, and your MR request against that target branch. Finally, if the MR is a backport candidate you should mention it in your MR message.
When asn and David assign reviews for little-t-tor we check for unassigned GL Merge requests in the components of little-t-tor, chutney and sbws. When we want to assign a merge request to Alice, we change the "Assigned" field of the MR to Alice.
Here are the relevant queries we use:
Finding your reviews
To find your reviews you use this query:
[ Also until we finish reviewing all the old tickets (from the pre-MR era) please also check the following links:
Reviewing your reviews (happy path)
When you do your reviews, the happy path is that the patch was good and you merge it, close the MR and the gitlab issue.
If the branch needs to get backported:
- Give the MR the
- Un-assign yourself from the MR: you don't need to review it any more.
- Put the MR into the latest milestone to which it has not been backported.
Reviewing your reviews (sad path)
If the patch you are reviewing needs revisions, you need to change the Assignee of the MR back to the patch author. This signals to the patch author that revisions need to be done (plus also adds it into their TODO list)
Revising your branches
If a branch needs to get revised, the author revises it, pushes the revised branch, and switches the Assignee field back to the reviewier (effectively also adding it to the reviewer's TODO list).