[WIP] test: Add integration test running on github runner

[henrywang]

New integration test workflow:

• Run integration test in Github runner or run locally with TEST_OS=fedora-42 make test

• build job:

1. build bootc binary in container and replace the bootc inside the bootc image
2. bootc install to-disk to generate disk image
3. archive disk file (skip this step if run locally), one image can be used by the test jobs in parallel

• test job:

1. download disk image from archive
2. boot disk image with qemu-system
3. run tmt test against this VM

[gemini-code-assist]

Code Review

This pull request introduces a new integration test running on GitHub runners, which is a great addition. The implementation involves new scripts for building a test image and running it in QEMU. My review focuses on improving the robustness and security of these new test scripts. I've identified a few critical issues that would prevent the tests from running as intended, such as an undefined command and incorrect error handling in the presence of set -e. I've also pointed out security concerns regarding disabled TLS verification and opportunities to make the scripts more robust and maintainable. Please see the detailed comments for suggestions.

[gemini-code-assist]

The temporary directory path /tmp/tmp-bootc-build is hardcoded here and in build.sh. This creates a tight, implicit coupling between the two scripts. It would be more robust to define this path in one place (e.g., in the Makefile), export it as an environment variable, and have both scripts use it. This would also make it easier to manage the lifecycle of the temporary directory (creation and cleanup).

[cgwalters]

Yes, I think we could just require this script to be invoked in the context of the temporary directory.

That said also, the only thing that actually binds the two things together right now is the ssh key.

But we can avoid that by not using --root-ssh-authorized-keys at bootc install to-disk time but instead injecting the SSH key via systemd credentials - that's how podman-bootc does it.

(Of course this whole topic instantly gets into the whole https://gitlab.com/fedora/bootc/tracker/-/issues/2 and whether/how podman-bootc and other virt provisioning tools should be shared underneath different testing frameworks)

Anyways for now though let's just change the GHA to allocate a temporary directory, see below

[henrywang]

@cgwalters , The two failures still need investigate. It's tmt issue, not our code issue.
Do you have any comment on this PR? Thanks.

[cgwalters]

Unrelated to this PR specifically but we should probably factor this stuff out into a shared action helper

[cgwalters]

Let's make this be quay.io/fedora/fedora:42 e.g. - see below

[henrywang]

This test_os will be [fedora-41, fedora-42, fedora-43, centos-9, centos-10].

[cgwalters]

Yes, I think we could just require this script to be invoked in the context of the temporary directory.

That said also, the only thing that actually binds the two things together right now is the ssh key.

But we can avoid that by not using --root-ssh-authorized-keys at bootc install to-disk time but instead injecting the SSH key via systemd credentials - that's how podman-bootc does it.

(Of course this whole topic instantly gets into the whole https://gitlab.com/fedora/bootc/tracker/-/issues/2 and whether/how podman-bootc and other virt provisioning tools should be shared underneath different testing frameworks)

Anyways for now though let's just change the GHA to allocate a temporary directory, see below

[cgwalters]

I think this would then become:

tmpd=$(mktemp -d) && cd $tmpd && $srcdir/tests/build.sh && $srcdir/tests/test.sh

or so

[cgwalters]

I'm OK with this as is if you prefer, we can land further cleanups as followups

[cgwalters]

     package: building container image with dependencies

We had a live chat about this and I think the fact that tmt is dynamically rebuilding the OS image on boot is a problem. In the long term ideally the testing framework doesn't require installing any binaries at all on the target (this would let us test minimal systems without python etc) but:

• In the short term how about tmt print-target-dependencies or so and then we can pre-install those in our container image, and then tmt shouldn't require rebuilding inside the target system? i.e. in the Dockerfile we do RUN dnf -y install $(tmt print-target-dependencies)