Simplify Code Review Process with Auto Mention Code Review Systems
As Tokopedia grows fast from time to time, so does the number of sub-teams and modules in our android team codebase. Each sub-team usually owns a number of modules, depending on the size of each sub-team. We use CODEOWNERS file system from GitHub to make sure that every code changes to a specific module should be reviewed by at least one of the members of the sub-team that owns that module.
Actually this system is great for securing the codebase from breaking changes. The only problem is: when we create a pull request (PR) with huge changes in a lot of modules and want to request for code reviews.
The Problem
What we usually do when we want to request for code reviews on our PR is by checking out who’s sub-teams are the codeowners by looking at the top right corner of the GitHub PR page.
Then we find out the list of persons that belong to each sub-team. For example, we want to know who are the members of android-minionkevin-dev, then we go to the sub-team page.
After we got the member list, we slack DM them one-by-one so if one team member is unavailable for reviewing (taking leave, in a meeting, etc), the other member can do the code review. After the review process finished and approval given, everything is done. Really? No no no.. not that easy fellas!
Remember that is just one approval from one CODEOWNERS sub-team. You have to repeat the whole process all over again for all sub-teams that own the modules changed in the PR. If you make changes to substantial things like the library that are used in many modules, you usually need to get approval from 10 or more sub-teams.
Frustrating? Yes. But those are just from the PR creator side. From the reviewer side, there is also one freaking thing: you should find out yourself which files are yours from the list of hundreds of file changes on the PR.
This cumbersome and frustrating process is there from times to times, until I have an “Eureka!” moment and figure out a solution to end this pain across all android teams.
The Solutions
I actually thought to myself: If there exists a system to notify all members of each CODEOWNERS sub-team that need to review a PR, along with lists of file changes that are mapped for each sub-team, it could solve all the problems, both for the PR creator and reviewers.
So I started with utilizing Slack, as our main communication and notification tools across the entire company. First, I create slack user group for each CODEOWNERS sub-team, so that we can just mention the user group to notify all of the sub-team members, instead of slacking them one-by-one.
Here is one example of slack user group, that you can just use @android-core-dev to get attention from all the core team members, instead of mentioning them one-by-one (look, I’m there btw 😂)
After that, I create a slack channel #android-auto-mention-code-review where all code review related matters will be inside here.
As you may notice from the above picture, yes, I automate the process of mentioning each CODEOWNERS user group that needs to review a PR via this little cute yellow Android Bot. What you have to do to trigger this bot is just comment /check review on your PR, and just watch him working hard to get approval from all CODEOWNERS needed.
This little bot also list all file changes needed to be reviewed by specific user group in a thread reply to the mentioning slack message, so the team members can directly look at the file list via Threads menu in the upper left corner of the Slack Apps, without going back and forth to the code review channel
Here is the example preview of that automatic thread reply
From there, all core team can know that from all 26 file changes in PR #14123, ten of them are belong to core team and need to be reviewed by them. Also, if there is any change requested by core team, the PR creator can just reply to this thread again to notify core team again that the change request has been addressed.
Although this invention and approach are hard to think until I figure it out, the tech ingredients that I used to create this magic is pretty simple and not a matter of rocket science. Basically, all we needed are just these components:
- The way to detect /check review comment on a PR
- The way to programmatically obtain changed files list of a specific PR
- The way to programmatically obtain CODEOWNERS file content
- The way to programmatically mapped changed files list to each CODEOWNERS sub-team
- The way to programmatically post something to slack channel
Let’s break them out one by one!
So, to detect /check review comments on a PR, we simply use webhook system that is provided by GitHub. With this system, your company server machine can get notified when any GitHub event happened on your company repository, including new comments on PR. This notification includes what is called webhook payload, which consists of the event details. So what I do is getting the commented PR number along with comment body, check if comment body equals /check review, and then trigger auto mention code review Jenkins job, with commented PR number as parameter. Here are the docs of GitHub webhooks if you want to explore more.
After Jenkins job triggered, the first thing that the job do is to obtain changed files list in the commented PR. Fortunately, GitHub also provides this functionality through their API. Just pass the PR number and you are good to go. Don’t worry about :owner and :repo params, cause there are the same as in your ordinary GitHub repo url (github.com/:owner/:repo). Just hardcode them to keep it simple!
Then we need the content of the CODEOWNERS file. Again, we can use this API from GitHub to obtain it. Don’t forget to add this field in your request header
‘Accept’: ‘application/vnd.github.v3.raw’or else you will only get encrypted content that is meaningless 😂
Now we have all the ingredients needed: The changed files list and the CODEOWNERS content. It’s time to cook them together so that we get delicious food: Separated changed files list for each CODEOWNERS sub-team. It seems complicated at first, but if you do further analysis, nothing to be scared of by exerting brute force iteration with n² complexity.
Imagine you have a very huge codebase in your company with 100,000 files inside a single repository, and you also have 1,000 lines in CODEOWNERS file. In worst case scenario — when you create a PR that changed every single file in the repo (100,000 changed files) — you will iterate 100,000,000 times to compare each changed filename to each line of CODEOWNERS. That is below 10 seconds for most of the computer nowadays with an average filename string length of 50. Very acceptable!
Lastly, we need to serve that delicious food to the customer. I use this pretty simple API from Slack to post full custom messages into #android-auto-mention-code-review slack channel, including user group mentions, PR links, and list of file changes in a reply thread. Please read my previous post to get more detail into how I did this step-by-step.
Conclusion
After this auto mention code review system is implemented, the code review process is much simpler and not as frustrating as earlier. Developers are happier, work-life balance can be attained, as they have more time to spend with their families instead of struggling with the stressful code review process. Henry Pri once again saves so many lifetimes of android developers at Tokopedia.
Want to be a hero too? Just use this invention, and treat me a cup of coffee if you get a noble prize from your company. Just kidding ;)
