bootc-dev / bootc-dev/bootc

ci: podman machine vs /var/tmp/tmt

Open
#1,168 3 comments 0 reactions 0 assignees View on GitHub
area/ci
Dominant language
Rust
Stars
2.3k
Forks
230
Avg merge
3d 12h
Merged PRs (30d)
38

Description

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](https://containers.dev/) issue which again last I looked kind of itself clashes with doing container builds)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.