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>
