CodeQL is the successor to LGTM; I was hoping for a seamless transition to CodeQL, but sadly that wasn’t to be. A lot of the things that I had been previously been doing like @SuppressWarnings("lgtm[ignore-this-weak-crypto]") were being ignored, and I’ve been ignoring the security code scanning alerts as well. It’s taken a while, but now I’ve actually embarked on a journey where I am in the process of using it for some additional projects and I wanted to make sure that I have the feature set that I’m used to :- being able to suppress alerts in the code, not in an external tool. This is important because the code will always exist for the lifetime of the product but tools come and go.

I’m running kubernetes at home; it seemed like an amusing thing to do at the time. I have been using helm charts to install the things. As helm charts are updated then the underlying docker images are updated; so as a downstream consumer of the helm charts I just have to worry about whether the helm chart maintainer has lost interest / abandoned the charts. The charts from k8s-at-home have been archived in github which means they are effectively abandoned. Consequently I decided to migrate to terraform to manage my kubernetes infrastructure at least for those charts.

I now have to concern myself with when third-party docker images are updated and published.

Recently I’ve started using the gradle axion-release plugin; it’s a nice idea since I agree with its core precepts. It means that I don’t have to think about what the next version number will be since that is now derivable from git history. This post isn’t about that though, it’s about gradle plugin dependency management and the rabbit hole I found myself in.

You know what they say, you can always run Linux on your old hardware to make it useful again. I have a Mac Mini, more specifically a Apple Inc. Macmini7,1/Mac circa 2015/2016 whose usefulness is now at an end. It’s worth pointing out here that I don’t think this particular Mac was actually ever any good as a long term piece of kit; soldered RAM and having to break out my torx screw driver set never equates to fun times in my book. Still, it should be fine with Linux running on it, being a spare Kubernetes node in my homelab…

Last time I ended spending far longer wrestling with microk8s on windows than actually doing Kubernetes based things. I’ve tried microk8s on my RPi instances, and it plays absolutely fine so it was definitely the interoperability between Windows and microk8s. As a result I decided to do the same thing with kind just to reflect on the differences.

TLDR; My opinion is that kind is much better for creating sandbox test environments; I might consider something like talos as well for building out a K8S environment. Since Kind has fewer opinions, you’re not wrestling with your search engine, and you can mostly follow the vanilla K8S install guides for whatever you want. I’m still going to bootstrap K8S with an ingress controller running ActiveMQ, Elasticsearch and Kibana. KEDA is installed, and I’ll be installing Interlok later on into the cluster.