So, whats the plan here? :)

That deliverable isn't made as part of our normal compose process. Is the intention that we move it in to be composed nightly with the rest of the compose process and if it fails, fail the compose?
I am not sure pungi can do this, but it might be possible. The base and base-minimal images are made from kickstart files, I don't think we produce anything direct from Dockerfiles.

Or is the intention/plan that we simply have QE check / test it and if it's not available, we are 'no-go' until it is?

I think that was my question in the older ticket.

So, whats the plan here? :)

That deliverable isn't made as part of our normal compose process. Is the intention that we move it in to be composed nightly with the rest of the compose process and if it fails, fail the compose?
I am not sure pungi can do this, but it might be possible. The base and base-minimal images are made from kickstart files, I don't think we produce anything direct from Dockerfiles.

The fedora-toolbox images are currently defined as a Docker/Containerfile, both upstream and downstream. There's some value in this because a Docker/Containerfile ensures a workflow that's widely known and easy to use with podman build as part of the upstream CI.

Is there no way to build the images as part of the normal compose process unless they are defined in fedora-kickstarts? Maybe a fedpkg container-build can be snuck in somewhere?

I think the most tricky milestone is the branching. Even more so than the Beta and Final release candidates.

Currently, one has to remember to jump in after branching is done, and fire off a fedpkg container-build. Until that happens and the image makes its way to registry.fedoraproject.org, folks using Toolbx on Fedora Branched/Rawhide are left in this odd state that leads to unhappy bug reports. Needless to say, we aren't always prompt to trigger the build manually, which can lead to an extended period of not having the image.

It would be a big help if Release Engineering could do this as part of their usual branching checklist.

Or is the intention/plan that we simply have QE check / test it and if it's not available, we are 'no-go' until it is?

I suppose that could work for the Beta and Final release candidates. Although, ideally, if an RPM is tagged into a new release candidate during the freezes, then the same should happen for the fedora-toolbox image. I have no idea how feasible it is for someone who is not in Release Engineering to tag in an RPM for the image, and fire off a fedpkg container-build.

At today's weekly meeting, we agreed that adding a new manual step to the release process is a last resort. We will investigate how this can be made part of our composes using container-build..

So the Change for this was accepted without the releng side of things being fully worked out (unless that was worked out but this ticket wasn't updated). I'm a bit concerned about that. See https://pagure.io/fesco/issue/3002 .

Oh, my bad
so there was a discussion on devel-list about using Kickstart to build the container. The change requester agreed. Here is pr with the kickstart https://pagure.io/fedora-kickstarts/pull-request/964

ah, great. that seems like a reasonable way to cover it. then we can just put in the compose process like any other kickstart-based task, right, and mark it as fatal so the compose fails if it fails to build? and then we just need to figure out a process for publishing it to the registry when it's done...

ah, great. that seems like a reasonable way to cover it. then we can just put in the compose process like any other kickstart-based task, right, and mark it as fatal so the compose fails if it fails to build?

That is the basic idea. I would like to get changes to config and script done together with the kickstart this week.

and then we just need to figure out a process for publishing it to the registry when it's done...

We use this script to sync the base images. It needs some updates to include the toolbox and we should be done.

Here is pr with the kickstart https://pagure.io/fedora-kickstarts/pull-request/964

Thanks for that reference. I had somehow missed the creation of that pull request and was beginning to wonder like @adamwill

Hi @rishi,

can you check if the naming of the new image is ok? Once this PR gets merged we will start composing nightlies with the container image. https://pagure.io/pungi-fedora/pull-request/1179

Yeah, so looks like the name is good. :)

Yep, for future reference, I'm putting the link to the comment where Rishi explained the naming convention: https://pagure.io/pungi-fedora/pull-request/1179#comment-189097.

Afaict the toolbox image is not in Rawhide composes yet.

That is the basic idea. I would like to get changes to config

which is now done it appears.

and script done

What changes would be needed to it?

We use this script to sync the base images. It needs some updates to include the toolbox and we should be done.

I think this is pending, but the image is needed first I suppose.

eg https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20230710.n.0/compose/Container/x86_64/images/

Thanks to @humaton the rawhide compose is now generating fedora-toolbox:39 since yesterday!

I think the next step is to get the image pushed to the Fedora Registry as noted in https://pagure.io/releng/issue/11399#comment-862130

After this PR, we will now be able to see fedora-toolbox images (updates-candidate) on registries such as registry.fedoraproject.org etc.

Toolbox is part of the regular composes now. Closing.