Re-enable the vmware tests on RHEL 10 and use vcenter 8 instead of 6. This fixes the issues caused by outdated CPUs in old cluster by migrating to a new one with new hosts as well.
This commit tweaks the `cross-build.sh` to checkout the last release
tag of the images library instead of using main. The issue with using
main is that there are many false positive errors when e.g. a new
fedora release is added to main.
Ideally it would use the tag of the vendored images library but
this particular test looks at the rpm content so the information
what version of images was used is not readily available (we could
fix this but the workaround of this commit is hopefully sufficient).
Add more information when the cross-distro.sh test fails. Currently
it prints:
```
DEBUG: ===== ALL_DISTROS ====
rhel-8
...
rhel-8
DEBUG: ===== ALL_EXPECTED_DISTROS ====
fedora-40
...
fedora-42
DEBUG: ===== ALL_REMAINDERS ====
rhel-8
....
rhel-8
DEBUG: ===== END ====
Some distros are missing!
Missing distros:
```
But the most crucial information (i.e. what is installed) is
missing from this debug print (it can be found in a different
output but lets make it easy).
Remove incorrect comment (not an ostree image).
Add a greenprint for depsolving since it can take some time for that to
run and it makes more sense than pausing output on "Preparing
blueprint".
Add separate blueprint creation functions, one for each partitioning
layout:
- disk-plain
- disk-lvm
- disk-btrfs (Fedora only)
The existing 'filesystem' blueprint is also kept.
Each function also sets the $EXPECTED_MOUNTPOINTS variable for the
mountpoint check that happens after the build.
Call the script without a path since it's now in the PATH.
Drop the SELinux labelling workaround (chcon) from filesystem.sh and
image_tests.sh. The packaged tool is already labelled correctly.
Install osbuild-tools instead of osbuild-composer-tests in
regression-old-worker-new-composer.sh to get osbuild-image-info.
It turned out that our new F41 CI images have firewalld installed. Make
sure that the worker-executor port is opened in firewall, otherwise the
worker can't connect to the executor.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Unfortunately, `which` does not seem to be installed by default on our
F41 CI images. Instead of doing the dance with rebuilds, which has been
problematic recently, let's not rely on `which` in scripts any more,
since we can replace it with the Bash built-in `type` command.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
This also adds an actual repository json file for the test-disro.
Without this the repo.ListDistros() function doesn't return any actual
distros.
Related: RHEL-60125
When generating x509 v3 certs we need to explicitely set "CA:TRUE"
otherwise they're not trusted to be used. Also start running the tests
on RHEL-9.5 and RHEL-10.0
This is needed for GPG key import to work on RHEL-9, because the key
uses SHA-1. This results in the following error when importing the key
during the build of the build container:
"Signature not supported. Hash algorithm SHA1 not available."
We do not need the AUX key in our RHEL-8 repo definitions used for
testing.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Adjust the test case to cope with the SPDX SBOM documents uploaded to
the Koji. Also explicitly check that there is the expected number of
SBOM documents uploaded as the image build output.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Previously, the worker was determining the GCE image guest OS Features
on its own, based on the OS name. This caused problems, in case the
osbuild-composer was of a newer version than the worker.
Example:
osbuild-composer contained support for c10s GCE image type and its
implementation also contained the proper guest OS Features list for it.
However, when the worker got the osbuild job, it built it and tried to
fetch the guest OS Features for the distro. Since its implementation was
too old, it didn't contain the code that added the actual support for
c10s GCE images and got no guest OS features list (which is the default
for unsupported distros). The image was successfully uploaded and
shared, but it does not boot in GCP, because it does not know that it
should use UEFI to boot it.
This behavior could be considered a bug. The worker should be dumb. It
should not be making decisions about the image features, but instead it
should take them from the upload target options. And composer should be
the authoritative source of truth for this. Because otherwise, we
basically have two components that need to be updated in sync to add
support for GCE images on a new distro.
Move the GCE image guest OS features to the GCP upload target options.
The worker will just take what is specified there and use it when
importing the image to GCP. As a compatibility layer for the case when
the composer would be older than the worker (unlikely, but still),
worker will try to determine the image guest OS features in case the
list in the upload target options is empty.
Extend the GCP functional tests to check that the imported image has at
least some guest OS features set.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
