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>
RHEL and Fedora used different output formats (.ami vs .raw.xz). The job
package assumed `image.ami`, which failed for RHEL.
Change Fedora to use image.raw.xz as well. This makes it consistent, but
we should also get the filename from the distro at some point.
osbuild has a concept of runners now: scripts that set up a build
environment. Update the osbuild submodule to latest master, change
`Pipeline` to to the new buildroot description format, and use the
`org.osbuild.fedora30` runner from the fedora30 distro.
This slightly changes the customizations logic. We now make sure
that each stage is appended exactly once.
customizations.go are now responsible only for the things that are
completely generic, and not per-ouput-type. helpers.go contain more
high-level helpers that combine customziations and per-output-type
defaults.
This does not change the behaviour, though some pipelines are slightly
reordered to make them consistent.
Signed-off-by: Tom Gundersen <teg@jklm.no>
1) additional qemu tests for ami, vmdk, vhd, and openstack image types
2) new type of systemd-nspawn tests for tar, ext4, and parititioned disk
types
the systemd-nspawn tests use loopback network interface directly from
the host so it is necessary to tweak the settings of its SSH server.
This is done in a "script" stage using simple "sed" command.
The tests works by executing osbuild with predefined pipeline. Then the
image boots and the testing script creates SSH connection to the running
VM. If everything goes fine `systemctl is-system-running` is executed
with result `running` and the test case passed.
The JSON definition of the test case contains also a blueprint that
should generate the desired pipeline, but it didn't work for me, so I'm
including it for future use from the golang unit tests.
Introduce the `distro` package, which contains an interface for OS
implementations. Its main purpose is to convert a blueprint to a
distro-specific pipeline.
Also introduce the `distro/fedora30` package. It is the first
implementation of the distro interface. Most of its code has been copied
with minimal modifications from the blueprint package.
The `blueprint` package is now back to serving a single purpose:
representing a weldr blueprint. It does not depend on the `pipeline`
package anymore.
Change osbuild-composer and osbuild-pipeline to use the new API,
hard-coding "fedora-30". This looks a bit weird now, but is the same
behavior as before.
All test cases now also take an "distro" key in the "compose" object.
These tests (will) test more than just image-info: they'll take a
blueprint, verify that `osbuild-pipeline` generates the correct
pipeline, run osbuild with that pipeline and verify that the resulting
image has the expected image-info output.
This change only includes the latter half (i.e., only moves the already
existing tests).
Also drop python's unittest. It was hard to control output (important
for quickly spotting failures and to make travis happy). This introduces
test/run, which runs all test cases in test/cases or the ones given on
the command line.
When a failure occurs, it prints a diff of the actual and the expected
image info.
