Update ostree-ng.sh to install and run ostree commit on UEFI VM
ostree.sh keeps on BIOS VM. Both of BIOS and UEFI are covered.
check_ostree.yaml ansible playbook has to be updated to support
both BISO and UEFI
sudo journalctl -af -n 1 -u "${WORKER_UNIT}" &
WORKER_JOURNAL_PID=$!
In this snippet, WORKER_JOURNAL_PID is set to the PID of the sudo process.
Sudo doesn't propagate any signals - therefore the child process of sudo
(journalctl in this case) isn't killed when a signal is sent to the parent.
Use pkill -P instead which kills all processes where sudo is the parent.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
According to Ben's suggestion, test has been updated to aligin with
customer scenario.
1. Setup ostree prod repo, building installer and edge upgrade
will be from prod repo
2. Containers for building installer and edge upgrade will be
running as stage repo
3. Before edge system update, prod repo will pull update content
from stage repo, make static-delta and summary
Using DISTRO_CODE simplifies test case selection and allows to test
different distro than the one test is running on.
This is used to run tests for RHEL 9.0 on F33 or RHEL 8.4
Previously, the Cloud API endpoint `/v1/compose/{id}` return value's
`image_status.status` for a running worker job was "running", which didn't
comply with the Cloud API specification. Equivalents allowed by the API
specification are "building", "uploading" or "registering".
As a result, the Image Builder API also does not comply in this regard
to its specification, because it currently just copies the status value
string returned by osbuild-composer.
Define the `image_status.status` as a reusable type in the Cloud API
specification. This forces openapi to generate an explicit type for it,
which can be then explicitly used in the code, instead of plain strings.
Return "building", instead of "running" for running compose.
Modify api integration test to check for all valid `image_status.status`
values for a compose.
Add News entry explaining this change.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Run tests with user-specified ostree ref.
The ref needs to be specified in the container build as well (without a
URL) to be used for the commit that will be served to the installer.
The same variable/ref is also used to retrieve the $UPGRADE_HASH for the
final OS test.
Extend internal GCP library to allow deleting Compute Node image and
instance. In addition provide function to load service account
credentials file content from the environment.
Change names used for GCP image and instance in `api.sh` integration
test to make them predictable. This is important, so that cloud-cleaner
can identify potentially left over resources and clean them up. Use the
same approach for generating predictable, but run-specific, test ID as
in GenerateCIArtifactName() from internal/test/helpers.go. Use SHA224
to generate a hash from the string, because it can contain characters
not allowed by GCP for resource name (specifically "_" e.g. in "x86_64").
SHA-224 was picked because it generates short enough output and it is
future proof for use in RHEL (unlike MD5 or SHA-1).
Refactor cloud-cleaner to clean up GCP resources and also to run cleanup
for each cloud in a separate goroutine.
Modify run_cloud_cleaner.sh to be able to run in environment in which
AZURE_CREDS is not defined.
Always run cloud-cleaner after integration tests for rhel8, rhel84 and
cs8, which test GCP.
Define DISTRO_CODE for each integration testing stage in Jenkinsfile.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Since kernel upgrading from 'default' to 'rt kernel' has SSH
connection issue, 'install' kernel and 'upgrade' kernel must
have 'kernel-rt' included.
https://github.com/osbuild/osbuild-composer/issues/1222
Only RHEL 8.4 repo has 'rt kernel' repo, 'rt kernel' test will be
RHEL 8.4 only
Return GCP-specific target results form the worker, similar as it is
done for AWS.
Extend Cloud API to allow GCP-specific upload Options.
Modify Cloud API to return UploadOptions as part of the UploadStatus.
Modify Cloud API integration test to check returned upload Options and
upload Type.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Extend the Cloud API integration test for GCP to also create a Compute
Node instance using the image, boot it and ssh to it. This brings the
GCP integration testing on par with AWS testing.
Use VHD image type for GCP integration testing, because it by default
contains `cloud-init` installed, unlike the VMDK image.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Upload target type is currently not returned form the worker, but
hardcoded in the cloudapi code to always return "aws". This make testing
of the cloudapi for other cloud providers quite complicated.
Since extending the target status information returned from the
worker is currently in progress, work around the situation for now
by returning an empty string as the upload type.
This will allows other types of upload targets to be tested as part of
cloudapi test case.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Refactor test/cases/api.sh to incorporate testing of cloudapi with
multiple cloud providers as the target. Since all variables in Bash are
by default global, don't declare them as empty in advance. The only
place where underclared variables can be potentially expanded are the
cleanup functions. Ensure that there are no unbound variables expanded
inside cleanup functions. Rename all AWS-specific variables to
contain "AWS_" prefix to make their purpose explicit.
Modify provision.sh to append the GCP credentials file path to the
worker configuration.
Add GCP api.sh test case to integration tests in Jenkins and run it only
if the appropriate GCP credentials environment variable is defined. Run
the GCP test case for RHEL images.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
The tools/provision.sh script is sourced by all test cases and it sets
up the system and software for running test cases. As part of the setup,
it copied over the whole content of test/data/composer/ to
/etc/osbuild-composer. However the source directory contains not only
osbuild-composer's configuration, but also configuration for the worker.
The worker however expects its configuration in /etc/osbuild-worker.
The fact that provision.sh does not copy the worker configuration to the
correct directory didn't affect the CI, because the only test case that
relied on it is koji.sh, which copies the worker configuration
explicitly.
Move osbuild-worker test configuration to a separate 'test/data/worker/'
subdirectory. Also install the osbuild-worker test configuration to its
own subdirectory in the "-test" RPM.
Move the copying of worker configuration to the correct destination
directory from koji.sh to provision.sh, so that all test cases can rely
on the system being set up properly. Do not use wildcard for copying
osbuild-{composer,worker} configuration files, but explicitly copy each
file to its respective destination directory.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
We are gaining new ostree features that overlap to a great deal
with the current ones. We still need to keep the current features
for backwards compatibility, so add another test run that does the
same but using new API.
For now this simply uses the `url` parameter rather than `parent`
to build update commits. Further changes will be made in follow-up
commits.
Use `curl` rather than `composer-cli` as we have a chicken-and-egg
problem where we can't land this feature without tests, but
`composer-cli` can't add support for it without having it first in
`composer`.
The image definition is shared with the latest RHEL 8.y one (8.4 currently).
I expect that we the introduction of 8.5 support, we point the centos 8
distro at it.
The test repositories and manifests use the official CentOS composes. From
what I can tell, they are persistent. This is not guaranteed though, so we
might need to switch to RPMRepo at some point.
The "classic" CentOS 8 should also be buildable but due to the chicken and egg
issue (this commit will get into Centos "8.4" but Centos "8.4" isn't a thing
yet), we cannot test it and therefore it might be broken.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Optionally allow a pacakge set to be included in the compose request.
The specified packages are added to the base packages before
depsolving. As the base packages differ between the image types
the package customizations may have different results on the different
images part of the compose request.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Expose a more detailed job status result - specifically, include upload status
alongside image status. Expand openapi.yml accordingly and add an UploadStatus
field to the OSBuildJobResult struct. At the moment, only represent the
"success" and "failure" states of UploadStatus - to differentiate between
"pending" and "running" would involve significant design decisions and should be
addressed in a separate commit.
Adding the tag called `Name` to the AMI ensures that the name appears in
the *Name* column inside AWS' web console.
Fixes#1171.
Signed-off-by: Major Hayden <major@redhat.com>
All tests in /usr/libexec/tests/osbuild-composer should be able to run without
any arguments. This was not a case of libvirt.sh - it required two arguments
set by some Jenkinsfile logic.
This commit moves test/cases/libvirt.sh to tools/libvirt_test.sh and extracts
the logic controlling the test case from Jenkinsfile to test/cases/libvirt.sh.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
x86_64 and aarch64 rhel 8.4 images support hybrid boot. qcow2 images are
now tested with both BIOS and UEFI boot. The Jenkinsfile now specifies
which boot type is supported when calling run_tests. For the qemu tests,
this boot type can be passed as an option so the test can boot using
UEFI.
In order to boot using uefi from a rhel machine, we must pass the --boot
uefi flag as well as tell libvirt where the variable store template is.
Since we are not testing secureboot, we must pass
nvram_template=/usr/share/edk2/ovmf/OVMF_VARS.fd to the --boot flag.
This is the location of our non-secureboot varstore template.
rhel 8.4 tests are added. The configs are based off of those used for
rhel 8.3. The Schutzbot Mockbuild, Base, Image, Integration, and OSTree
tests are added for 8.4. Repo overrides are added for the rhel 8.4 tests
so that the tests use rpmrepo snapshots.
The mockbuild uses the jenkins rhel84-nightly-repo credential to
override the rhel mock template's repos with rhel 8.4 nightly repos.
These repos are stored in a credential because they are internal links.
The image tests and koji tests need a special distro selector since the
rhel-8 test cases are only for rhel 8 versions less than 8.4. The rhel
8.4 tests are named with the rhel-84 pattern whereas the other rhel 8
versions have the rhel-8 pattern.
Also, instead of having only rhel-8 and rhel-8-beta repo configs for the
tests, we now have a specific repo config for each rhel release we test.
The repo is also now pulled from an rpmrepo snapshot. For whichever
distro is being tested, the approriate repo config will be copied to
/etc/osbuild-composer/repositories as rhel-8 and rhel-8-beta since this
is the naming osbuild-composer looks for. For testing purposes, the
rhel-8 and rhel-8-beta repo should be the same since eventually all rhel
releases will go from beta to not beta. The fedora repo overrides are
already done in tools/provision.sh so the rhel override is set there as
well. Currently, only rhel 8.4 requires an override.
If the ostree test was run on an unsupported distro, it failed but with a
very weird error message. This commit makes the test fail fast and with a
nice message.
The downloaded image may not fit inside tmpfs, especially when testing
on a constrained VM. This commit makes the test script use a different
temporary directory while handling the possibly big image.
The integration tests are leaving the composes (which include images) in
osbuild-composer. This can lead to exhausting the disk space we have available
on our tiny testing machines. This commit adds a removal of the composes
after each integration test is finished. This issue is not present in koji.sh
and api.sh as they use different osbuild-composer APIs that doesn't use the
artifact feature.
This issue occurred when I worked on enabling the Fedora 33 tests, see:
https://osbuildci.cloud.paas.psi.redhat.com/blue/organizations/jenkins/osbuild%2Fosbuild-composer/detail/PR-1014/23/pipeline