This *should* make things easier at branching, where we might
want not to tell fedfind/openQA about the new Rawhide release
number until there's a compose, but we still want tests of
Rawhide updates to go down the Rawhide paths.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
using podman run leaves containers and/or images lying around; if
the thing being tested is big enough, we can wind up with enough
that podman just stops working (I saw this while testing the
python 3.13 side tag). To avoid this, use podman run --rm, which
clears up the container/image after the command is run.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This works more or less like testing side tags. We also fix up
some flow problems with this path (that also affect the side tag
case), and enable the package checks on this path - it's not too
hard really, we just need to write the updatepkgs file when we
set up the repo, which we can do with dnf repoquery.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When testing the update that implements the dnf5 switchover, we
need to patch the kiwi config on the fly for dnf5.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This test, much like _live_build or _installer_build, builds a
container image in a way intended to be as similar as possible
to how official compose images are built. The purpose of the test
is to make sure updates do not break official container image
builds.
At the end of the test, we also check that the built container
is functional (at least, that we can run a 'hello world' command
in it). This can't really be rolled into podman.pm because that
test is more about testing podman itself, and it's just a one-
liner here anyway. We also run the 'if any packages from the
update are installed, are they the versions from the update?'
check inside the container, which required giving that check the
ability to 'wrap' the rpm commands to run inside a container.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
