Code review is finally fun and fast thanks to MergeBoard. Here we will tackle, how the reviewer and author interact and what makes this process so much safer and easier to track.
You have already been introduced to actors and how MergeBoard calculates who is currently responsible for the advancement of the merge request. MergeBoard makes it very easy for you to track this responsibility if you follow the review loop:
- 1 Author opens the merge request or pushes changes
The first thing MergeBoard will do is wait. While the CI and Scanners are running the responsibility for advancing the merge request lies with the CI and Scanners.
If the author fixed change requests, they now mark them as
Intentionalto let the reviewer(s) know these tasks are solved. While there are open change requests, the responsibility for the merge request stays with the author.
- 2 The CI results are in:
If the CI or the Scanners report a failed status, the author gets the responsibility for fixing these errors. Once they push their changes, we return to step 1.
If the results are good, the reviewer(s) get the responsibility for advancing the merge request.
- 3 Review
They can also check off all change request they deem correctly implemented or remove the
Intentionalflag set by the author to let them know, these tasks need to be tackled again. This is also a good time to add a comment, why they think this is.
If there are open change requests the responsibility now is handed back to the author again. We are back at step 1.
If all change requests implementations are approved the merge request is now ready to merge and can leave the loop.
- 4 Merge
Anyone with the necessary rights can finally merge the merge request. MergeBoard will now trigger certain actions depending on you project settings and e.g. close any connected issues.
Please note that this way of working is not enforced by MergeBoard. Both reviewers and author can e.g. post change requests at any given time or push changes to the merge request. Nevertheless, this is the intended way of using MergeBoard, though if you are having other workflows that you want to solve with our tools, let us know at firstname.lastname@example.org.
Communication is key, this is why we give you the possibility to be very precise in what you say, request and consider done.
MergeBoard allows you to communicate in threads, meaning that every user can post some comment or change request which should then be discussed in its attached thread. Scanner results can also be discussed in this form.
Used to communicate specific change requests. Works best in combination with a code reference. Make sure to select the red bug when writing your request.
While change requests have all the features of a normal comment thread they also track their implementation state. This is done using the green buttons on the top right of the thread comment.
After the change request is posted its state is open, indicated by the fact that it is neither marked as
While open you can change the state to
Fixedby simply clicking on the button or by selecting the state from the dropdown. Here you can also select the state
Intentional. Now the change request is marked as addressed.
After having set the state of a change request to addressed, a green checkmark appears. A reviewer can click it to mark the thread as approved. Alternatively a reviewer or the author can set the thread’s state back to open by clicking on
Intentional, depending on how the thread was marked as addressed.