I have uploaded a draft document on the stuff needed for us to use the Fedora CI pipeline. I ll appreciate reviews. I will share this later on the infra-list and the ci lists.

https://pagure.io/ContainerSIG/container-sig/blob/master/f/docs/Fedora_Container_CI.rst

Overall design LGTM, a few questions:

• is it a short-term solution to leave bodhi and greenwave out of the picture?
• what if an image doesn't have any tests, will we push to registry.fp.o right away?
• where and how will the CI results be available? I'm assuming we'll use the same mechanism as for rpms
• I wonder how much code (if any) we need to either add to standard test roles or boilerplate b/w all the dist-git repos; meaning: install container runtime, run it, pull the image
• I think it could finally be the time to move github.com/container-image/template repo to pagure so we can prototype this over there

LGTM, I can't think about any changes/improvements right now

But it popped on my mind how/if we will be addressing CI for multi-container applications, especially where there might not be any meaningful tests for the individual containers. I have mainly openshift on my mind, but I believe there might more use cases (like kube,LAMPs???).

Overall design LGTM, a few questions:

is it a short-term solution to leave bodhi and greenwave out of the picture?

Yes, first I was thinking that it might be easier to start without and also I wanted to use this spec for the Fedora CI team so they could understand our use case. Also having the automatic update/push with bodhi will require some work and I am not sure when this will be available.

what if an image doesn't have any tests, will we push to registry.fp.o right away?

I think that currently we do not have many containers in dist-git, so it could be the job of the SIG to add tests to all of them. Even if this is a simple test that just start the container.

where and how will the CI results be available? I'm assuming we'll use the same mechanism as for rpms

So the Fedora CI pipeline pushes the results in resultsdb, in this solution we do not have a nicer interface for the results. I believe the next release of bodhi will support displaying the results from resultsdb.

I wonder how much code (if any) we need to either add to standard test roles or boilerplate b/w all the dist-git repos; meaning: install container runtime, run it, pull the image
I think it could finally be the time to move github.com/container-image/template repo to pagure so we can prototype this over there

I am not super familiar with the container-image-template, but that might be a good item to bring during on of the meeting.

LGTM, I can't think about any changes/improvements right now
But it popped on my mind how/if we will be addressing CI for multi-container applications, especially where there might not be any meaningful tests for the individual containers. I have mainly openshift on my mind, but I believe there might more use cases (like kube,LAMPs???).

As far as I know, there is nothing stopping you from pulling multiple images in the Python test script using conu. That way you could start a multiple containers an test a full stack application.

The test case might a bit more difficult to write tho.