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.