Is there an easy way to get to the artifact generated by the compose?

If I recall correctly, Image Factory produces a tarball in the so-called docker-archive or docker save format. So, one can download the tarball and do this to make it visible to toolbox and podman:

$ skopeo copy \
    docker-archive:/path/to/tarball \
    containers-storage:registry.fedoraproject.org/fedora-toolbox:40

However, I wonder how much this will be impacted by the KiwiBuiltCloudImages Change for Fedora 40.

This ticket is for updating the wiki test case

Isn't the Wiki test case also used as a hint for toolbox updates to stable Fedoras? If so, we might have to differentiate between Fedoras under development, and those that have been released and considered stable.

So the way we do this programmatically is via the productmd metadata, i.e. the images.json file. I maintain a thing called fedfind which, these days, mostly acts as a kinda convenience wrapper around that data with some fancy extra functions. The openQA scheduler uses that, and other test systems that want to test images can do the same or use images.json directly or whatever. So test systems can certainly find and test images that are listed there. The toolbox images listed there are the "Fedora-Container-Toolbox" images that have format tar.xz and type 'docker', so I guess they're in the format you describe. We can definitely try the way you describe, thanks.

For humans, the validation matrices list all the images in the compose - in the table at the top of https://fedoraproject.org/wiki/Test_Results:Fedora_40_Branched_20240219.n.0_Installation for e.g. you can see a "Container_Toolbox docker" row. (The tool that generates the pages uses fedfind to produce this table). We can tell human testers to refer to that row to find an image to test.

Yes, the test case will have to cover both paths, the 'simple just run toolbox enter' path and the more complex way to test a specific image.

So the way we do this programmatically is via the productmd metadata, i.e. the images.json file. I maintain a thing called fedfind which, these days, mostly acts as a kinda convenience wrapper around that data with some fancy extra functions. The openQA scheduler uses that, and other test systems that want to test images can do the same or use images.json directly or whatever. So test systems can certainly find and test images that are listed there.

Cool.

The toolbox images listed there are the "Fedora-Container-Toolbox" images that have format tar.xz and type 'docker', so I guess they're in the format you describe. We can definitely try the way you describe, thanks.

Yeah, it will work if you download the tarballs and do a skopeo copy to place them in containers-storage with the right fully qualified name.

For humans, the validation matrices list all the images in the compose - in the table at the top of https://fedoraproject.org/wiki/Test_Results:Fedora_40_Branched_20240219.n.0_Installation for e.g. you can see a "Container_Toolbox docker" row. (The tool that generates the pages uses fedfind to produce this table). We can tell human testers to refer to that row to find an image to test.

Yes, the test case will have to cover both paths, the 'simple just run toolbox enter' path and the more complex way to test a specific image.

nod

Thanks for working on this, @adamwill !

No problem. I've updated the wiki test case and I'm working on enhancing the openQA test to do this now. Let me know if you see anything wrong. Thanks for the pointers!

edit: test run of the modified openQA test will run at https://openqa.stg.fedoraproject.org/tests/3597885 soon, cross your fingers...

why is skopeo copy so slow? I gave it five minutes to run in openQA and it timed out! let's try 10...

alright, well, 10 minutes works. https://openqa.stg.fedoraproject.org/tests/3597926#details . gonna merge all that into prod and call it good.

Fantastic!

why is skopeo copy so slow? I gave it five minutes to run
in openQA and it timed out! let's try 10...

Yeah, it can be a bit slow. I never dug into why that is.