These cases are pointing to internal repos that have since changed. Drop them
until we have a better long-term story.
Our CI currently does not verify these cases, so this is not a behavioural
change.
Signed-off-by: Tom Gundersen <teg@jklm.no>
A manifest is struct made up of a pipeline and a sources object. So
far all our sources objects are empty, but we have moved from
using pipelines to manifests everywhere, in preparation for
generating pipelines that require sources.
Make the same change in the test cases.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This is to avoid any confusion with the Compose struct in the store,
which contains the pinned rpmmd data and the pipeline, among other
things.
The struct in the test cases represent the user input to the compose
route, so rename it 'compose-request', to make that clearer.
Signed-off-by: Tom Gundersen <teg@jklm.no>
The intention is that the compose struct fully specifies the test
case, and pipeline and image-info specifies the expected outputs.
Lastly, the boot struct specifies how to boot-test the image.
The checksum does not fit into this scheme, as it is computed from
the compose by querying rpmmd, and it is then passed as an input to
distro.Pipeline in order to compute the pipeline.
Introduce a new struct, rpmmd, which will eventually contain all
the data returned from rpmmd.Depsolve and later passed to
distro.Pipeline. For now it only contains the checksum.
This is not a functional change.
Signed-off-by: Tom Gundersen <teg@jklm.no>
When creating a pipeline the assembler includes an image size. This
image size can be set when creating the pipeline but if it is 0 then a
default image size will be used. The default is 2 GB except for ami
images which are 6 GB.
During development of a new distro, we need to test composer against
nightly or beta repositories, but we cannot ship composer itself
with the nightly repository information hardcoded in. At the same
time, we want to distinguish between the system repositories of the
host and the repositories we use to generate images (the host may not
use the same distro/version/architecture as the target, and it may
include custom repositories that the target should not).
We therefore ship per distro repository information that can be
overriden (typically in testing) by dropping files in /etc.
For now use the latest nightlies for RHEL-8.2, we may want to
replace these with the official mirrors for GA eventually.
Signed-off-by: Tom Gundersen <teg@jklm.no>
When group names are passed on to dnf, they must be prefixed with an
ampersand, or they are treated as a regular package, potentially
causing the build to fail.
Add a testcase to verify this behavior.
This resolves rhbz#1784035.
Signed-off-by: Tom Gundersen <teg@jklm.no>
On architectures that require EFI, we must create the ESP partition
and use a GPT partition table. We must also install either the UEFI
or the legacy version of GRUB2 in the image.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Move to the new options format, allowing more flexible partition
tables. The pipeline changes, but the result should be the same.
This requires a yet-to-be-released version of osbuild.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Allow bootloader specific packages to be defined per architecture,
and allow repositories to depend on the architecture.
This does not altert he pipelines we produce, part from the ami
image now contains the grub2-pc package, rather than the grub2
package. This should make no difference.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Make sure we catch expected errors and fail gracefully. Also, make
sure the output id is printed on successufl osbuild run so it can
be introspected from outside the test suite.
Handle the case where osbuild suceeds but does not return an
output_id.
Signed-off-by: Tom Gundersen <teg@jklm.no>
These are used to verify that our pipeline generation is stable, and
that the piplines can generate images that boot.
Signed-off-by: Tom Gundersen <teg@jklm.no>
When we get an ssh connection, before the image is fully booted,
systemctl is-system-started returnse "starting", treat this as a
failed connection, and keep retrying.
Some distros may not support the wait switch correctly.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Instead of having a static repository checksum, set it dynamically from
the metadata that osbuild-composer last saw. This is implemented in
dnf-json, which returns the checksums for each repository on every call.
This enables the use of repositories that change over time, such as
fedora-updates. Note that the osbuild pipeline will break when such a
repository changes. This is intentional: pipelines have to be
reproducible.
Currently we still only build for x86_64, but now the test suite is
prepared for hooking up other architectures.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This way we can test the distros on their respective CI, as not
all distros can be built in all environment. In particular RHEL
needs to be on a subscribed host.
Signed-off-by: Tom Gundersen <teg@jklm.no>
We can now select specific cases, but whether or not to check image-info
or boot the image is determined purely by the contents of the json test
case.
We still run the tests as two travis workers just to avoid the timeout,
this should clearly be reworked.
Signed-off-by: Tom Gundersen <teg@jklm.no>
We were supporting downloading an image and checking its image info. We don't
want to rely on external resources, and we should not test images made by others.
Drop it.
We were failing on name reuse. We should be able to not name these
at all, but nspawn is not happy with that.
Signed-off-by: Tom Gundersen <teg@jklm.no>
We now have three top-level maps, that can be combined in any way:
boot-test: information about how to boot the image
compose: information about how to generate the pipeline
pipeline: the pipeline to generate the image
expected: the expected image-info
This creates compose entries for all the boot tests, but the blueprints
are named 'blueprint-draft', as we are not yet verifynig that the pipeline
is correct.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This passes the redhat user with ssh key as an ISO image to our
qemu instances, making sure images relying on cloud-init rather than
hardcoded user credentials can be used in our tests.
Signed-off-by: Tom Gundersen <teg@jklm.no>
For the qemu tests this makes no difference as we are anyway forwarding
the ports. But the nspawn tests share the same network namespace between
the image and the ssh client running the test without any forwarding. In
order for that to work we had to modify the image to use a non-standard
port.
We don't want this for two reasons: we want to make sure we test our images
unmodified, and also this meant that when we changed our pipeline generation
we were not verifying that the boot test cases were updated accordingly. As
a result they have now drifted.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This makes sure we can use any port to connect to sshd, without
worrynig about clashes with parallel tests, or an sshd instance
running on the host.
Signed-off-by: Tom Gundersen <teg@jklm.no>
