Add a small paragraph with the instruction to run the go tests when
pulling in a new version of images as a guide for making sure that
osbuild-composer builds and runs successfully, before moving on to
integration tests.
- Add ppc64le and s390x repo URLs to Fedora repositories.
- Add Fedora 40 (rawhide) repositories.
- Update Fedora testing repositories to latest snapshots, adding new
arches and F40 repos. Basically took what is in osbuild/images repo.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Include the osbuild version used to build the image, in the image extra
metadata attached to the Koji build and image output.
Extend `koji.sh` to verify that the version is set and of the expected
value.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Test the content of manifest outputs extra metadata and that they are
the same as the metadata attached to the build extra metadata.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Expose the osbuild information used to produce the image, in the image
extra metadata under the `osbuild_artifact` property.
This information will get included in the image / build extra metadata
and make it explicit how to reproduce the image build using osbuild and
the attached manifest.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Add any non-Koji upload target results attached to an OSBuild result, to
the image extra metadata. This will make it easy to locate any image
from Koji uploaded to cloud, in the target cloud environment.
The rationale behind including only non-Koji target results is that one
can find it only in Koji, so there is no added value in including the
Koji target results at all.
Extend the `koji.sh` to check the target results in image metadata when
testing Koji scenario with cloud upload.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Import osbuild manifest and build log to the Koji build as outputs. Also
note the respective filenames in the image output extra metadata.
Note that the osbuild manifest is imported as a log file for now. Koji
has very limited set of output types defined and I still need to
determine the best way to use a custom output type in Koji instances (as
other content generators do).
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Refactor koji.sh:
- Store Koji hub URL in a variable and use it instead of a literal.
- Do not inspect builinfo output and don't parse it using grep and sed,
but instead directly call Koji XMLRPC functions (using `koji call`)
with JSON output.
In addition, test that the image archive extra metadata are the same as
those stored in the build extra metadata, stored under the image
filename.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Run a basic check to see that the tailoring file has been created when
adding tailoring rules to the OpenSCAP config. Since the OpenSCAP scan
requires more memory and breaks some of the API tests, a full scan is
not run in the cloudapi tests.
test logs print:
[2023-08-22T10:18:14-04:00] 💿 Install image via installer(ISO) on VM
WARNING --os-type is deprecated and does nothing. Please stop using it.
Also extend the Koji test case to verify that the boot mode information
is in the build extra metadata and that it contains valid value.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Expose the extra metadata information for each image output stored in
`ImageExtraInfo` also in the build extra metadata. The extra metadata
for each image is nested under key corresponding to the image filename.
Extend the Koji test case to check information in the buildinfo output
and specifically check for all expected metadata in the build Extra
metadata field.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
