@tkopecek This can be set per build tag, right?

yes

Just one note that this will slowdown builds quite a lot, because the bootstrap chroot would be created once for SRPM task and then for each arch...

It would be much better if Koji would learn how to create podman images and automatically generate one after newRepo finishes (if packages in image changed). This would make it very fast and reliable...

I see bootstrap_image as a workaround, not as proper long-term solution for prod. I think, that builders should be able to do that installation without bootstrapping. So, usecase for me is, that if I've RHEL7 builder for building F33 packages, I need to have one image "f33-base", which I can reuse every time, while buildroot is installed from current repo. I was not thinking about updating that image every time, more one-super-tested-image-per-product.

Extending it to have docker image for every repo would mean a totally different approach (I had some PoC of that) but mock was comletely obsoleted by that. I could do everything inside container in that moment. We've been discussing it a bit with @mikem and result was Abstract Buildroot Interface https://koji-planning.readthedocs.io/en/latest/Proposals/kbi.html which which should allow us to do such things.

Other option I was thinking about was to limit image to what is in koji (so, probably some docker image import by OSBS or manually). It could download it by nvr (or via buildroot contents), so it could be isolated from outside network completely.

As it stands, code-wise, this LGTM. :thumbsup:

:thumbsup:

trivial thing: maybe adding some warning to indicate that mock_boostrap_image is disabled on this builder?

testing-ready tag was removed because of conflict in QE build. Will be tagged again after testing.

rebased because of conflicts and removed testing-done

:thumbsup:

Commit 6d11e0ed fixes this pull-request