Let's explain how RPMs for RHEL are built:
We use a subscribed RHEL 8.x machine and mock build these on it. Mock
initializes its own buildroot based on the latest RHEL 8 CDN content, see[1].
This means that the minor version of the buildroot is independent of the minor
version of the host.
However, we currently upload RPMs to a directory whose name consists also of
the minor version of the host. Our hosts are currently running RHEL 8.3 so
the RPMs are uploaded into rhel-8.3 directory despite them being built in the
RHEL 8.4 buildroot (RHEL 8 CDN buildroot specifically). This means that
we cannot guarantee that they are installable on RHEL 8.3 which is weird.
This commit adds a special case for hosts that run on subscribed RHEL and
thus build RPMs in a buildroot constructed from RHEL CDN. These RPMs are
now uploaded into rhel-8-cdn directory. This change more accurately reflects
the way we build our RPMs and removes some confusion.
Also, we need to bump osbuild commit so we have a version that already has
the rhel-8-cdn change in it.
This also bumps all deps so we have rhel-8-cdn repos everywhere.
[1]: https://github.com/rpm-software-management/mock/blob/main/mock-core-configs/etc/mock/templates/rhel-8.tpl#L37
We want to use `dnf` in the same way as our users do. This means we want the
modular repositories and weak deps enabled. Fastestmirror is fine, it doesn't
change the content set nor depsolving.
Also, this is a workaround for rhbz#1908352, tl;dr: installing podman without
weak deps makes it unusable on Fedora 32.
Repository URLs are predictable. There's no need to use Jenkins' stash
feature to pass the repo file between stages.
Instead, simply create the repo file where it is needed, in deploy.sh.
This is similar to how other osbuild packages are testing: everything
that's needed for testing is included in the tests package or a
dependency of it. The test runner then runs every executable in
/usr/libexec/tests/<packagename>. This gives a simple test API to
projects depending on this package (notably osbuild-composer).
The local development workflow described in HACKING.md is meant to
continue to work. To ensure this, all relevant scripts gained a
TEST_DATA variable, which defaults to `./test`, but is set from $1 to
the installed path from integration.sh.
Now that osbuild and osbuild-composer use predictable destinations
for their dnf repositories, those can be used and auto-generated
from the environment and a specific git commit (identified by
the hash).
This will make updating easier, because the only thing we need to
change is the commit hash.
For osbuild-composer the latest release is used, for osbuild the
predictable repos were introduced after the latest release, so
the commit that introduced the feature is used.
Instead of installing and enabling the koji socket, use the new
api socket. The koji socket is not properly wired up anymore
and any attempt to actually use it with hang.
The CI is in two stages, for each supported distro.
First the RPMs are generated from the spec file in the repo for the
given distro and architecture.
Once all the RPM builds have succeeded successfully, a test machine is
provisioned with osbulid-composer installed, and koji API enabled.
The repository containing the RPMs of the code being tested is also
enabled on the test machine, and the cli client is installed.
Finally, the test/integration.sh script is executed, which currently
does nothing.
Signed-off-by: Tom Gundersen <teg@jklm.no>
