It also really depends on what you find cool, there are different ways to look at things. For example if I think of pipelines as these execution graphs that run on their own and make sure your artifacts end up in the right place, then its really fun. CI systems that visualize this make it even more interesting.

A little combination of the right personal interests and perspective goes a long way towards building up resilience to deal with the ugly bits.

I had this interesting experience back in university. We were doing some simple web service project in pairs, and it consisted of a program and some devops stuff. My partner in that project turned out to have skills that exactly complemented my own - he had trouble with the algorithmic stuff that I thought was trivial, yet he easily stitched all the services together by editing some configuration files before I even understood what any of them were for.

I would caution against trusting your build process definition to hold up to time. It's definitely better than nothing.

Even within the last few years of my job, we've had numerous disruptions to our automated builds due to everything from repo changes to version bumps in our fundamental deploy tools. I've got a self-assigned action to take just tomorrow due to how a change in how secrets management has now disrupted our performance testing process available to devs. Anecdotally, it seems more and more that as newer build tools move forward, they rarely seem to prioritize compatibility with existing methods (I'm looking at you, k8s, and your API versioning; "where feasible" turned out to be a loose definition).

It may not run to completion in the future, that’s true. However, if it’s something as simple as a shell script or a shell command list, it’s at least relatively transparent.

Unlike, say, tasks on Azure DevOps. Not a fan of those.

> There’s a nice side-effect, too: The CI definition documents how to compile the project.

Okay, sure, but that's not an argument for CI. That's an argument for a Makefile.

In fact, I find myself going back to Makefiles all the time not in spite of all these specialized build tools, but because of them. Even if the steps are straight-forward for someone who's familiar with the tools, just having a Makefile there in the repository root will be helpful documentation to help someone new (or myself in 2 years) get started with how to build the stuff. For example, for LaTeX, it could be something like:

  build: slides.pdf handout.pdf

  %.pdf: %.tex
    pdflatex $*
    pdflatex $*