Spotify gives you Wrapped; I make myself do some introspection and examine my life rather than wondering why my top artist (categorisation error¹?) was Joseph Haydn during the year. In reviewing my development toolchain; I’ve realised that I’ve been using a variation of the same thing (git+bash on Windows with Scoop) for far too long. It’s time to shake things up a bit not least because I’ve started doing a lot more with things like Node & Python rather than Java. My experience under Windows is that it’s manageable, but i’m fighting against the tooling rather than getting shit done. WSL2 is obviously the answer to the question that I’m asking, but it means a full migration of all development into the WSL2 filesystem for performance reasons. Generating this blog under WSL2, on the Windows filesystem takes over a a minute but only takes 3 seconds if the files are in the native WSL2 VHD.

I’ve been using terraform for a while and what I’ve discovered is that there doesn’t seem to be a whole wealth of information about what to do when cold hard reality smacks your utopian infrastructure as code in the face. A classic example might be a support engineer adding LOG_LEVEL=super-verbose as an environment variable via the AWS console to some particular runtime because they’re getting reports that something blahblahblah doesn’t work.

If the first thought in your head is “That’ll never happen because IaC means they just have to modify some file; raise a PR; and then it’ll get auto deployed after going through the appropriate approval gates”; this blog post is not for you.

I rely a lot on dependabot to keep my projects up to date; however, there are some things that dependabot doesn’t yet know about. In any project there is a bunch of additional tooling that makes our lives easier, those tools all deserve to be updated to latest and greatest too! We’ve been using updatecli for that and it’s been very useful in managing updates to things that don’t get revisited that often (like pre-commit hook versions via the yaml plugin)

The github terraform provider is ace; I’ve been using it to manage my personal github repos and also my organisation ones (well, the ones I have sufficient rights to manage at least), however, one thing did strike me as I was down the rabbit hole - I can’t easily change the permissions model for workflow actions on an individual basis; I can cascade them from an organisational perspective, but not on an individual repository basis (this is true as of the github terraform provider 5.28.1). That’s something I wanted to do and since terraform is infinitely flexible I was sure that I could do something tricksy with one of the other providers without having to write my own.

GNU Make has been around for an awfully long time, and I’ve recently starting reverting back to it because I’ve been doing a lot of terraform. It’s still incredibly useful even though I’m not actually building anything locally. I hadn’t really thought about make for a long time (since not writing any C in anger), and I’ve forgotten everything that I ever knew about make. It’s a bit like riding a bike though, you’re not better than the next person, but what you are is just quicker at constructing the right search term and understanding the results because you have the memory trigger from a different era.