to help with running the tests by hand on downstream snapshots.
In that scenario we want TEST_OS/VM_IMAGE to look as closely as
possibly like the snapshot that we'd like to test.
bcl: The mirrors are not very good at staying in sync, and if
composer hits one mirror and anaconda hits a different mirror,
you will see depsolve fail. The safest thing is to not use mirrors
in Fedora.
Note: use podman-docker to avoid changing tests too much. This
is also what we have on the RHEL branches.
There's no service to be started/restarted so remove everything
related to docker service.
On Fedora 31 passworless root login is no longer working. We already
install a ssh key, may as well use it.
This also reduces the live boot timeout to 2s from 60s, which should
help with timeout problems when booting.
This splits out the lorax-composer specific execution so that the built
image can be downloaded from the build vm and booted by the host instead
of using nested virt to try and boot it inside the build vm.
Also adds copying the ssh key from the build vm so that it can log into
the image and run the test_boot_* scripts.
- save compose logs under /var/log/$TEST
- save qemu logs under /var/log/$TEST/qemu.log
- download everything to $TEST_ATTACHMENTS so it can be saved
in CI results
Blueprint names can only contain alphanumeric characters and the characters: ._-. This test checks that an api request to create a blueprint with invalid characters in its name will return an InvalidChars error.
The VALID_API_STRING function allows for characters that should not be
allowed in blueprint names. VALID_BLUEPRINT_NAME allows us to
specifically check if a blueprint contains a valid name.
Beakerlib upstream can't do this yet, but might at some point:
https://github.com/beakerlib/beakerlib/issues/42
This is only enabled in combination with the `--sit` option of the
`test/check-*` scripts. It leaves the system in exacly the state it was
in when an assertion failed. Finishing the test run would run cleanup as
well (such as deleting created images). It also takes longer.
Test the HTTP API directly from outside the VM by forwarding
/run/weldr/api.socket to a TCP port on the host.
This is only a start to test that the API always returns JSON (see
previous commit).
this makes it possible to have more granular test execution
reported as separate statuses on GitHub. ATM we will have:
- cockpit/fedora-30
- cockpit/fedora-30/live-iso
- cockpit/fedora-30/qcow2
- cockpit/fedora-30/aws
- cockpit/fedora-30/azure
- cockpit/fedora-30/openstack
- cockpit/fedora-30/vmware
Helps in figuring out which tests are in a file without having to open
it. Use like this:
$ test/check-cli -l
TestImages.test_live_iso
TestImages.test_partitioned_disk
TestImages.test_qcow2
TestImages.test_tar
TestSanity.test_blueprint_sanity
TestSanity.test_compose_sanity
Names of classes containing multiple tests can be given, just like
normal:
$ test/check-cli -l TestSanity
TestSanity.test_blueprint_sanity
TestSanity.test_compose_sanity
Commit 4783f6562f introduced the assumption that beakerlib is already
installed in non-RHEL images. As the test script runs without `set -e`,
this hasn't been noticed as the test silently succeeds.
Go back to installing beakerlib everywhere.
Allows to run the tests on multiple operating systems and on the
infrastructure that the Cockpit team maintains.
`make vm` downloads one of Cockpit's test images (override which one
with TEST_OS) and installs rpms build from the local checkout of lorax.
The resulting image is placed in `test/images/$TEST_OS`.
TEST_OS can be set to any of Cockpit's supported images (default:
fedora-30).
Run `make check-vm` to run the CLI checks in the VM. The bulk of the
work is done in `test/check-cli`, which uses Cockpit's `bots` library to
start the VM and run the script in it.
Also included is a `test/run` script, which is the entrypoint for
Cockpit's test infrastructure.
