The networking to the cluster seems slightly flakey, so I noticed
a few failures when playing with it. A little retry is able to fix it.
The function was taken from deploy.sh. I considered de-duping it,
but deploy.sh runs in a context where
/usr/libexec/tests/osbuild-composer/shared_lib.sh is not yet
established, so it's unfortunately no so simple. :(
The old one is going to be decommissioned. I only changed:
- extracted the storage class to a variable
- adjusted the openshift yaml file to what I was given in the UI
- most importantly, we now use an instancetype to specify the
resource requirements instead of doing it manually
- the network is called default, instead of nic0 on this cluster
- we are downloading the oc and virtctl clients from the new cluster
so the versions match
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>
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
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>
Enable testing of GCE image type on el10 / c10s. The el10 / c10s image
type temporarily uses cloud-init, because there are no GCP guest tools
for el10 / c10s yet and el9 version can't be installed. This implies
that we need to set the SSH key in the instance metadata and use SSH
directly.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
The reason is that the key that we use to test the customization uses
SHA-1 in its signature. And this algorithm is no longer allowed by
default on el10 / c10s.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Add support for RHSM customizations, which currently allow various
aspects of RHSM. Specifically enabling / disabling DNF plugins shipped
by subscription-manager package and setting a subset of options in the
rhsm.conf.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Add support for RPM customizations, which currently allow to import RPM
GPG key from a file installed in the image. This is e.g. done for the
Azure RHUI image type.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Do not schedule gcp.sh on rhel-10 and centos-stream-10. Also improve
loggin for aws.sh and azure.sh as the cloud-image-val testing is
currently not preformed there.
both are defined in CI, but the GOVC_ prefix doesn't match anything
else. Additionally this value is slightly different for vCenter8 and may
lead to failures if not unified.
The cleanup() function cats the httpd log and error file, but did not
use sudo, which failed on permissions. Fix that.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
The test case mistakenly takes into consideration also upstream repo
definitions with the 'no-aux-key' suffix, which are however never
installed by RPMs with this name.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
