This is aligning with what I did in https://github.com/ostreedev/ostree/pull/3439
- What gets invoked in e.g. GHA should ideally most be `just` commands
that are easy to run locally too (with sudo in GHA, without sudo locally)
- Move the "core build" to the toplevel so that one can just `podman build`
directly too (without the Justfile) and have it do something useful
- The "always build and test in a container" helps for LLM-assisted coding
because what they can do is inherently sandboxed
Signed-off-by: Colin Walters <walters@verbum.org>
Main motivation: I was looking at making more changes here
- Use an idiom I'd like to standardize more of copy context to `FROM scratch` image
which is then mounted and consumed in other phases by mounting. This helps
avoid polluting later containers with intermediate copied files.
- Change `build.sh` to handle being run from any directory
- Drop the `dev-rootfs` stuff as it's weird and awkward; instead we should
encourage multi-step builds deriving from this image
- Don't make `bootc.tar.zst` only to immediately untar it; just use `COPY`
from the build container
- Use heredocs to condense multiple `RUN` invocations to avoid pointless
small layers
Signed-off-by: Colin Walters <walters@verbum.org>
Specifically, I want to hack on both e.g. ostree and bootc
at the same time. With this, I can do (from ostree):
```bash
$ make install DESTDIR=/path/to/bootc/target/dev-rootfs
```
Then from this repo, running a container build will get me both.
Signed-off-by: Colin Walters <walters@verbum.org>
This test will
- build a container image derived from FCOS, injecting bootc-under-test
into it
- Schedule a separate container derived from coreos-assembler
which has a reference to that container injected via
https://docs.ci.openshift.org/docs/architecture/ci-operator/#referring-to-images-in-tests
- Run the stable FCOS base image via kola (qemu), injecting the target oscontainer
- Execute a basic test that just verifies `status --json` today
However, in the future we can change the build system to generate
multiple container images, and test upgrades, rollbacks, etc.
Signed-off-by: Colin Walters <walters@verbum.org>
