Fedora docker tagging for automatic ci/cd updates

Ask Fedora
, , ,
1

Container image tags: rawhide and branched releases are published as bare numeric tags

The official Fedora container images publish 44, 45, 46, latest and rawhide as
parallel tags, and nothing in the tag list distinguishes a released version from a branched
or rawhide one. I run a small self-hosted GitLab with automated dependency updates, and this
caught me out badly enough that I wanted to ask whether the tagging could carry that signal.

What happened

On 2026-09-15 my dependency bot opened and merged what looked like an ordinary major bump:

chore(deps): update fedora docker tag to v46

Fedora 46 is rawhide. The bot listed the registry tags, took the highest numeric one, and
proposed it, which is reasonable given what it can see. The image it bumped is the one that
builds every other CI image on my instance.

Eleven days later, after a caching bug that had been masking it was fixed and the image was
genuinely rebuilt, every build failed:

Error: mounting an overlay over build context directory: ... userxattr: invalid argument

Rawhide’s buildah 1.45.1 mounts an overlay over the build context using native overlay with
userxattr, and in my setup the lowerdir already sits on podman’s overlay storage. The
kernel refuses overlay over overlay. Pinning back to 44 fixed it straight away.

Rawhide behaving differently from stable is expected and fine. Running it without meaning to
is the problem.

Bodhi already has the answer

Bodhi is completely clear about this. Today it reports:

Release State Branch Prerelease status Released on
F44 current f44 None 2026-04-28
F45 pending f45 None None
F46 pending rawhide pre_beta None

F46’s branch is literally rawhide and its prerelease status is pre_beta. There is no
ambiguity at all at that layer. The information simply does not reach the container registry,
where all three appear as equally plausible numeric tags.

I could not use Bodhi from CI either. bodhi.fedoraproject.org and the dl.fedoraproject.org
release index both returned an Anubis challenge page to my runner on 2026-09-28. I understand
why that is there and I am not asking for it to change, but it does rule Bodhi out as a source
for an unattended job.

Why the usual workarounds do not hold

Following the latest tag looks like the obvious fix and does not work. Renovate reports:

Can't find version with tag latest for docker package fedora

Container registries carry no equivalent of npm’s “latest version” field, so a dependency bot
can only follow a tag that resolves to a version, and latest does not. Worth noting for
anyone considering it: adding a stable alias tag would hit exactly the same wall, because it
would be an alias rather than a version.

Capping the version works and then rots. allowedVersions: "<45" blocks rawhide today, and
also blocks 45 once 45 is released, so it has to be raised by hand every cycle. A cap nobody
remembers to raise silently stops delivering updates, which is worse than the problem it
solves.

For what it is worth, latest is accurate: fedora:latest and fedora:44 are currently the
same manifest (sha256:43b29f65...), while 45 and 46 are distinct. So the registry does know.
It just cannot express it in a form version-based tooling can consume.

What would help

  1. Do not publish rawhide or branched releases as bare numeric tags. If 46 only appeared
    once 46 was released, with rawhide at rawhide and a branched pre-release at something like
    46-beta, every dependency bot would behave correctly with no configuration. This is the
    only option that fixes it for people who never find out it is a problem.
  2. A machine-readable release-state endpoint that is not behind the bot challenge. A small
    static JSON file on a plain mirror would be enough to build a custom datasource against.
    Bodhi already has the data.
  3. Document the intended pinning strategy. If bare numeric tags are meant to include
    pre-release versions and users are expected to pin explicitly, saying so in the container
    image docs would save the next person the outage.

Is there a supported approach here I have missed? And is the parallel numeric tagging of
rawhide deliberate for reasons I am not seeing?

5

bump if someone has anything for this

6

Some public APIs you can use for CI:

# Docker Hub
curl -L https://hub.docker.com/v2/namespaces/library/repositories/fedora/tags \
| jq -r '.results[].name'

# GitHub
curl -L https://api.github.com/repos/fedora-cloud/docker-brew-fedora/branches \
| jq -r '.[].name'

# Fedora
curl -L https://fedoraproject.org/releases.json \
| jq --arg arch $(arch) '.[]|select(.arch==$arch)'

Here’s an exaple getting the latest stable release:
How to fetch the current fedora version number from the web? - #4 by vgaetera

7

Thanks I will look on these and see if those are blocked by bots etc might be solid way

8

this one was the working one as it was only one that has solid tags not just numbers that my renovate bot can follow without pushing highest numbers so no more rawhide bumps. Thank you