The bootloader option in ostree.config stage is new in osbuild 37. However,
osbuild 37 contains a bug that prevents it from working in certain cases,
thus we need to pin to a slightly newer commit that contains a fix for it:
bug: https://github.com/osbuild/osbuild/issues/822
fix: https://github.com/osbuild/osbuild/pull/824
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Use the new bootloader config for OSTree deployments to set the
bootloader backend to `none` since we use grub2 and BLS in all
currentlysupported architectures. In fact, not setting it to
`none`, will use the default `auto`, which will result in the
run of `grub2-mkconfig`, which is not what we want and might
even fail for us.
Expose the new (osbuild > 36) `sysroot.bootloader` option to
configure the bootloader backend for OSTree deployments.
Normally, this should be set to `none` for modern bootloader
that use the BLS, since the BLS snippets are always generated.
The main changes are:
- Kind, Href, Id fields for every object returned
- Attach operationIds to each request, return it for errors
- Errors are predefined and queryable
We don't run on RHEL 8.3 anymore.
Note that the koji-osbuild rev-deps test is not run anymore, therefore
it's fine to drop dependants, see:
https://github.com/osbuild/osbuild-composer/issues/1559
We should reintroduce it though.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
We use the koji API to build RHEL nightlies, therefore we should build
only development versions in the testsuite.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
There is no need for osbuild-composer to wait until the whole multi-user
target is completed. It can be started earlier as it doesn't have any
dependencies in the target.
This can be a problem if there is a unit in the target that is not starting
and still is unrelated to osbuild-composer. There was a bug like this
with Plymouth where the service didn't finish and it was hanging. That
prevented osbuild-composer from starting and the user was left with
working SSH connection and shell, but composer-cli and systemctl start
osbuild-composer.service were both unresponsive.
Replace After=multi-user.target with After=network.target to start
osbuild-composer earlier.
The variables are set to the git revision from which the build is
triggered and rpm version from the spec file, if it is build using RPM.
This can be later used to query exact source version while
running osbuild-composer.
It is necessary to use both, because none of them is available in all
possible scenarios.
Use either git-rev (preferably) or RPM version (NEVRA) instead of the
"devel" build type. It was just a placeholder.
The ostree-ng test was updated to accommodate a change in the
edge-container image type
(see https://github.com/osbuild/osbuild-composer/pull/1595).
RHEL 9.0-beta uses the old edge-container configuration, however RHEL
9.0 GA should eventually adopt the new container.
Copying the old ostree-ng test and running it separately is better than
having several conditions in the single test script to accommodate the
old behaviour and then reverting them when the changes land in RHEL 9.
Modified from the old version to assume we're using 'weldr-client'
(which has a different json output schema) and to use RHEL 9
naming/versioning where necessary.
The ansible checks were also copied to remove the kernel-rt check.
Signed-off-by: Achilleas Koutsou <achilleas@koutsou.net>
recover from panics such as out-of-bounds array access & nil
pointer access, print a stack trace and return 5xx error
instead of the service crashing and relying on Execution
framework to handle crashes
The base url for the osbuild-worker container was
missing the `https` protocol in the docker-compose file.
This commit adds this to prevent the worker from exiting
The `nss-altfiles` package is actually needed for OSTree based
systems, since in those the user/groups database is located in
the /usr/lib directory (in addition to /etc). It was removed
because it was not available in RHEL 9 (rhbz#1916260). This has
been fixed, so we need to re-include the package.
Generating image test case with all possible blueprint customizations is
supported only for `qcow2` image type. Generating `qcow2` images with
customizations was not a lot of fun. One had to use a special CLI option
for this case.
To streamline the generation of image test cases, drop the
`--with-customizations` option from the `generate-test-cases` script and
move the functionality to `format-request-map.json` by defining a new
`qcow2-customize` test case. This is very similar to what `*edge-rt`
test case already uses. This mean that when the test case for `qcow2`
image type is being generated, actually two test cases will be
generated. The filesystem customizations since RHEL-8.5 are handled
through distro-specific `overrides`.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Some of the `overrides` specified in `format-request-map.json` were
redundant, because the same blueprint customizations were already
specified in the image compose-request. Thus these values had no
additional values.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Unfortunately, after the addition of `supported_arches` item to some
of the image type definitions in `format-request-map.json`, it started
to leak to the `compose-request` object in the generated image test
case.
Ensure that the item does not leak to the generated image test case,
since it is relevant only for the generator script.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Add a CLI option to keep the workdir created on the runner, after it
finishes its work. The workdir is deleted by default.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
