@SHG-bot, aiming for better Pull-Requests
DISCLAIMER: I use Dark Reader for black on white display reducing eye strain. So don't be spook by the upcoming screenshots.
TL;DR: Github bot made on my personal free time to make Pull-Requests more empathetic.
At Sport Heroes Group (SHG), Pull-Request are a major part of the development process.
Any code proposal has to go through peer-review and need at least 2 approvals before it can be merged. As a Pull-Requests are a place uniting developers. It is a place raising awareness between coworkers concerning the codebase and where debates arise every so often.
When you add labels, unit-testing, acceptance-testing and code coverage to the mix, you soon start to realize that Pull-Requests are also a very cold and rather stern place by nature.
Here at Sport Heroes Group (SHG) we use CircleCI as build automation and release tool. It has neat features, notably with their workflows introduced their version 2.0, but its integration felt incomplete to me.
- If your build fails you don't get to see the reason why.
- To see the coverage diff you have to scroll at the bottom of your job details.
- You can't adjust PR labels dynamically based on the build results.
By default, you only get an overview of which jobs of your workflow passed:
But when you have failing tests, let alone deprecation warnings, you have actively browse to get the details. And with PRs it can also be nice to know the coverage diffs. I also was dreaming of an automated PR labeling.
The birth of @SHG-bot MK1
One evening I decided to figuring out how to automatically comment a pull-request. Once I did, I also decided to include auto-labelling as a feature. A few bash lines later, I ended up with a basic result that did the job. Now we could see some coverage details.
@SHG-bot MK2 - Coverage diffs
It was good, but not good enough to my taste. I really wanted to have the coverage difference between the existing codebase and the change proposal. Something to note here: tools doing this exists, but requires you to pay several hundred of dollars monthly to do so.
Another evening I committed myself to figuring out how to achieve this goal. This lead me to writing an obscene amount of bash until I reached the end of my journey late at night and got the results I wanted.
We were getting there, numbers are nice but but not visually mind-blowing. Which lead few days later to MK2.1:
@SHG-bot MK3 - Contextualized reactions
One day I stumbled upon a popular repository containing a GIF bank classified by reaction. It gave me an idea of how I could improve my bot. What if PR comments were reacting to the current state of you PR?
A PR can be in one of 3 different states that have their own "pool" of available reactional GIFs
- tests passing
- tests failing
- tests passing but with deprecation warning(s)
Now, whenever your tests pass you get congratulated:
If one (or multiple) of your tests are failing to pass you also known it:
And because deprecation warnings are hard to see buried in hundred of lines, I've also add a specific case for them to clearly highlight them
I am quite proud of the results and I think they are a nice addition to PRs. I would love to have colored keywords but it will have to wait until Markdown can support this idea!
Thanks for reading this :)