feature request: tag daily builds of images

[Blaimi]

Description

You are building the buildah container images on a daily base to avoid security-problems. I think this is fine and I welcome this 👍 .

If your build has a bug like the one in #4715, it's not possible for a user to rollback to an older image until the bug is fixed to get the pipelines running.

It would be nice to have tags of the builds for at least the last one or two weeks. When you cleanup the images on a regular base, you can avoid users relying on these tags abusively.

E.g. texlive uses this strategy for their images with weekly builds (registry-link with filter-example)

Steps to reproduce the issue:

1. me: using buildah-image
2. you: implement a bug, e.g. Buildah version 1.29.1 broken fuse-overlayfs in gitlab runner #4715

Describe the results you received:
3. me: 🤷

Describe the results you expected:

3. me: temporary switch to image from the day before the bug until it is fixed
4. me: 😄

[dhduvall]

The documentation for the image, at https://github.com/containers/buildah/tree/main/contrib/buildahimage says

quay.io/containers/buildah:<version> and quay.io/buildah/stable:<version> - These images are built daily. They are intended to contain an unchanging and stable version of buildah.

which suggests that while the underlying OS bits are expected to change on a daily basis, the buildah bits stay exactly the same (or at least built from the same source), with the release matching the image tag.

I think that's a great policy, but I don't know whether it's not being implemented because the documentation is out of date and the current behavior is intentional or inadvertent.

skopeo has the same issue; I haven't checked the other repos.

Having tags for the past N builds seems reasonable, but I would also be happy with selecting the image version with the hash—only the older manifests don't seem to exist after they've been superseded, so that's not an option, unless I copy the image to a private repo.

[elacheche]

which suggests that while the underlying OS bits are expected to change on a daily basis, the buildah bits stay exactly the same (or at least built from the same source), with the release matching the image tag.

Hello,

Is /etc/containers/storage.conf part of the OS bits? Because that's what's causing #4715 (comment).

And so, the latest tag of yesterday is not the same as the latest tag of t2 days ago..

[github-actions]

A friendly reminder that this issue had no activity for 30 days.