- 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
tests: export BLUEPRINTS_DIR for use in tests
Depending on the way the tests are run the directory may be a temporary
dir, or it may be the standard /var/lib/lorax/... path.
Related: rhbz#1714103
bacause this requires additional Python modules and we don't
really use it! Fixes
[ WARNING ] :: cannot create journal.xml due to missing python interpreter
Add -monitor none to turn off the qemu monitor multiplexing.
Pass -boot d for -cdrom booting instead of 'c'.
Add 'console=ttyS0,115200n8' to the boot arguments so that kernel output
will show up on the serial port.
the biggest slow down is fetching data for many repositories
over a slow network. The previous retry count and sleep times
sometimes are not enough on Fedora.
It's necessary to make sure the blueprints directory doesn't contain
the git/ directory before the tests are run, so that we can just simply
modify the blueprint files without using blueprints push.
Related: rhbz#1714298
`setup_tests()` expected BLUEPRINTS_DIR to be set, but it wasn't when
running in automated mode (with $CLI set).
Fix this and move share and blueprint dirs to function arguments.
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.
this will allow you to test against installed RPM like so:
# export CLI="/usr/bin/composer-cli"
# make test_images
If you already have lorax-composer running then you can directly
execute test scripts:
# ./tests/cli/test_build_and_deploy_aws.sh
otherwise composer-cli is unable to glob() the kickstart
files and we're left without supported compose types. Seen
during AWS testing for example.
Helps with running some of the tests via sudo b/c this is
what Jenkins requires.
If trying to execute test_cli.sh inside a git checkout
we are going to get the following exception:
Traceback (most recent call last):
File "./src/sbin/lorax-composer", line 251, in <module>
repo = open_or_create_repo(server.config["REPO_DIR"])
File "/home/jenkins/lorax/src/pylorax/api/recipes.py", line 306, in open_or_create_repo
gi.repository.GLib.Error: ggit-error: failed to stat '/home/jenkins/lorax/tests/pylorax/blueprints': Permission denied (-1)
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
File "/usr/lib64/python3.7/multiprocessing/popen_fork.py", line 54, in _send_signal
os.kill(self.pid, sig)
From what I can tell open_or_create_repo() is trying to initialize
a git repository inside the blueprints directory which fails when
we have an active git checkout.
This doesn't happen when we run the tests in Travis CI because
rsync excludes .git/ inside the Docker container.
these targets help hooking up things in Jenkins and enable us to
perform build & deploy tests for cloud images.
NOTE: use sudo -E to preserve the environment
It needs to be root in order to set the ownership and permissions on the
directories that are under /var/lib/lorax/composer/
Refactor the directory creation into a utility function, and use a umask
of 0o006 to ensure that the parent directories created do not have o+rw
set on them (makedirs behavior is different between Python 3.6 and 3.7
so umask of 0 doesn't work consistently).
Also kill the lorax-composer process and remove /run/weldr/api.socket
so that when this is run with podman you don't get an error about
attempting to tar up the socket.
- need to specify --sharedir so lorax-composer can find its
kickstart files
- each test script writes results into a separate directory to
avoid a passing test overwriting the results from a failing one.
To avoid reporting failures in case of previously failing tests
(e.g. during development) remove the temporary directories holding
tets results before execution!
these are built on top of beakerlib and we use its internal
protocol to figure out the result without relying on the full
test runner that is tipically used inside of a RHEL environment!
Includes a disabled test snippet for Issue #460