Version pinning used to be someone else's job
Before I started this portfolio-with-a-pipeline project, I didn't know that pinning a version was something anyone needed to do. Now, I know it's one of the things keeping my pipeline from breaking when a software version updates.
Two failure emails
I got a couple of emails the other morning saying that two of my scheduled tests had failed: the llms.txt verification test and the API reference screenshot test. As one does, I asked my robot minion (Claude Code) to find out why.
Neither test had actually run. Every workflow in my repo runs on a temporary machine that GitHub supplies, and the message on both jobs said no machine ever picked the job up. GitHub's status page showed an Actions incident that started about 20 minutes before my tests were scheduled. The tests that ran earlier and later that day all passed. The fix was to wait for the next scheduled run. So, no big deal.
The notice next to the failures
Claude Code also pointed out a notice that GitHub had attached to every run, passing or failing. Starting October 19, the ubuntu-latest label moves to Ubuntu 26.
Every one of my workflows had the line runs-on: ubuntu-latest. That line doesn't name a version. It asks for whatever GitHub currently calls the latest one. On October 19, all of my workflows would move to a new operating system, and I wouldn't have changed a thing in my repo.
Most of my pipeline probably wouldn't notice. The screenshot tests are the ones I'd worry about. They compare a new screenshot against a saved one, and a different operating system can render fonts and spacing a little differently. A test could fail over a few pixels, and I'd spend a morning chasing a problem that was never in my content. No thank you!
I'd seen this before
Pinning had come up before. Earlier this year, I'd pinned Doc Detective to a specific version so that an update couldn't break my tests without warning. In September, I found out the hard way that the pin didn't cover a browser driver that Doc Detective downloads on its own (grr). That one's written up in I'm the supervisor, not the engineer.
The fix here made sense to me right away. Claude Code changed every workflow from ubuntu-latest to ubuntu-24.04, the version they were already running on. That's 16 jobs across 14 workflow files. They run exactly as before, but the upgrade now happens when I decide it does, instead of on GitHub's calendar.
The pin isn't permanent. GitHub will eventually retire Ubuntu 24.04, so at some point I'll try Ubuntu 26 on a separate branch, refresh any saved screenshots that come out different, and then take the pin out. In fact, I told Claude Code to remind me in November so that I can test it out after the initial flurry of fixes and release pains are past.
Somebody used to do this for me
In my previous life, I was a technical writer at a company where an ops team handled this kind of thing. I never saw a runner label. If a build machine changed under me, then someone else whose job it was knew about it first and dealt with it. I never heard about it.
Owning the repo means I'm that someone now. It also means I can talk about the pros and cons of pinning a version with an engineer and actually contribute meaningfully to the conversation. It's incredibly empowering.
If Git and pipelines still feel like black magic to you, set up a project of your own and own it for a while. You'll run into things you never expected to learn about, and you'll be glad you did.