Skip to content

setup-runner asserts ubuntu-24.04 and blocks every consumer's ubuntu-26.04 runner bump #541

Description

@Danathar

What happens

Every Renovate "update dependency ubuntu to v26" pull request in a repo that builds images through this action is blocked. Currently: projectbluefin/dakota#1592, projectbluefin/bluefin#1307, projectbluefin/common#1142. Each one looks like a harmless runner-label bump and has green lint (or fails lint only because actionlint doesn't know the label yet), but merging any of them would break that repo's image builds on the next push.

Why

bootc-build/setup-runner/action.yml, in the "Add Ubuntu resolute apt source" step (runs whenever update-podman is true, which is the default):

set -eux
IDV=$(. /usr/lib/os-release && echo ${ID}-${VERSION_ID})
test "${IDV}" = "ubuntu-24.04"

On a ubuntu-26.04 runner the test fails and, under set -e, the whole setup step dies before podman is touched. So a consumer that bumps its runs-on to 26.04 gets every build job failing at setup. The comment above that line already says:

TODO: remove when Ubuntu 26.04 runners ship a new-enough podman

The 26.04 runner images are deployed now (actions/runner-images shows both ubuntu-26.04 and ubuntu-26.04-arm live as of 2026-09-07).

What "fixed" looks like

Either of these unblocks the three PRs above:

  1. Check whether the pin is still needed on 26.04. If the 26.04 image's podman is new enough for the rechunker's layer annotations and zstd:chunked push (the two reasons the resolute pin exists), skip the resolute apt source on 26.04 instead of asserting 24.04: case "$IDV" in ubuntu-24.04) add resolute ;; ubuntu-26.04) : ;; *) fail loudly ;; esac.
  2. If it is not new enough, keep the resolute pin but make the assert accept both versions, since the resolute packages install on either.

Whichever it is, a consumer PR bumping to 26.04 should be re-run against the fixed action before merging, because PR CI in the consumer repos does not exercise the build path.

Evidence

  • dakota#1592: build.yml, publish.yml, build-aarch64.yml all call this action with update-podman: true; review there explains the failure path.
  • common#1142: build.yml calls it with update-podman: "true".
  • bluefin#1307: same, plus the actionlint label failure.
  • knuckle#918 merged the same bump fine — that repo does not use this action, which is the tell.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions