When Tails first got released to the public. DevDojo opened up the repository for contributions. Prompting pull request after pull request to come in. Some being ready to merge into the project from the first request. But some that required some changes. Here's how I go about reviewing those pull requests with the help of the GitHub CLI tool and Live Server.
The request.
When a request comes into the repository, the first thing I do is I view the request on the web. I look through the request body what the contributor has written. If they've added any images of the component. Then I take a quick look at the code in the browser and see if anything catches my eye before I checkout the code.
The checkout.
After I've taken a brief overview of the request and code, and have decided to start reviewing. I open vscode and travel to my personal fork of Tails. From there I run the following command.
gh pr checkout --repo thedevdojo/tails {pr}
With the {pr} in this case being the pull request ID number. If you've ever tried to checkout with GH before. You'll know that when you first run pr checkout and you have multiple remotes. In my case, I have two, my fork located under origin and the upstream.
A prompt will appear asking which repository GH should use as the base. I've set mine to my origin, that's why I have to pass in the --repo flag to specify which repository I'm searching in.
After this command has run, GH will pull down the branch from the request, add it do a new branch on my local version of Tails, and checkout that branch for me.
The review.
This is where the fun begins for me. When I have everything locally. I will open the component and let the linters I have installed do a quick scan of the file. Then since I'm lazy. I open up the landmark template, copy the head. Paste that into the component and open the file with Live Server. From there I can see how the components look in different browsers. Check the responsiveness of the component and, play around with changes I'd like to suggest.
Having the request in a local branch gives me more freedom when testing the component. It also allows me to easily create a new branch of the request to submit my own pull request back to the initial request should the need arise.
Suggestions.
Now that I've done my checks and have looked through the code, I'm ready to make my suggestions. With the pr view command, I can easily open the request in the browser.
gh pr view --repo thedevdojo/tails --web {pr}
With the request opened in the browser, I can start to formulate my suggestions. I usually start by writing my suggestions down in the main review comment. If I feel that something I've written down is better suited as an inline comment, I will remove that part from the overall comment and move that into an inline comment. This also allows me to make direct suggestions for code changes.
View Website
View Website
View Website
After I've written down all my suggestions. I take one last look over everything I've suggested. In my final overlook, what I mostly look for is. Have I explained my suggestion in a way the contributor will understand? If not, I rewrite and change until I feel it's understandable.
Finally, it's time to check the Request changes box and submit my review. After that is submitted. I move on to the next one and wait for a response or changes from the first request. Then rinse and repeat until the request is approved and merged.
In conclusion.
Submitting a review isn't that complicated when you boil it down to a few steps. I also see it as a learning experience for myself. As I have to think more carefully about the code I'm reviewing. And get to see how contributors have structured their code and solved their problems.
In the end. It boils down to a simple premise. Reviewing code is fun.
Comments (0)