Git aliases for CI notifications

A few years ago, I created a shell script to get notified when the CI pipeline of a pull request finished. I have used this frequently since then, but not consistently. After creating or updating a pull request, starting the script still required the extra step to execute ci-notify from the repository root, and that was enough for me to not always do it. Now, after almost four years, I finally fixed this with a simple git alias in my ~/.gitconfig:

[alias]
    monitor = "!bash -c 'git push; ~/bin/ci-notify &'"

Instead of using git push to update a pull request, I now use git monitor, and it automatically starts the notification script. It’s bizarre, but this simple change made it a lot easier for me to consistently monitor all of my pull requests. Somehow, making it a git alias instead of a separate shell script makes it feel much more integrated. Sometimes, I forget to use the monitoring alias and instead use a bare push instead. When I notice, I follow up with a git monitor, even though I could have used ci-notify instead. This again shows to me that the alias almost makes it feel like a native git thing.

I also added a second alias to create pull requests in the first place.

[alias]
    pr = "!bash -c 'git push; gh pr create; ~/bin/ci-notify &'"

For a long time, I didn’t want to create pull requests through the CLI. Before putting up a pull request for review, it helps me to see the change outside of my IDE. Seeing it in a different format often allows me to spot small things that could be removed or cleaned up which I didn’t see before. I usually do this even twice: before pushing the changes, I do a git diff in the terminal, and after pushing, I go through the change in the GitHub UI. Almost always, at least one of those triggers me to apply some change. Creating the pull request through the CLI removes one of those fresh views (at least at first).

I also like to create comprehensive pull request descriptions. I find this useful both for the reviewers and for myself. Often, when writing the description, I realize that I have to validate my assumptions, which sometimes leads to changes to the pull request. And more than a few times, when trying to understand some code and finally resorting to git blame, I landed at my pull request descriptions which usually clear things up for me. But writing good descriptions takes time. Time during which the CI pipeline could already run. That’s why I changed my stance on creating pull requests through the CLI. Before adding this alias, I started with a simple shell script, but again, the integrated nature of the alias makes it a lot easier for me to use, and I now use git pr exclusively when creating new pull requests, without really thinking about it. I don’t add any description at this stage and instead use the defaults for everything. In the GitHub UI, I first go through the changes once more (as I did before) and then edit the description, while the CI pipeline is already running. So in the end, I don’t really lose the extra view on my changes. Often, the pipeline is finished before I am done with writing the description, so I don’t even need to really context switch to fix any potential issues.

I have been using these aliases for a few weeks now, and they still make me unreasonably happy. Sometimes it’s the little things.

—Written by Sebastian Jambor. Follow me on Mastodon @crepels@mastodon.social for updates on new blog posts.