This uses the token generated in the GitHub app that has a limited
scope. Also refactors the commit/push steps to use the
create-pull-request action rather than manually committing and pushing.
This simplifies the token usage when committing/pushing.
Signed-off-by: ckyrouac <ckyrouac@redhat.com>
This modifies the scheduled release to happen every 3 weeks regardless
of when the previous release happened. This aligns with the team's
schedule.
Assisted-by: Claude code
Signed-off-by: ckyrouac <ckyrouac@redhat.com>
Update the autovendor GitHub workflow to use the correct path 'crates/cli'
instead of 'cli', which was causing the job to fail with "No such file or
directory" error.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: John Eckersberg <jeckersb@redhat.com>
Since there is some user intervention required for the scheduled
release, this adds a 2 day buffer in case the buttons weren't clicked
immediately last time.
Signed-off-by: ckyrouac <ckyrouac@redhat.com>
This adds two github actions, "Create Release PR" and "release". The
first is scheduled to run every 3 weeks to automatically create a
release PR that bumps the versions. The "release" action is triggered
when the release PR is merged. It will create a draft release with the
tars attached.
Assited-by: Claude Code
Signed-off-by: ckyrouac <ckyrouac@redhat.com>
And add a single test which verifies that our internal `reboot`
code actually does what it should (via systemd-run etc.)
This took me way, way too long to do...there were so many missteps
and confusion. First of all, I kept trying to use `systemd.extra-unit`
from https://www.freedesktop.org/software/systemd/man/latest/systemd-debug-generator.html#
but that doesn't exist in stream9.
I spent way too long trying to debug the fact that switching from
`podman run <image> /sbin/init` to `podman run <image> /bin/sh -c '<stuff> && exec /sbin/init`
fails because in the latter case podman's auto-detection fails and
we need to explicitly say `--systemd=always`. In retrospect obvious...but oh well.
On the positive side, I think with some cleanup we could extend this model
and generalize it for "test running in a container with systemd" (with
a lot of cleanup really)
Signed-off-by: Colin Walters <walters@verbum.org>
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>
Automatically mark any PR touching files in the system-reinstall-bootc
directory with the area/system-reinstall-bootc label.
Signed-off-by: Omer Tuchfeld <omer@tuchfeld.dev>
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>
It appears the single glob '*' doesn't match recursively, so use the
globstar '**' where we want to match anything within a subtree
Signed-off-by: John Eckersberg <jeckersb@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>
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>
