test: move bib tests #398
Closed
test: move bib tests #398
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add a new running() method to the base class so that each subclass can define their own condition for determining if the VM is running. This and the IP address were the only things that differed in the two run() implementations.
write_aws_creds(): writes the AWS credentials defined in the environment to a file in the format required by the AWS SDK. deregister_ami(): deregister an image from EC2 given its ID.
When building AMIs, include upload options and credentials: - the `--aws-...` options are added as upload_args to the build command. - credentials are read from the environment, written to a temporary file, and mounted into the container. The environment variables will be set through the CI config.
Add the image type name and a metadata dict to the ImageBuildResult. We will use the image type to decide what we can do with the build result (like where and how to boot it). The metadata can be used to communicate information to downstream tests. Here we use it to include the AMI ID in the result. We could have let the tests that use the ImageBuildResult parse the log for the AMI ID, but it's probably better if we only have to do it once and also, parsing it in the image_type_fixture() lets us register the finalizer that will deregister the AMI from EC2. Parsing the log for the AMI ID is a bit dirty and is certainly not the most robust way to get it. We could later print it in a more machine-readable format.
A variant of the test_image_boots() test that only runs for the AMI image type. The function uses the AWS VM class to boot an AMI (given the AMI ID), run a couple of commands over SSH, then tears it down. As opposed to the local boot test, this one also runs on macOS.
Add a new pytest flag, --force-aws-upload, which controls how the AWS build (and boot) test should behave when the AWS credentials aren't set: - if set, the image build will raise a RuntimeError, making any tests that depend on the fixture fail. - if not set, the upload flags will not be set and the AWS boot test is skipped.
Add the AWS secrets to the testing farm action and enable `force-aws-upload` on the pytest call in the testing farm plan. Run these only in testing farm which runs on pull_request_target and can access GitHub secrets.
Now that we have a `bootc-image-builder build` verb we can have a `manifest` one as well that just generates the manifest but does not do the full building. This is mostly useful for testing so it's not exposed by default in the entrypoint (for now).
Support for `match` in python is only available in version 3.10. However centos/rhel 8 and 9 have lower versions so this will need to be moved to `if/elif/else` for now.
Because of the issues with the latest CentOS/centos-bootc#184 and osbuild/bootc-image-builder#149 with the latest quay.io/centos-bootc/fedora-bootc:eln this commit moves to the last known good container id.
Our test images can easily be 10GB and if /tmp is mounted via a tmpfs that can be too much for low memory systems. Hence switch to /var/tmp by default. Note that we do not really need 10GB as it's a sparse files but if /tmp is too small we still get ENOSPC.
Add a new integration test that checks that the container installer is working. The contaner installer just does an unattended install of a disk. The test will run qemu with the installer.iso and an empty disk. Once a reboot from the ISO is detected (via QMP) qemu exists and boots the test disk and checks that it boots and the test user can login.
When running tests locally it can be useful to have a full qemu gui. E.g. the install test is not putting anything on the serial port AFAICT. So the new environment `OSBUILD_TEST_QEMU_GUI=1` will bring up a graphical qemu during the tests. Use as e.g. ``` $ sudo OSBUILD_TEST_QEMU_GUI=1 pytest -s -vv -rs './test/test_build.py::test_iso_installs[iso]' ```
This unbreak macos tests and also fedora-bootc:eln got fixed/reverted upstream.
We have a bunch of false positive test failures like: ``` Check failure on line 4 in bib/cmd/bootc-image-builder/partition_tables.go GitHub Actions / ⌨ Lint "github.com/osbuild/images/pkg/arch" imported and not used (typecheck) ``` This commit tries to fix it by moving to a newer version of golangci-lint.
Test both `quay.io/centos-bootc/{centos,fedora}-bootc:{eln,stream9}`,
now that `bib` supports both fedora and centos bootc we need to start
testing both as part of the integration suite.
Note that not all combinations are tested to save time, it's a
tradeoff and trivial enough to tweak.
We are running out of disk space on the GH runners so we need to be more aggressive about cleanups.
Bumps [golangci/golangci-lint-action](https://github.com/golangci/golangci-lint-action) from 3 to 4. - [Release notes](https://github.com/golangci/golangci-lint-action/releases) - [Commits](golangci/golangci-lint-action@v3...v4) --- updated-dependencies: - dependency-name: golangci/golangci-lint-action dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
I would like to potentially introduce a generic "live iso" that generates *exactly the input container* just as a Live ISO, very similar to how Fedora CoreOS (and one of its parents, the original Container Linux) do it. This has several use cases, such as always running from a PXE boot. I also think this is the long term architecture for an ISO, as opposed to the current Anaconda. This "direct" Live ISO is also the same as how e.g. Fedora Workstation does it, where the installer is just an app in the system. For compatibility we continue to honor the `iso` as an alias.
This commit disabled the anaconda-install test that fails currently because of osbuild/bootc-image-builder#233
Add a new `--progress` option that defaults to `text` and show upload progress when uploading an AMI.
When I open the log for test run in GitHub actions, I want to see just the test run, not pip install deps. Let's split these two things to make the log more readable.
Add a new fixtures, images, that reuses the code from the image_type fixture. Both the images and image_type fixture now call a new function, build_images, that handles either building new images or returning cached builds. When one or more disk images are requested, the build_images() function uses the new multi-build feature to build all disk image types and returns the artifacts that were requested. A new test, test_multi_build_request(), ensures that the returned image artifacts exist and match the expected file names. ISO tests are unaffected by these changes since they can only built separately.
6e965d2413f7bdc8844bf09c9c9968c6c170d96d changed bib to always go through a container storage. However, if the container runtime running bib was using overlayfs (the default), we ended up in a situation that /var/lib/containers/storage was overlayfs. When bib itself tried to worked with these containers, it called podman/skopeo that tried to create overlayfs inside overlayfs, which is a forbidden combination. This worked by accident with centos-boocs/fedora and centos containers, because they contain fuse-overlayfs, and podman/skopeo apparently silently switched to using fuse. This isn't only slow, but it also didn't work with container images without fuse-overlayfs. One example of such an image is the iot-bootable-container. E.g. registry.gitlab.com/redhat/services/products/image-builder/ci/images/iot-bootable-container:fedora-39-x86_64-49d623cc26287730f87d4c9eebadefd2b180dea8a41b00efe7f3b1c636f221d7 Let's fix this by making /var/lib/containers/storage a proper volume, which means that this directory will be bind-mounted to a real filesystem by the container engine, instead of being on an overlay. I tested this by successfully building a disk image from the iot-bootable-container container image above.
Signed-off-by: John Eckersberg <jeckersb@redhat.com>
Avoid CI problems with rate-limits and might also speed up the tests
I'm getting the following error, so this is no longer needed: The same or higher version of rpm-ostree is already installed, cannot update it.
This commit checks early if cross architecture building support via `qemu-user-static` (or similar tooling) is missing and errors in a more user friendly way. Note that there is no integration test right now because testing this for real requires mutating the very global state of `echo 0 > /proc/sys/fs/binfmt_misc/qemu-aarch64` which would make the test non-parallelizable and even risks failing other cross-arch tests running on the same host (because binfmt-misc is not namespaced (yet)).
Fedora 40 is out, let's switch to it. Note that we are still fast- tracking osbuild from the "unpinned" COPR, but let's figure that out in a follow-up. Baby steps!
For easier tracing of what revision was used by who this commit adds the git revision to the main `bootc-image-builder` binary. To do this we need to include the git tree in the build container, go will do the rest and pick up the build info from the git tree, see https://shibumi.dev/posts/go-18-feature/
When `tmt` runs it will not include the `.git` dir when it prepares the source. This was breaking the tmt tests. This commit just makes the containerfile copy the entire current working dir so that we get `.git` if it's there or it is skipped otherwise. Closes: osbuild/bootc-image-builder#583
Prior this commit, the bootc-image-builder container image had
a custom entrypoint that hardcoded the use of the build subcommand. This
meant that if a user wanted to use a different subcommand, they had to
overwrite the entrypoint.
This commit changes the cobra code in bib to fallback to build if no
subcommand was given. This is slighly ugly, but it allows us to remove
the custom entrypoint, streamlining the use of subcommands. Let's see
an example of calling the version subcommand:
Before:
podman run --rm -it --entrypoint=/usr/bin/bootc-image-builder \
quay.io/centos-bootc/bootc-image-builder:latest version
After:
sudo podman run --rm -it \
quay.io/centos-bootc/bootc-image-builder:latest version
Kudos to https://github.com/IKukhta for his code from
spf13/cobra#823 (comment)
Fedora N-1 (40 now) is stable, but will eventually get stale. In my case we happen to be using this image as a "builder" image and I added a new feature to rpm-ostree, which I didn't ship to F40. I may still do so. However it's clearly a good idea for us to keep updated. This all said, it's actually not clear to me that Fedora is the right default base image - it may make sense to target e.g. c10s or c9s? This all relates to https://gitlab.com/fedora/bootc/tracker/-/issues/2 as well. Signed-off-by: Colin Walters <walters@verbum.org>
Let's base our upstream container on Fedora 42 now that it is GA. Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
Trivial drive-by to update LABEL io.openshift.tags="base fedora40" -> 42
This commit checks early if cross architecture building support via `qemu-user-static` (or similar tooling) is missing and errors in a more user friendly way. Note that there is no integration test right now because testing this for real requires mutating the very global state of `echo 0 > /proc/sys/fs/binfmt_misc/qemu-aarch64` which would make the test non-parallelizable and even risks failing other cross-arch tests running on the same host (because binfmt-misc is not namespaced (yet)).
Adjust the bib containerfile to the environment it lives in in ibcli. This is not ideal as we now have drift between ibcli/bib version of the Containerfile. As much of this should be merged back into bib so that ideally we would just copy the files and even have a test that errors if there is drift.
mvo5
force-pushed
the
move-bib-tests
branch
3 times, most recently
from
f6bb9b1 to
40c41ce
Compare
This means dropping shellcheck, golang-ci and unit tests which are already run by other workflows (or not needed like shellcheck).
Collaborator
Author
|
This (and the coresponding test in osbuild/bootc-image-builder#1157) fails with: so there is something off here that needs further investigation. What is interesting is that the other iso tests work: so it might be related to anaconda in centos-10 ? [edit: the upstream/main version of bootc-image-builder is failing in the same way so this is independent of the current changes and most likely an upstream issue with anaconda and how it deploys the container or an issue with how we construct the bootc-installer container] |
mvo5
added a commit
to mvo5/image-builder-cli
that referenced
this pull request
Dec 15, 2025
Move the integration tests from bootc-image-builder into image-builder. With bootc-image-builder being merged into image-builder we still want to run the integration tests for bib because our goal is 100% compatibility. Note that this does not preserve history. There is a PR [0] that does that and while I'm a big fan in general I am not sure its worth the trouble because GH will not allow us to merge the repos and we need to manually force push it. The history of the tests is still fully available in the bootc-image-builder repo in cases it is needed. [0] osbuild#398
mvo5
added a commit
to mvo5/image-builder-cli
that referenced
this pull request
Dec 15, 2025
Move the integration tests from bootc-image-builder into image-builder. With bootc-image-builder being merged into image-builder we still want to run the integration tests for bib because our goal is 100% compatibility. Note that this does not preserve history. There is a PR [0] that does that and while I'm a big fan in general I am not sure its worth the trouble because GH will not allow us to merge the repos and we need to manually force push it. The history of the tests is still fully available in the bootc-image-builder repo in cases it is needed. [0] osbuild#398
Collaborator
Author
|
Closing in favor of #407 (but happen to reopen if people prefer the history). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[draft as this will need some work to get the github workflow right]