Ci

I’ve managed to recently upgrade my image building process for this website, using some of what I have been learning about Nix. For a while while I was first learning to use Nix I thoguht of the language, the packages, and the OS as being one thing. And this did a disservice to both the breadth of what Nix offers as well as the capabilities it offers.

Old Paradigm

So previously with this site I used a fairly straightforward and manual process. I installed Hugo on my local machine with dnf, ran the dev server, and edited my pages. When I pushed the commits into GitHub, I had a Containerfile in the repository that would get built with Docker or Podman, pushing the resulting image to my image repository. I used a multi-stage file, first pulling the Hugo image to build the files and then grabbing the resulting build produts to place them into the Nginx image.

So I have talked before about what CI actually means. That post was, admittedly, rather dry and academic. I think it’s important to sometimes make the distinction between what is just regular automation and what is strictly CI. When there is automation but no CI it is still very easy for errors to slip into a supposedly stable code base, as not every commit is tested before it is merged to the main. However, with the complexity of modern software, it is pragmatically impossible to separate these two concerns, as CI without automation quickly overwhelms any manual system.

At work I have been doing CI for nearly 10 years, now. Having been working at Red Hat for the past 6 of those, some of the CI work that I do is available in open source contributions up on Git Hub. I plan to make a series of posts about that work, so I am going to start with this brief discussion of the very idea of CI before I get into working on the particular types of CI that I do.