I think it's worth to mention that many layered container images are published directly on the Fedora's Quay.io organisation (https://quay.io/organization/fedora).
The builds are not happening in OSBS or the Fedora infrastructure but IIRC it's a GitHub Action that does the build and pushes the container image. There could be an option to leverage Quay.io build capabilities too.
On Tue, 30 May 2023, 17:02 Owen Taylor, <otaylor@xxxxxxxxxx> wrote:
_______________________________________________On Tue, May 30, 2023 at 9:47 AM Debarshi Ray <rishi.is@xxxxxxxxx> wrote:Hey Owen,
On Mon, 2023-05-29 at 12:39 -0400, Owen Taylor wrote:
> On Mon, May 29, 2023 at 8:16 AM Debarshi Ray via devel
> <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > My main concern, which I had brought up in the Release Engineering
> > tickets before [1,2] is whether the fedora-toolbox images would
> > continue to be defined as a Docker/Containerfile. I am asking
> > because the fedora base images are defined as kickstart files [3].
> >
> > There's some value in continuing to use a Docker/Containerfile
> > because it's widely known and leads to a common workflow. It is
> > used for the official Toolbx images for other distributions like
> > Arch Linux, RHEL and Ubuntu, and a growing list of third-party
> > Toolbx images [4]. A Docker/Containerfile is easy to use with
> > 'podman build' as part of the upstream CI, which makes it easier to
> > test all the different parts.
>
> Unfortunately, if we switched to using ImageFactory or pretty much
> anything other than OSBS, we'd no longer be able to define the Fedora
> toolbox image as a Dockerfile. It certainly is a disadvantage that
> it's no longer connected to the way that the other toolbox images are
> defined,
It's an advantage to have the Fedora images be defined in the same
source language as the Arch Linux and Ubuntu images, and certainly the
RHEL images. However, ultimately, I see it only as a convenience.
Folks can take the Fedora images as a reference and tweak them to fit
their own distribution, or copy paste the files across Git
repositories, etc.. If we lose that, then I would learn to live with
it. :)I guess in this scenario, the Fedora images are no longer the reference for creating things for other distributions and something else (RHEL, Ubuntu, ...) would have to take over that role. For "tweaking", I'd think we'd definitely want to promote "FROM fedora-toolbox:latest".If we do move away from Container/Dockerfiles, then my main question
would be whether it'll still be easy to locally build the images. Will
we need something a lot more elaborate than the simplicity of a 'podman
build'?I haven't actually tried building the Fedora container images locally, but it it looks relatively documented and straightforward, and someone could write a shell script to automate it pretty easily. But it is still going to require tools (ImageFactory) that people don't have installed and probably take a while to run. It seems like more of a "want to contribute to the the Fedora toolbox image" thing than a "would do it to run tests when contributing to Toolbx" thing.Toolbx has two parts. A somewhat distro-agnostic toolbox(1) binary,
and an OCI image for a distribution. Both work together to provide an
interactive CLI environment, and hence both should be tested together.
If a contributor attempts to change one or both of those two, then it
should be easy for them to verify whether both would continue to work
together. Currently, they can do that by doing a local 'podman build'
on the image definitions in toolbox.git and try to use them with their
modified toolbox(1) binary. I want to formalize this by making the
upstream CI run against both:
(a) images that are currently published on the OCI registries and
(b) images that are built on-the-fly from the sources in toolbox.gitIn this scenario the Fedora Toolbx image definition would live in fedora-kickstarts, so it doesn't really make sense for me that Toolbox CI would *recreate it*, rather than just using the version from the repository.Ideally, we'd run the Toolbox tests against the newly built Toolbx image as part of QE for the Fedora compose.... so that it will validate any changes to the image sources in
toolbox.git, and alert us to any changes in the underlying distribution
(eg., packages, dependencies, base images, etc.) that could break
future image rebuilds.
Currently, the upstream CI runs only against (a).
If we lose the simplicity of a 'podman build' then we lose the testing.
That's my main worry.
If the new set-up offers a similarly simple way of building the images
from source, then I am happy.
> but maybe that's bearable if we can substantially improve the
> workflow?
The phrase "we can substantially improve the workflow" makes me
curious. Any details or pointers?What I mean by this was simply the obvious - that the Toolbx image is built as part of the compose, and can be tested as part of the compose validation. That nobody is sitting there manually typing 'fedpkg container-build' and creating Bodhi updates. (*)- Owen(*) I'm not saying that this level of integration is impossible with OSBS - in fact there is some level of Pungi support for OSBS container builds already. Just that it's basically *already* there in Fedora for the base images.
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
