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, <otay...@redhat.com> wrote: > > > On Tue, May 30, 2023 at 9:47 AM Debarshi Ray <rishi...@lostca.se> 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@lists.fedoraproject.org> 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.git >> > > In 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
