+1

+1 on this, provided that the questions about getting the toolbox integrated with the compose are resolved.

This did not receive enough responses in a week. Waiting one more.

+1

+1 sounds like a good idea

+1

+1 but... I would love it if we could just move this to a base image as @otaylor suggested on the list. That discussion seems to still be going?

After 14+ days, this is APPROVED (+6, 0, -0)

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZX5SUHRTJK2N4DV656A2SNLUISAUK7GC/

So this is accepted, but the Change is still at "ChangeReadyForFesco" stage, so it's not in the F39 ChangeSet - https://fedoraproject.org/wiki/Releases/39/ChangeSet . Can someone remedy that? Tagging @amoloney , though I know it's not your real job, thanks for helping take care of this lately.

Also, it seems like this was accepted without the releng side of things being fully worked out:
https://pagure.io/releng/issue/11399
that ticket has been just sitting for two months, with no clear plan in place. This concerns me.

@kparal and I have been talking about this (beginning from reviewing the release criterion, but we can't write a sensible criterion without a sensible process). From the QA perspective, what we need is that - at least for release candidate composes, but ideally for nightlies too - the toolbx image that is part of the compose needs to be published to the registry (using some non-default tag, the 'testing' tag or whatever). Then we can have the tests for this (once we write them) test both the CLI command and the container image.

Otherwise, we're going to wind up testing only the CLI command, but it will be using some older image, and we will not have tested the image we build before it gets pushed out to the default tag.

Also, if this is to be accepted, we really need the toolbox image to be considered a non-failable deliverable so far as the compose process is concerned - i.e. the compose fails if building the toolbox container image fails. (This is how it works for other release-blocking deliverables). Otherwise we run the risk of signing off a release with no corresponding container image.

Just to circle back here, releng has been discussing this and was waiting to see if we could just move this to being another base image (which would be a lot easier for us and skip the container building pipeline). That seems to be ok, so there's already a PR to add a kickstart for this.

So, it would just be another image created in composes, could be markede non failalble, etc.

Can I go ahead and update this so it shows up in the F39 change set then?

Just to circle back here, releng has been discussing this and was
waiting to see if we could just move this to being another base
image (which would be a lot easier for us and skip the container
building pipeline). That seems to be ok, so there's already a PR
to add a kickstart for this.

Yes, as a Toolbx maintainer and Change co-owner, I am OK with defining the fedora-toolbox through a kickstart file instead of a Dockerfile.

Can I go ahead and update this so it shows up in the F39 change set then?

Yes, please do!

Yes, as a Toolbx maintainer and Change co-owner, I am OK with defining the fedora-toolbox through a kickstart file instead of a Dockerfile.

Thanks!