What I learned this month: Github Actions and pre-commit

This is yet again another attempt to reboot the dev part of this blog. I’m not successful, but at least I’m persistent 😉

Introduction

I’m kicking off a new serie of posts. Every month, I plan on writing about the new stuff that I’ve discovered in the broader field of software development. It’s an attempt to share the knowledge that I may have gained during that time, and also to show the world that you can be a somewhat experienced software developer and still be discovering new stuff every month.

I have observed that I tend to discover the latest hype about at the time it stops being cool. If you’re like me, we can make up for this latency by sharing ideas. Also, it requires quite a bit of time to play with software that isn’t yet ready for anything besides its original intended use case. So, let’s not waste our time.

I don’t plan on writing well researched articles, because aiming too high is a sure way for me to fail at building a habit, and that’s one of the main goals here. I’ll probably be a bit terse, with only the main links and my impressions. I hope you’ll understand. (and if you don’t, I’m not making you read this 😉 )

The two tools that I’ve selected for this month’s article are Github Actions and pre-commit.

Github Actions

D’oh, you might say. It’s been around for a while but I didn’t have a chance to use it yet, because in Fedora we run our CI on a Jenkins instance that the good CentOS folks provide us with.

But for some projects, it does not make much sense to run our unit tests on specific Fedora versions, and it’s always good to have an alternative. I’ve set up Github Actions to run CI on a couple projects that I maintain, such as fedora-messaging and flask-healthz, to test-drive it. The Python SIG in Fedora also provides a Github Action to run tox on a Fedora container, which is nice.

Another use: since Dependabot has eaten by Github, they have removed the feature to auto-merge dependency updates according to their semver classification. And I did not enjoy manually approving patch updates to my dependencies, since what I basically did was to make sure CI passed. That’s a bot’s job. So I’ve set up a Github Action that either merges patch and minor updates (but not backwards-incompatible major versions), or just approves them, waiting for Mergify to do the actual merge.

It’s nice, it’s fast, I like it. Maybe I’ll end up keeping our CentOS CI Jenkins instance only for integration tests.

pre-commit

I discovered pre-commit recently and I think it has potential. It’s a well known fact of software development that the sooner you catch a bug, the lesser that bug costs you. Find a bug during development (and even while typing the code, thanks to linters embedded in your editor) and you’ll be much better off than if you found it after production deployment.

The point of pre-commit is to run checks before the code is committed to Git. That means fast checks such as linters and formatters, and probably now your entire unit tests suite, but your mileage may vary. As for me, I usually run black, isort and flake8 as part of Visual Studio Code, so I catch issues even sooner. However, I’m not the only one to work on my projects, and for those not using advanced text editors it is a nice safety net to run the checks before committing.

I’ve converted a couple projects to pre-commit, we’ll see how it goes.

Conclusion

It’s all for this first edition. Hopefully I’ll see you next month with more findings. In the meantime, happy hacking! 🙂