This introduces a GitHub workflow to periodically run `cargo xtask
update-generated` in order to keep the docs up-to-date with the
latest changes. It will create a PR if changes are detected.
Signed-off-by: Micah Abbott <miabbott@redhat.com>
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>
This enables using a local image with system-reinstall-bootc. A couple
drive by cleanups to the integration tests are included.
Signed-off-by: ckyrouac <ckyrouac@redhat.com>
This adds a few basic integration tests for system-reinstall-bootc, adds
a system-reinstall option to tests-integration to run them, and executes
them as part of the github action.
Signed-off-by: ckyrouac <ckyrouac@redhat.com>
Key off the ostree prepare-root config to require fsverity
on all objects.
As part of this:
- Add a dependency on composefs-rs just for the fsverity querying
APIs, and as prep for further integration.
- Add `bootc internals fsck`, which verifies the expected
fsverity state.
Signed-off-by: Colin Walters <walters@verbum.org>
We should really have a more centrally-maintained `cargo-deny`
configuration. I'd argue to maintain it here in bootc to
start, but this will be a common thing for other projects
in github.com/containers and elsewhere.
Anyways, this needed updating for the new Unicode-3.0 license
in some updated unicode crates that I saw in rpm-ostree.
While we're here, quiet the duplicate crate warning in the CI
job, as it's just noise. Keep it when running locally so
we have some visibility if we care about it.
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>
In relatively recent rust there's a nice way to globally
configure clippy lints for the whole workspace. We can
kill the `custom-lints` target because relatively
recently clippy has a lint for `todo!` and `dbg!` itself.
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>
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>
1. add bootc swtich test
2. add bootc install to-disk test
3. cover more distros, like rhel 9.5, fedora 40 and 41(rawhide)
Signed-off-by: Xiaofeng Wang <henrywangxf@me.com>
- Build from the hack/Containerfile flow but using Fedora
- Run that container instead of bind mounting in our binaries
Signed-off-by: Colin Walters <walters@verbum.org>
A few things going on here:
- Rewrite logic from shell script into Rust (using xshell, so
it's still convenient to fork commands)
- Make the test logic take an externally-built container image
instead of using a `-v bootc:/usr/bin/bootc` bind mount
- Build the container image using our stock hack/Containerfile
in Github Actions instead of building for c9s in GHA
- This all hence starts to make the logic reusable outside
of Github Actions too; the container build is a known standard thing.
Signed-off-by: Colin Walters <walters@verbum.org>
Especially the `-t` forces as pty allocation which causes
bad rendering for things like progress bars in the github actions
flow.
Signed-off-by: Colin Walters <walters@verbum.org>
It was raised in a discussion that it's rather easy to copy-paste
this command you may find in a document and not fully understand
what it does.
Let's prominently warn by default, with a timeout.
Signed-off-by: Colin Walters <walters@verbum.org>
Every time I (or someone else) force pushes to re-add the DCO
we're wasting resources and/or just have added latency.
Signed-off-by: Colin Walters <walters@verbum.org>
This fixes a logical bug where for base images that don't
have any install configuration at all, we errored out even
if we were explicitly passed `--filesystem`.
This is just about making it easier to test base images
that don't have an install config.
Signed-off-by: Colin Walters <walters@verbum.org>
If we want it we'll bring it back, the fact that it was just
empty lines was causing us to have failures in actions.
Signed-off-by: Colin Walters <walters@verbum.org>
I went through the docs and cleaned some things up, fixed
some missing content, etc.
Also a patch to `xtask` to make it so that `cargo xtask manpages`
works even when $PWD is in `docs`.
Signed-off-by: Colin Walters <walters@verbum.org>
First, in the install code, acquire a proper policy object.
Add helpers for writing files/directories that take a policy
object and operate *solely* using fd-relative operations and
don't fork off helper processes.
This is a notable cleanup because we don't need to juggle
absolute file paths *and* fds, which avoids a lot of confusion.
Our usage of a wrapper for the cap-std-ext atomic write API
for generating files ensures that if the file is present,
it will always have the correct label without any race conditions.
Change the one place we now call `chcon` as a helper process
to be an explicit recursive selinux relabeling. In the
future we should switch to using a direct API instead of
forking off `/usr/bin/chcon` - then everything would be fd-relative.
Signed-off-by: Colin Walters <walters@verbum.org>
Github has job status update. Same job will have two status if
testing farm updates PR status. That does not make sense.
Github job status update can't be disabled, so testing farm
PR job status update has to be disabled.
Signed-off-by: Xiaofeng Wang <henrywangxf@me.com>
- I don't want my life to involve ruby, and in particular `mdbook serve`
Just Works out of the box with a single binary
- Reorganize the sections
- Some content cleanup and fixes
- Integrate the man pages into the docs (hooray!)
Signed-off-by: Colin Walters <walters@verbum.org>
There's some instability in eln right now, but more importantly
I think our baseline target should be c9s because that acts
as the real lower bound for what we want to support.
Signed-off-by: Colin Walters <walters@verbum.org>
