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.
* If `$COCKPIT_BOTS_REF` is set, check out that bots version instead of
master.
* Use git cache in $XDG_CACHE_HOME if available. Our CI uses that to
save downloads, and it does not get in the way for local developers.
Adapted from https://github.com/cockpit-project/starter-kit/pull/233
Commit 4643afa58 was a thinko -- for our CI we *don't* want our test to
clobber a pre-existing bots/ checkout, as we often use this to run tests
against an updated image or to validate a changes to the bots project.
On developer machines, bots may also be a symlink to an actual bots
directory in development, so don't clobber that.
Stop making "bots" a phony target, and drop the now unnecessary
`[ -d bots ]` check.
Adapted from https://github.com/cockpit-project/starter-kit/pull/232
Also add a test_cli target to run things like the blueprint cli tests.
Run this like so:
RUN_TESTS="ci test_cli" make test-in-docker
If nothing is passed it will run the "ci" target.
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.
Change the docs-in-docker target to generate the docs for the NEXT
release, not the current one. Also pass in uid/gid so that the new files
can be set to the correct ownership instead of root.
Modify docs/conf.py to bump the version of the docs if
LORAX_VERSION=next is set in the environment.
- on some arches (also Fedora x86_64) systemd-nspawn may not be
available
- delete composes from other tests in rlPhaseStartCleanup because
we're seeing the tar compose kind of hanging in Jenkins and that
test script is executed last so the slave may be running out of
disk space. Be a good citizen and clean up after the previous
tests.
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
When I re-arranged the test-in-docker I didn't realize how .travis.yml
was extracting the results. This should fix it.
When running with test-in-docker we mount the source read-only on
/linux-ro/ inside the container and copy it over to /lorax/ for running
the tests.
The local directory ./.test-results/ is mounted on /test-results/ in the
container and the .coverage file is copied into there so that it is
available on the host.
To use podman run the tests like this:
DOCKER=podman make test-in-docker
This now builds the welder/lorax-tests image as a separate step from
running the tests.
Running the tests uses the welder/lorax-tests image and mounts the
source directory read-only, copies it into /lorax-test/ and runs the
tests from there.
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
This fixes the 'make install' target to work on a typical RHEL or
Fedora system. We now by default install to a prefix of /usr instead
of /usr/local
The prefix is overridable like so:
$ make install PREFIX=/opt/
This makes it easier to generate new documentation for
http://weldr.io/lorax/
It requires having a current welder/lorax-composer:latest image (created with
the test-in-docker target), then run docs-in-docker to rerun sphinx with
the docs/html directory mounted from the container.
Here's a bash_completion file for composer-cli! It completes known
commands, subcommands, and flags, plus arguments to flags that take
arguments, and if you've got write access to the socket it'll also
autocomplete:
* source names for commands that need source names
* blueprint names for commands that take blueprint names
* compose uuids for commands that take compose uuids
* intelligently only suggests appropriate uuids - e.g. only
suggests uuids of running composes for "compose cancel"
NOTE: bash completion scripts are horrible and this is no exception.
Please forgive me.
We should have as much of the logic of how the CI tests are run in source
control as possible, so that's what this target is for. Besides this, jenkins
just runs a "git clean" first.
This updates things for python3, and adds 2 subpackages to pull in
dependencies needed by lmc when running with virt-install or --no-virt
with anaconda.
Run 'make docs' to update the apidocs.
Also moves the README.livemedia-creator and README.product into docs
as ReST documents. They will be installed in /usr/share/doc/lorax/
by the rpm package.
