Please allow pinning an image to a specific version like `20250915.62.1`, so users get control over *when* image updates break their CI 🙏

[hartwork]

Description

Hello GitHub Actions,

I would like to shine a light at a key issue with how GitHub Actions image updates are deployed over time. The issue is that the repository does not currently have any control over which specific version of an image the CI is going to be run with, e.g. for ubuntu-22.04 the CI ends up running with CMake 3.29 or 3.31 depending on what image version roulette gives me:

• Version: 20250907.50.1 — CMake 3.29
• Version: 20250915.62.1 — CMake 3.31

That means that CI workflows sensitive to anything different between the two images will…

• break CI and turn all pull requests red until main is fixed with no way around it
• make fixing anything but fun (and sometimes very tricky) in particular because green CI needs image roulette to return the latest version of the image and debugging either needs just the old or just the new version (and it easily takes 10+ re-tries to get to that) — it's very frustrating.

I understand that it's not in GitHub's interest to store and make available a pile of images at the same time and "forever". I need control over when updates happen though: I have everything pinned down but the image version. Could you please let users pin a version of an image? I'm fine with that pinned version disappearing from mirrors at some point and CI to just fail for everyone that did pin a version and did not update the pinning prior to removal of that version of the image: that's fair.

I've been a happy user of GitHub Actions, but the fact that even with all other bits pinned, automatic image updates keep breaking my CI back and forth is really unfortunate, a constant pain and flawed design. It's wearing me down to the point of "I need to speak up" and it makes promoting use of GitHub Actions challenging at best. Thank you for listening!

Best, Sebastian

CC #8674

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 22.04
• Ubuntu 24.04
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• macOS 26 Arm64
• Windows Server 2019
• Windows Server 2022
• Windows Server 2025

Image version and build link

n/a

Is it regression?

nope

Expected behavior

Support for pinning a specific version of an image, e.g. version: "20250915.62.1".

Actual behavior

The image updates apply whenever they like and keep breaking CI when it is not a good time to take care of breakage.

Repro steps

Run a CI that is e.g. sensitive to the very version of CMake being used, wait for it to break, and try to get CI back to green.

[hartwork]

@alexbal45 I would like to be explicit that CMake is not an essential part of this picture: a part of the symptom, yes, but not a part of the root cause.

[RaviAkshintala]

@hartwork Thank you for bringing this issue to our attention. We will look into this issue and will update you after investigation.

[gtjoseph]

Yeah I think being able to pin image version for a workflow, even if it's for a fixed lifetime is a great idea. You could even have the image write its expiration date to the workflow log so we know when we'll need to update.

Originally, we ran everything inside docker containers of our own creation but given the complexity of our workflows and the fact that the time it took to download an image from ghcr.io could take anywhere between 1 and 20 minutes just made that approach too complex and unreliable.

Except for unexpected version changes, running directly on the runners has been working fine.