ci: podman machine vs /var/tmp/tmt

[cgwalters]

With the latest cargo xtask test-tmt which mostly just calls out to the new tmt bootc glue, what I get by default is

Cause number 1:

    provision step failed

    The exception was caused by 1 earlier exceptions

    Cause number 1:

        Command 'podman run --rm --privileged -v /var/lib/containers/storage:/var/lib/containers/storage --security-opt label=type:unconfined_t -v /var/tmp/tmt/run-004/plans/test-01-readonly/provision/default-0:/output quay.io/centos-bootc/bootc-image-builder:latest build --type qcow2 --rootfs xfs --local localhost/tmtmodified-1741212057' returned 125.

        # stderr (1/1 lines)
        # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        Error: statfs /var/tmp/tmt/run-004/plans/test-01-readonly/provision/default-0: no such file or directory
        # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

After being confused for a bit what I eventually figured out here is that /var/tmp needs to be part of the podman machine bind mounts when you do podman machine init with e.g. -v /var/tmp:/var/tmp. Except of course if you have an existing machine you need to hand edit ~/.config/containers/podman/machine/qemu/podman-machine-default.json to add that mount, and restart it.

But really we should not require this, it's a logistical annoyance.

The more I think about this, the more strongly of the opinion I am that actually we should always run tmt from a container, not from the "host" (which in my case is a toolbox, but that's mostly irrelevant).

IOW as a bootc developer I should have a flow that's basically

• podman build
• ./ci/script-which-spawns-pods

That latter script should be ideally a low-dependency tool whose job it is just to basically podman run, and we should avoid executing code on the host in the default flow.

---

(Of course, what I hit last time I tried to go this way is it doesn't work quite as well with IDEs and such, or at least raises the devcontainer issue which again last I looked kind of itself clashes with doing container builds)

[cgwalters]

This also relates to #903

[cgwalters]

@ckyrouac did you hit this? I know I used to have this working, but then I reinitialized my podman-machine a while back and lost the change I made, and am actually still failing even with setting up the virtiofs mount

[ckyrouac]

This is working for me with podman machine init ... -v /var/tmp/tmt:/var/tmp/tmt ...

IOW as a bootc developer I should have a flow that's basically

podman build
./ci/script-which-spawns-pods

👍