This directory will contain expected files in the base image.
That said, I may change the container import path to auto-create
at least the sysroot dir and symlink at some point and these
can just be dropped.
And for that matter after
9a0acd7249
"libostree/deploy: enable composefs by default"
we can likely just drop the prepare-root bit too.
But for now this is needed.
Motivated by improving base image generation from
https://gitlab.com/fedora/bootc/tracker/-/issues/32
Signed-off-by: Colin Walters <walters@verbum.org>
This adds a new systemd path unit which activates on bootc status
changing, and in turn triggers a new systemd target. This allows
adding arbitrary new systemd services with `WantedBy =
bootc-status-updated.target` that will be activated each time the
bootc status is updated.
Signed-off-by: John Eckersberg <jeckersb@redhat.com>
This helps ensure our CI is covering our copy of ostree-ext, not
the one currently vendored in rpm-ostree.
Signed-off-by: Colin Walters <walters@verbum.org>
Add `dead_code = "deny"` to our default lints; we had
a compiler warning for this in main.
Fix the warning by moving the human readable test code into
`#[cfg(test)]`.
While we're here, move the other lib.rs lints into the crate;
enforcing docs for *everything* at first I thought might be heavy
handed but actually is fine as it only applies to things that
are `pub`, of which we don't actually have that much so it
mainly forced me to add some stub docs for the modules, which
is probably a good idea.
Signed-off-by: Colin Walters <walters@verbum.org>
Closes: https://github.com/containers/bootc/issues/721
- Initialize a containers-storage: instance at install time
(that defaults to empty)
- Open it at the same time we open the ostree repo/sysroot
- Change bound images to use this
We are *NOT* yet changing the base bootc image pull to use this.
That's an obvious next step (xref
https://github.com/containers/bootc/pull/215 ) but will come later.
Signed-off-by: Colin Walters <walters@verbum.org>
I plan to add more generated-from-source files, so generalize
the target which is currently specialized to manpages.
Signed-off-by: Colin Walters <walters@verbum.org>
Let's ensure these directories exist by default, because
we want people to drop things there - and having to create
the directory in derived images invites typos.
Signed-off-by: Colin Walters <walters@verbum.org>
The `make validate-rust` reproduces locally the same checks
we run in CI as gating by default; hook it up to the existing
`make validate`.
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>
Part of https://github.com/containers/bootc/issues/543
I'm not totally happy with this, but it does demonstrate the basic
wiring flow of:
- `cargo xtask test-tmt`
That will do a container build, make a disk image from it,
and run a "hello world" tmt test.
A lot more to do here including wiring up our existing tests
into this, and deduplicating with the other integration tests.
A key aspect too will be exploring workflows that e.g. expose
a registry locally.
Signed-off-by: Colin Walters <walters@verbum.org>
This ensures that when we rerun the container build without
changing the source, we get the same thing. Which then
further ensures we don't invalidate any cached disk images,
etc.
Signed-off-by: Colin Walters <walters@verbum.org>
Previous work started moving our tests into an external binary;
this is just cleaner because it can test things how a user
would test. Also, we started using `libtest-mimic` to
have a "real" test scaffolding that e.g. allows selecting
individual tests to run, etc.
Complete the picture here by moving the remaining bits into
the tests-integration binary. We now run the `tests-integration`
binary in two ways in e.g. Github Actions:
- It's compiled directly on the Ubuntu runner, and orchestrates
things itself
- It's built in our default container image (Fedora) but as an external
`/usr/bin/bootc-integration-tests` binary
Also while we're here, drop the kola tests.
Signed-off-by: Colin Walters <walters@verbum.org>
This is a giant and hacky workaround for
https://github.com/ostreedev/ostree/issues/3193
The better real fix is probably in either systemd or anaconda
(more realistically both) but let's paper over things here for now.
Having code to run as a generator will likely be useful in the
future anyways.
Signed-off-by: Colin Walters <walters@verbum.org>
I was being too chicken; there's no reason not to install our
systemd units by default. They're not enabled by default,
but we do want to encourage their use.
Signed-off-by: Colin Walters <walters@verbum.org>
Add a `make validate` target to run cargo-fmt and cargo-clippy.
My muscle memory from other containers/ projects is strong where I am
used to run `make validate` before committing/pushing changes.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
- Inject pre-generated manpages into the source tarball we make
- Ensure we use the git tag for version if there is one
Immediate motivation is making sure man pages end up in e.g.
RPM builds.
Signed-off-by: Colin Walters <walters@verbum.org>
Add support for `/usr/lib/bootc/install/*.toml`
and `/etc/bootc/install/*.toml`
and `/run/bootc/install/*.toml` etc. which define config files
for the install process.
Use this to configure the root filesystem type instead of hardcoding
it. We still default to xfs but it's now trivial for an OS/distribution
to drop-in an override (or just edit the default toml). Additionally
derived builds can do so just as easily.
We then drop the `impl Default for Filesystem` so that the default
isn't hardcoded in the binary anymore.
Signed-off-by: Colin Walters <walters@verbum.org>
Usage example with `/dev/vda` being an extra mounted disk:
```
$ podman run --privileged --pid=host --net=none quay.io/cgwalters/c9s-oscore:latest bootc install /dev/vda
```
Signed-off-by: Colin Walters <walters@verbum.org>
First, this adds `cargo xtask` following
https://github.com/matklad/cargo-xtask/
We use this to write "external glue scripts" in Rust, not bash.
Specifically we now have e.g. `cargo xtask vendor` which just
wraps running `cargo vendor-filterer`.
Then build on that and add `cargo xtask package-srpm` which generates
a `.src.rpm`.
And build on that by adding the requisite glue to have Fedora's COPR
be able to understand it, so that we can get auto-built and shipped
packages there.
This will make trying out bootc a bit easier.
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>
