Now that we're doing a "from scratch" build we don't
have the mtime issue, and so we can change our build system
to do everything in a single step.
Assisted-by: OpenCode (Opus 4.5)
Signed-off-by: Colin Walters <walters@verbum.org>
install-to-filesystem-var-mount test requires packages which should
be built into image for Packit provision (system-reinstall-bootc on
package mode testing farm runner)
Signed-off-by: Xiaofeng Wang <henrywangxf@me.com>
The `cp -a lbi/usr/. /usr` command was preserving local directory
permissions which in one case for me have a restrictive mode 0750
which breaks booting.
Switch to `install -D -m 0644` which explicitly sets file modes and
creates parent directories with correct 755 permissions, while also
simplifying the directory structure.
Assisted-by: OpenCode (Opus 4.5)
Signed-off-by: Colin Walters <walters@verbum.org>
The previous commit consolidated test content (nushell, cloud-init, etc.)
into the base image. This completes that work by removing the separate
`build-integration-test-image` target and updating all references.
Now `just build` produces the complete test-ready image directly,
simplifying the build pipeline and eliminating the intermediate
`localhost/bootc-integration` image.
Also adds SKIP_CONFIGS support for the coreos testing workflow, which
skips LBIs, test kargs, and install configs that would conflict with FCOS.
Signed-off-by: Colin Walters <walters@verbum.org>
Move all content from the derived test image (hack/Containerfile) into
the main Dockerfile base image. This includes nushell, cloud-init, and
the other testing packages from packages.txt.
This simplifies the build by avoiding the need to juggle multiple images
during testing workflows - the base image now contains everything needed.
Assisted-by: OpenCode (Claude Sonnet 4)
Signed-off-by: Colin Walters <walters@verbum.org>
# Conflicts:
# hack/Containerfile
Add a new `bootc container compute-composefs-digest` command that computes
the bootable composefs digest directly from a filesystem directory path,
defaulting to `/target`. This enables computing digests in container
environments without requiring access to container storage or a booted
host system.
The existing container-storage-based behavior is preserved and renamed
to `compute-composefs-digest-from-storage` (hidden). The `hack/compute-composefs-digest`
script is updated to use the renamed command.
The core digest computation logic is extracted into a new
`bootc_composefs::digest` module with:
- `new_temp_composefs_repo()` helper for DRY temp repository creation
- `compute_composefs_digest()` function with "/" path rejection
Unit tests and an integration test verify the command works correctly,
producing valid SHA-512 hex digests with consistent results across
multiple invocations. Exact digest values are not asserted due to
environmental variations (SELinux labels, timestamps, etc.).
Closes: https://github.com/bootc-dev/bootc/issues/1862
Assisted-by: OpenCode (Claude Opus 4.5)
Signed-off-by: John Eckersberg <jeckersb@redhat.com>
Previously, `BootedStorage::new()` unconditionally tried to open
`/sysroot` before checking the environment type. This caused
`bootc status` to fail on non-ostree/composefs systems.
(We did work in containers and we had tests for that; but
the container case is special cased even earlier)
Fixes: https://issues.redhat.com/browse/RHEL-135687
Assisted-by: Claude Code (Opus 4.5)
Signed-off-by: Colin Walters <walters@verbum.org>
Main goal is to reduce signing logic duplication between the systemd-boot
and UKI generation.
However, this quickly snowballed into wanting to actually verify
by providing a custom secure boot keys to bcvk that things worked.
This depends on https://github.com/bootc-dev/bcvk/pull/170
Now as part of that, I ran into what I think are bugs in pesign;
this cuts things back over to using sbsign. I'll file a tracker for that
separately.
Finally as part of this, just remove the TMT example that builds
a sealed image but doesn't actually verify it works - it's already
drifted from what we do outside here. Ultimately what we need
is to shift some of this into the Fedora examples and we just
fetch it here anyways.
Assisted-by: Claude Code (Sonnet 4.5)
Signed-off-by: Colin Walters <walters@verbum.org>
I thought about this with the cloud-init disablement for now
with bcvk. It already works to just not enable `cloud-init.target`
which we were already doing.
Signed-off-by: Colin Walters <walters@verbum.org>
Part 1: Use bcvk
For local tests, right now testcloud+tmt doesn't support UEFI, see
https://github.com/teemtee/tmt/issues/4203
This is a blocker for us doing more testing with UKIs.
In this patch we switch to provisioning VMs with bcvk, which
fixes this - but beyond that a really compelling thing about
this is that bcvk is *also* designed to be ergonomic and efficient
beyond just being a test runner, with things like virtiofs
mounting of host container storage, etc.
In other words, bcvk is the preferred way to run local virt
with bootc, and this makes our TMT tests use it.
Now a major downside of this though is we're effectively
implementing a new "provisioner" for tmt (bypassing the
existing `virtual`). In the more medium term I think we
want to add `bcvk` as a provisioner option to tmt.
Anyways for now, this works by discovers test plans via `tmt plan ls`,
spawning a separate VM per test, and then using uses tmt's connect
provisioner to run tests targeting these externally provisioned
systems.
Part 2: Rework the Justfile and Dockerfile
This adds `base` and `variant` arguments which are propagated through
the system, and we have a new `variant` for sealed composefs.
The readonly tests now pass with composefs.
Drop the continuous repo tests...as while we could keep
that it's actually a whole *other* entry in this matrix.
Assisted-by: Claude Code (Sonnet 4.5)
Signed-off-by: Colin Walters <walters@verbum.org>
First change `.dockerignore` to be an allowlist.
This avoids spurious rebuilds when touching e.g. `tmt/`, and
also crucially we don't leak `.git/` into the sources which
can easily change as one makes commits/branches.
This also requires touching the `hack/` directory which
is now fully self contained.
While we're here, make clear the roles of Justfile vs Makefile.
Remove the `make test`.
Signed-off-by: Colin Walters <walters@verbum.org>
A key thing for me is that the `Justfile` should be a one-stop
shop for development of the project. It can't have everything but
it should answer the basic questions of "how do I build and test
this project".
This aligns the recently added tmt-on-GHA flow a *bit* more closely
with some of that. Biggest is to use the `just build-integration-test-image` as the canonical
way to build a container image with our testing stuff in it;
which uses our main Dockerfile
Other cleanups:
- Change test script to move into tests/tmt/ as a workaround for
https://github.com/teemtee/tmt/pull/3037#issuecomment-3259585271
- Change the qemu logic to use SMBIOS credentials so we don't
have to carry around both a disk image and a SSH key
- Change qemu to use `-snapshot` so we can reuse disks
- Change the scripts to accept data via argv[1] and not environment
- Drop the hardcoded testing directory and use `target/` as
a generic build artifact dir
Signed-off-by: Colin Walters <walters@verbum.org>
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>
This deprecates skip-fetch-check in favor of the inverse,
run-fetch-check. Updates docs and tests to reflect the change.
Signed-off-by: ckyrouac <ckyrouac@redhat.com>
One CI run just got a server error fetching the spec from Fedora.
We have a spec here (which I don't like but we do) so use it
to lower CI flakes.
Signed-off-by: Colin Walters <walters@verbum.org>
Keep the bind mounts in the docs though for now because many
people will be using the current docs with older bootc.
Signed-off-by: Colin Walters <walters@verbum.org>
This was a rather important miss; we need to pick
up the kargs.d files when doing a `bootc install` too.
Signed-off-by: Colin Walters <walters@verbum.org>
I've been trying to keep this project in "one" programming
language by writing even tests in Rust...but specifically
for our integration tests it's pretty painful not just to
compile them but have to deal with baking them into the base image.
The tmt framework is very GHA like in that it scrapes the
git source tree and copies it into the target environment, which
works really well with scripts.
Now, if you know me you know I am not a fan of dynamic programming
languages like bash and Python. I'm one of those folks that actually
tries to use Rust for things that feel like "scripts" i.e. they're
*mostly* about forking external processes (see the xtask/
crate which uses "xshell").
Some of our testing code is in Rust too. However...there's a giant
tension here because:
- Iteration speed is very important for tests and scripts
- The artifact being an architecture-dependent binary pushes us
to inject it into container images; having the binary part
of the bootc image under test conceptually forces us to reprovision
for each test change, which is super expensive
Most other people when faced with the testing challenge would
just write shell scripts (or Python); that's definitely what tmt
expects people to do.
The podman project has a mix of a "bats" suite which is all
bash based, and a Go-based framework.
The thing is: bash is easy to mess up and has very little ability
to do static analysis. Go (and Python) are very verbose for forking external
processes.
I've been using https://www.nushell.sh/ for my interactive shell
for quite a while; I know just enough to get by day to day
(but honestly sometimes I still type "bash" and run a few things there
that I know how to express in bash but not nu)
Anyways though, nushell has a lot of desirable properties for
tests (which are basically scripts):
- Architecture independent
- Running an external process requires zero ceremony; it's the
default!
- But it *is* easy to e.g. scrape JSON from an external binary
into a rich data structure
- A decently rich standard library
The downside is, it's a new language. And in the end, I'm
not going to say it's the only way to write tests...maybe we
do end up with some more bash. It wouldn't be the end of the world.
But...after playing with this, I definitely like the result.
OK, and after some debate we decided to add Python too, so this
demos a pytest test.
Signed-off-by: Colin Walters <walters@verbum.org>
I think this got broken in a refactoring; add
test coverage. In general all the heavy
lifting should move out of `baseline.rs`; a
good way to do that is probably to take the
next step of making it its own crate that
doesn't depend on the bootc core logic perhaps.
Closes: https://github.com/containers/bootc/issues/570
Signed-off-by: Colin Walters <walters@verbum.org>
This must be a regression from the timestamp change:
91ed63caf1
Without this we fail to parse the timestamp and get errors;
maybe something else changed.
Of course, we should use a non-Makefile language for
this so we get proper error checking. I may move some
of the makefile bits into xtask.rs or so.
Signed-off-by: Colin Walters <walters@verbum.org>
This is useful for remote debugging bootc running in a VM.
Until podman-bootc has support for forwarding arbitrary ports,
this custom solution is needed.
Signed-off-by: Chris Kyrouac <ckyrouac@redhat.com>
These are things that https://tmt.readthedocs.io/en/stable/
wants, and the goal is to support running under tmt more
directly.
Part of https://github.com/containers/bootc/issues/543
With this I can run:
```
provision:
how: virtual
image: /home/walters/src/github/containers/bootc/target/testbootc-cloud.qcow2
summary: Basic smoke test
execute:
how: tmt
script: bootc status
```
Signed-off-by: Colin Walters <walters@verbum.org>
