I often find myself stuck in a situation with a third-party Helm Chart where a particular manifest manipulation has not been exposed by the developers to the values.yaml, which in turn prevents me from installing the application in the way I’d like. Out of the box, Argo CD allows you to deploy from a Helm Chart, flat yaml manifests, or from a Kustomization manifest. However, what you can’t do is take the resulting manifest from a Helm Chart and post-render it through Kustomize to overcome this problem.

I wrote a lightweight container to post the status of a CI task to GitHub, allowing GitHub users to see the status of a PR or Branch. Designed for cloud native workflows (eg Argo Workflows, or Tekton), but will run wherever a container can be run.

This was originally written by me and published on the Argo blog in May 2021.

I recently collaborated on an Argo CD plugin called ArgoCD-Vault-Replacer. It allows you to merge your code in Git with your secrets in Hashicorp Vault to deploy into your Kubernetes cluster(s). It supports ‘normal’ Kubernetes yaml (or yml) manifests (of any type) as well as argocd-managed Kustomize and Helm charts.

I’ve been studying for my CKA exam and the focus is on churning out the right commands at a fast pace, as well as modifying yaml in the command line. I’m not a terribly slow typer, but I do rely on graphical IDEs in my day-to-day work and I’m usually a single-shell-window kinda guy.

Ever wanted to see the temperature of each room in your house plotted on a graph against the current outside temperature and the temperature you’re requesting from your boiler? No, me neither… but I’ve written a thing to do just that.

Yes, it’s another Sorry Cypress post, sorry!

For some reason, the official Cypress Docker images are a bit odd. They seem to be programatically created but there’s never any consistency between npm versions and browser versions. They contain repetitions across the layers which cause them to be bulkier than they need to be too. To make things worse, their images contain critical vulnerabilities that they have no interest in resolving.

So you’ve gone and set up Kubernetes backups… Nice one. You’ve probably used Velero if you haven’t used something native to your cloud provider. Velero is a solid tool, admittedly with a few quirks, but it gets the job done and can be relied upon. But how can you be certain the backups worked? You could manually restore every now and then, but that’s not very DevOpsy.. plus it’s really boring. Here’s how I did it.

I recently had a requirement to execute a small python script inside a cron job. This script produced a series of metric values that we ultimately wanted to be able to represent on a graph and alert on in the future.

Continuing on the Sorry Cypress theme. I thought it might be useful to demonstrate how I integrate our cypress tests in a Jenkins pipeline. There are other example of this on the web but they don’t cater for Jenkins running in Kubernetes, spinning up kubernetes pods as the executors.

Here at ${job} we use Cypress for our test automation and I wanted to integrate it more deeply with our CI/CD stack which sits on top of Kubernetes.