Move all content from the derived test image (hack/Containerfile) into
the main Dockerfile base image. This includes nushell, cloud-init, and
the other testing packages from packages.txt.
This simplifies the build by avoiding the need to juggle multiple images
during testing workflows - the base image now contains everything needed.
Assisted-by: OpenCode (Claude Sonnet 4)
Signed-off-by: Colin Walters <walters@verbum.org>
# Conflicts:
# hack/Containerfile
Pass SOURCE_DATE_EPOCH from git commit timestamp through to rpmbuild,
enabling bit-for-bit reproducible RPM builds. This is useful for
verification and caching.
Then fix the idempotency of the default `just build` to ensure
we're not incorrectly invalidating caches.
Add `just check-buildsys` command that builds packages twice and
verifies checksums match, confirming reproducibility. The CI package
job now uses this to catch regressions.
Assisted-by: OpenCode (Opus 4.5)
Signed-off-by: Colin Walters <walters@verbum.org>
This splits the RPM package building into a separate CI job that runs
before the integration tests. The built packages are then downloaded
and used by the integration test jobs, avoiding redundant builds.
Assisted-by: Claude Code (Sonnet 4.5)
Signed-off-by: Colin Walters <walters@verbum.org>
We were bit before by just doing a `COPY` of our binaries overtop of
the base image because that doens't remove old files.
Replace the pre-build approach with rpmbuild, and then change to
do an rpm-based upgrade so that we fix that problem.
Note that we still preserve incremental rebuilds by overriding
some of the RPM build process.
Assisted-by: Claude Code (Sonnet 4.5)
Signed-off-by: Colin Walters <walters@verbum.org>
First change `.dockerignore` to be an allowlist.
This avoids spurious rebuilds when touching e.g. `tmt/`, and
also crucially we don't leak `.git/` into the sources which
can easily change as one makes commits/branches.
This also requires touching the `hack/` directory which
is now fully self contained.
While we're here, make clear the roles of Justfile vs Makefile.
Remove the `make test`.
Signed-off-by: Colin Walters <walters@verbum.org>
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>
Main motivation: I was looking at making more changes here
- Use an idiom I'd like to standardize more of copy context to `FROM scratch` image
which is then mounted and consumed in other phases by mounting. This helps
avoid polluting later containers with intermediate copied files.
- Change `build.sh` to handle being run from any directory
- Drop the `dev-rootfs` stuff as it's weird and awkward; instead we should
encourage multi-step builds deriving from this image
- Don't make `bootc.tar.zst` only to immediately untar it; just use `COPY`
from the build container
- Use heredocs to condense multiple `RUN` invocations to avoid pointless
small layers
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>
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>
