One of my pet peeves when using GitHub Actions are Docker based Actions that build on every single run. It’s such a wasteful and error prone way to create an action. Not only does it take longer to set up the action when you run it due to whatever command is ran in there, also any issue on the network will make it fail and requires human intervention to start it up again. In this post I’ll go over my set up of using tagged images hosted on Docker Hub/GitHub Container Registry, and how to make the username/action@v1
way of versioning Actions work with that.
When I first started creating my first GitHub Actions testing them wasn’t much of a thing. It mostly happened by doing some form of throwing different scenarios at it and manually looking at the result. At least that was it for me. More complicated actions had unit tests but no assertions on the workflow level. That changed when GitHub decided to change the way an action (or anything in a workflow) can set outputs.
One of the things I’ve been planning for months, is to move my self-hosted Redis
, PostgreSQL
, and MySQL
servers from hosting it inside my Kubernetes
cluster to managed hosted at DigitalOcean
.
At $15 each, I would have to save at least $45 on Kubernetes
cluster resources (nodes and volumes) by moving them. In the end, I succeeded at that and probably will end up saving even more as I’m
moving some Prometheus
exporters for certain things into my home Kubernetes
cluster. (Less expensive per month to run and not super important to have a high uptime/availability, to be honest.) Plus I’ve
been cutting down on services. On the plus side it comes with shiny graphs to look inside how the managed databases are doing