/var/log/audit/audit.log isn't always available (eg. tar liveimg
install), but it is logged to the journal, which can be grepped with
'journalctl -g' so use that instead.
Cherry-picked from 89539a7bf4
Related: rhbz#1769525
passwd and openssh-clients need to be installed, and there is no need to
use sudo when you are connecting to the system as root.
Cherry-picked from 454af0c5d5
Related: rhbz#1769525
after the changes around live-iso and qcow2 test cases the asserts
used have also changed. This commit utilizes the existing test lib.
Cherry-picked from d67745d755
Related: rhbz#1769525
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.
Cherry-picked from e1b45958f4
Related: rhbz#1769525
Use anaconda to install the root.tar.xz into a disk image. Copy the
disk image to the host, and use the cockpit vm support to boot it and
test it.
Cherry-picked from 4705ff3b1e
Related: rhbz#1769525
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.
Cherry-picked from e3654e8297
Related: rhbz#1769525
Nested virt is not reliable enough, especially on other arches, to rely
on for testing the created images. This moves the test code into
test_boot_* scripts to be run from inside the booted images.
It also adds copying the results of the build into
/var/tmp/test-results/, and includes the generated ssh key so that
whatever boots the image can also log in.
The tests/test_image.sh script has been added to handle running the
test_boot_* scripts without any of the extra lorax-composer specific
setup.
Cherry-picked from b8bf258a3c
Related: rhbz#1769525
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.
Cherry-picked from df7a018ee2
Related: rhbz#1769525
- 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
Cherry-picked from 8af9723c
Related: rhbz#1769525
The function is meant to replace the duplicate pieces of code used in various
tests, the polling interval is unified to 20 seconds.
Cherry-picked from 836f0ddf
Related: rhbz#1769525
These weren't built until after 8.0.0, which they were approved for, and
even though they have all acks, it's for the wrong release so the build
system complains when they end up back in lorax.spec
This makes sure that required fields are included, and that sections are
not empty. It does not check for all optional fields.
If there are errors it will gather up all of them and then raise a
RecipeError with a string of all the errors.
(cherry picked from commit 61059a2699)
Resolves: rhbz#1716596
The 'enabled' field in the /compose/types output now reflects whether or
not the type is supported on the current architecture. Disabled types
are not allowed to be built, and will raise an error like:
Compose type 'alibaba' is disabled on this architecture
Resolves: rhbz#1751998
* 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
Cherry-picked from master commit a2c67385e4.
Previously it was looping, waiting for FINISHED|FAILED but was not
actually failing the test if the compose failed to build.
This adds a function to check the status of the compose and calls it
after each compose.
(cherry picked from commit d0e947fe3b)
Related: rhbz#1724073
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
Make sure that dotfiles are installed when not directly under /
Make sure / is not packaged in the rpm (it will cause a conflict with
the filesystem package).
Make sure that using destination="/" works
(cherry picked from commit 6fd06c6931)
Related: rhbz#1709594
rpmfluff was including / in the rpm, which conflicts with
filesystem.rpm
The rpm globs are pretty limited, and we don't actually know the file
paths until later, so we have to use a glob or a directory.
So when the destination is / it now uses /* to select all the files and
sub-directories in the archive. The limitation of this is that it cannot
support dotfiles directly under /, they will cause a rpmbuild error.
For destinations other than / it uses the name of the directory, so
dotfiles are fine in that situation.
(cherry picked from commit 049f68cb60)
Related: rhbz#1709594
- Check final-kickstart.ks for the rpm source
- Check final-kickstart.ks for the rpm package name and version
- Make sure depsolve works
- Make sure errors from a bad repo are returned correctly
- Make sure errors from a bad reference are returned correctly
This moves _wait_for_status into a helper function so it can be shared
between the test classes.
(cherry picked from commit 8c2184d59e)
Related: rhbz#1709594
The freeze function was not being tested. Add a test for it using the
repos.git test recipe.
(cherry picked from commit c26477a63c)
Related: rhbz#1709594
This hooks up creation of the rpm to the build, adds it to the
kickstart, and passes the url to Anaconda. The dnf repo with the rpms is
created under the results directory so it will be included when
downloading the build's results.
(cherry picked from commit cd8c884adb)
Related: rhbz#1709594
This handles creating the rpm from the dictionary describing the
repository and rpm. Also adds tests for archive and rpm creation.
(cherry picked from commit f6f2308765)
Related: rhbz#1709594
This adds support, documentation, and testing for a [[repos.git]]
blueprint section that can be used to install files from a git
repository. It will create an rpm that will be added to the build,
and included in the metadata that can be downloaded. This allows you to
accurately keep track of the source of configuration files and extra
metadata that is added to the build.
The source repo and reference will be listed in the rpm's summary making
it easy to discover on the installed system.
(cherry picked from commit d7b96c8f0f)
Resolves: rhbz#1709594
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
