In preparation for vendoring composefs-rs from git.
Basically before, things work fine when we're just vendoring
from crates.io, but fall over when we add a git dependency.
The Fedora `cargo_prep` macro writes a hardcoded `.cargo/config.toml`
which only has a replacement for `crates.io`, but we need
the generated replacement for git too which is output by
`cargo vendor-filterer` - which previously we were
discarding.
This was surprisingly difficult!
- Capture the output of `vendor-filterer`
- Work around a bug where it puts a broken `directory` path in
the generated TOML
- Insert that as a new `vendor-config.toml` in our source
- Do use `cargo_prep` to init the RPM config in the spec,
but re-inject our vendor config appended to that one.
Signed-off-by: Colin Walters <walters@verbum.org>
e.g. `TMT_TEST=test-21-logically-bound-switch make test-tmt`
will run all the tmt setup code then run test-21-logically-bound-switch.
This is useful when developing a test.
Signed-off-by: Chris Kyrouac <ckyrouac@redhat.com>
Along with the test, this will install the LBIs on the machine running
the tests prior to running the tests. Also refactors the existing LBI
test into a separate test plan to make room for the install tests.
Signed-off-by: Chris Kyrouac <ckyrouac@redhat.com>
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>
This is required for the bootc install tests that use a custom image.
Otherwise, the cached image will be used instead of the image built from
the bootc provision plugin.
Signed-off-by: Chris Kyrouac <ckyrouac@redhat.com>
1 -> enabled. This adds -vvvvv to the tmt run invocation when using
`make test-tmt` to stream detailed test run output.
Signed-off-by: Chris Kyrouac <ckyrouac@redhat.com>
There's...a variety of warts in the current API schema.
In particular I really dislike `.image.image.image`.
But...but...changing it now would in practice be somewhat
difficult, and it's hard to say that just *that* tweak
would be really useful.
Let's just stabilize the existing spec as `v1` and commit
to maintaining it.
We've already added notes to ask callers to use `--format-version 1`
to specify what they want so we can compatibly add new things
in the future.
Speaking of, this also makes `--format-version=1` be the
same thing as `--format-version=0` so that all the versions
are just "1".
Closes: https://github.com/containers/bootc/issues/518
Signed-off-by: Colin Walters <walters@verbum.org>
Because tmt right now doesn't support isolation automatically,
and many of the tests we'll want to write mutate the system,
we'll need to copy-paste the base plan.
This changes the `make test-tmt` to have its own little
tmt wrapper that dynamically scans the plans/ and sorts
them by a priority, then runs them one by one currently.
Closes: https://github.com/containers/bootc/issues/735
Signed-off-by: Colin Walters <walters@verbum.org>
It's annoying to have to go dig through the logs when something
fails. We do have the tmt logs in CI, but again, more clicks.
Signed-off-by: Colin Walters <walters@verbum.org>
- Add a hidden command to generate JSON schema
- Wire it up to the new `make update-generated`
- Describe how to use it in the docs
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>
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>
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>
New stable gives warning:
`default_features` is deprecated in favor of `default-features` and will not work in the 2024 edition
Signed-off-by: John Eckersberg <jeckersb@redhat.com>
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>
- 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>
The release process has drifted with xtask; I forget exactly
why but I ended up with `.zstd`, not `.zst` in the tarballs
and I've been hand-hacking that manually.
Fix things up so that `cargo xtask package` generates the source
snapshot and the vendor tarball named exactly how we release
them now.
Signed-off-by: Colin Walters <walters@verbum.org>
I forgot that this direction of things is used when
we're making a default tarball, and we didn't
currently depend on pandoc there. Let's use this
`mandown` crate instead which definitely does the
trick.
Signed-off-by: Colin Walters <walters@verbum.org>
This will help motivate us to improve our man pages, by making
them much more visible as pre-generated markdown that can
be conveniently viewed from e.g. the Github web UI.
For now, anytime we change the CLI we'll need to manually
run `cargo xtask man2markdown`, and commit and push the result.
This requires `pandoc` in the environment.
If this becomes burdensome I will likely investigate doing
e.g. a Github action which either automates doing it post-commit,
or enforces that it's done as part of the commit which introduces
the change. However the problem with the latter will be the
`pandoc` requirement.
It may make sense to investigate e.g.
[clap-markdown](https://docs.rs/clap-markdown/latest/clap_markdown/)
in the future instead.
Signed-off-by: Colin Walters <walters@verbum.org>
- 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>
No idea how it worked before; we don't want to include the diff
output which can lead to us failing to parse an integer:
```
error: Packaging
Caused by:
0: Finding git timestamp
1: invalid digit found in string
```
Signed-off-by: Colin Walters <walters@verbum.org>
I was hitting an issue with our COPR builds where we were getting
*earlier* builds because the git hash was the first component
of the version, and the leading numbers there don't increment,
and RPM wants higher versions.
Force newer-is-better by injecting the date (up to the minute, not
second because we're not going to build more than one a second).
Signed-off-by: Colin Walters <walters@verbum.org>
