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>
Add an entrypoint that basically everyone can start
adding to their builds which performs some basic
static analysis for known problems.
Closes : #216
Co-authored-by: Joseph Marrero <jmarrero@redhat.com>
Co-authored-by: Huijing Hei <hhei@redhat.com>
Co-authored-by: Yasmin de Souza <ydesouza@redhat.com>
Signed-off-by: Steven Presti <spresti@redhat.com>
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>
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>
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>
