Github runner -latest labels should be differentiated

[jackjansen]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Actions Runner Image

Discussion Details

The problem with the -latest label on a runner OS is that such a label can mean two things (and sometimes I want it to mean one, and sometimes I want it to mean the other, and I can't imagine that I'm the only one):

• conservative: the tools you can expect on a downstream OS of that type if the user has kept things up to date,
• bleeding edge: the latest version of the tools that are available for that OS.

If I'm building primarily for deploying myself I probably want the latter. But if I'm building source distributions that people can just build on their machines I probably want the former.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[tomm1990]

-latest is doing double duty and github never really separated those two meanings.

today ubuntu-latest (and friends) basically means “whatever image github currently points latest at” - so tool versions move when the image rolls. that’s closer to your bleeding-edge case than “what a normal up-to-date ubuntu box has.”

if you want the two behaviors separately right now:

1. conservative / reproducible builds

   • pin the OS label: ubuntu-24.04 / ubuntu-22.04 instead of ubuntu-latest
   • pin tools yourself (setup-node with an exact version, package locks, etc.)
   • don’t assume image defaults stay forever

2. bleeding edge / “deploy what i run in ci”

   • *-latest is fine
   • still pin anything that must not jump unexpectedly, or accept that image updates can change results

also worth knowing: github publishes runner-image release notes when latest moves. so “latest” is intentional drift, not a stable contract.

a nicer product split would be something like:

• ubuntu-latest = current image pointer (today’s behavior)
• ubuntu-lts / ubuntu-stable-tools = slower-moving baseline

until that exists, treat -latest as “moving target image,” and use explicit OS + tool pins when you’re building stuff other people need to reproduce.

[tomm1990]

hey @jackjansen

if the “pin ubuntu-24.04 + tool versions for conservative builds, keep *-latest when you want drift” split was useful enough as a current workaround, mind marking an answer?

[jackjansen]

You're right, your answer solves part of the problem (so I'll mark it), but not really the things that interest me most. ubuntu-latest moves to the next LTS once every two years. And they move sufficiently far into the cycle of the next LTS that I'm fine with requesting my users install that. But then the clock starts ticking for the installed software. For example, 24.04 ships with Python 3.12, so I could standardise on that. But for a multi-platform project that's going to be a problem, because Python 3.12 is now in bug-fix-only mode, no more binary releases, so now I have to tell my Windows users to install an old version of Python.
And with something like node the problem is a bit less (because that isn't included with any of windows/macOS/ubuntu.

And if we look at Windows (as opposed to Ubuntu) the problem is worse: last month windows-latest switched to Visual Studio 2026, which is about as bleeding edge as you can get...

[tomm1990]

fair point.

you’re right that pinning ubuntu-24.04 only solves half of it. the image is “LTS os,” but the preinstalled toolchain stack still isn’t “what a random user has on their laptop,” especially across windows/mac/linux.

what i’d do for a multi-platform source distro today:

• don’t treat runner preinstalls as your baseline - install the compiler/runtime versions you actually support in the job (setup-python / setup-node / explicit apt/winget/choco steps)
• add a conservative matrix on purpose: e.g. ubuntu-22.04 + windows-2022 (or whatever you consider your slowest supported platform), not just *-latest
• on linux, a plain container: ubuntu:jammy (or similar) can strip a lot of the runner’s extra tooling if you want “vanilla distro” behavior
• document “supported toolchain versions” separately from “ci runner label” - the label is infra, not your product’s support policy

totally agree the product gap is really “give me a conservative baseline tier,” not just “don’t use latest.” until github adds that, explicit installs + matrix + containers is the least bad workaround for maintainers shipping source to end users.

if you want, share your target platforms (ubuntu LTS + which windows/mac versions) and i can sketch a minimal matrix that matches how you want users to build.

[AUG235772]

Hi @jackjansen,

You have articulated a critical point of friction for maintainers of open-source projects and distribution packages. The ambiguity of the -latest label introduces massive uncertainty into cross-platform software distribution.

Currently, GitHub's hosted runner images (like ubuntu-latest, macos-latest, and windows-latest) default completely to the bleeding-edge paradigm. GitHub Actions virtual environments are heavily pre-packed with the absolute latest stable semantic releases of runtimes, compilers, and system dependencies (e.g., Node.js, Python, LLVM, Go).

While this is ideal for continuous deployment (CD) workflows where you want to test against the absolute forefront of modern software stacks, it creates a major compatibility blind spot when compiling source distributions intended for standard downstream end-users.

---

The Developer Operations Dilemma

When a maintainer uses ubuntu-latest, their build environment is running on highly optimized, modern container base-layers. This leads to two distinct failure modes:

1. The False-Positive Success: Your source distribution compiles flawlessly on the runner because it implicitly relies on a brand-new compiler optimization or standard library feature pre-installed on the bleeding-edge runner. However, when an end-user downloads the source distribution onto a standard, long-term support (LTS) workstation, the build immediately crashes due to missing dependencies.
2. Hidden Toolchain Pollution: Automated build systems can inadvertently compile binaries against newer GLIBC or system runtime library versions present on the runner. This creates unresolvable runtime linking errors (GLIBC_X.XX not found) for users operating on conservative systems.

---

Current Workarounds for Downstream Target Testing

Until GitHub natively differentiates its runner labels, maintainers can enforce a "conservative baseline" using these tactical configurations:

• Lock Explicit LTS Versions Instead of -latest: Avoid the moving target of -latest entirely for distribution testing. Explicitly bind your jobs to specific major versions (e.g., use ubuntu-22.04 or ubuntu-20.04 instead of ubuntu-latest). This forces the build matrix to run against older, highly conservative package baselines that mimic an average user's workstation.
• Isolate via Lean Docker Containers (Linux Only): Instead of relying on the runner's pre-installed host software stack, pull an explicitly minimal, vanilla base image inside your job declaration. This strips out the runner's bleeding-edge tooling additions entirely:

  jobs:
    build-dist:
      runs-on: ubuntu-latest
      container:
        image: ubuntu:jammy # Enforces a vanilla, conservative LTS environment
      steps:
        - uses: actions/checkout@v4
        - run: apt-get update && apt-get install -y build-essential

---

Recommended Community Support Blueprint

To help elevate this feedback to GitHub's Actions virtual environment product team, copy and paste this response into your active thread to summarize the necessary architectural improvements:

+1 for this distinction. The lack of a 'conservative' or 'LTS-baseline' runner tier causes significant configuration drift between CI testing environments and real-world distribution environments. 

Currently, `-latest` is optimized almost exclusively for continuous deployment pipelines targeting cloud-native infrastructure, rather than open-source source distribution compilers targeting diverse client machines.

Proposed Label Taxonomy Implementation:
To solve this without breaking backward compatibility, GitHub should introduce a secondary label tier:
1. `ubuntu-latest` / `ubuntu-edge`: Remains the current bleeding-edge profile, packaging the absolute latest updates of runtimes and compilers.
2. `ubuntu-lts` / `ubuntu-conservative`: Matches the baseline default package configuration of a vanilla distribution install (e.g., standard apt cache versions without custom PPA/third-party injections), giving maintainers a deterministic benchmark for downstream user compilation.