This is the same thing we do for the app_startstop tests in
aaa_setup, applied to a couple of other places we use
menu_launch_type in KDE and it's having trouble.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When running these tests on updates we inherit the main disk
image from server_cockpit_default, which has the repo config,
but the actual repo data is on HDD_3 which is not inherited.
We need to re-download the updates here to ensure they're
available to the tests (the automatic update test installs the
dnf-automatic package, so it should pull it from the update repo
if it is part of the update being tested).
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>
From https://openqa.fedoraproject.org/tests/2594954 it looks
like this takes more than three minutes for updates with hundreds
of packages when running in a container (in the container build/
validate test). So, let's give it more time in that case.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The bug number is wrong and I can't find the right one, d'oh.
We could *probably* safely remove this right now but I'm not
100% sure, I think it should be fine when F38 is EOL.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit b203f41f55.
The bug has been worked around for some time with a downstream
patch. Dropping the extended timeout means we'll notice if the
workaround is dropped prematurely or stops working.
This whole complicated loop looks like it's no longer needed for
current KDE. It seems like we always refresh, then we hit
"Update All", and from there we go straight to "Restart Now".
Clicking the button always seems to work, we never seem to need
to click "Refresh" again. So, let's drop it and simply expect to
see and click Restart Now.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
dnf5 config-manager can now do this, but the syntax is different
to dnf4, and honestly, it seems easier to just stick with this
going forward than make it conditional on dnf version until
dnf4 goes away. So let's stop marking this as a FIXME.
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>
Don't know why we need so many of these. There's something odd
about the panel in Plasma 6, I think.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is the variant we hit when upgrading from Fedora 40 (the
button looks a bit different than on F39). Without it the test
for Rawhide (which upgrades from F40) will fail.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
containers-common seems to have inadvertently introduced a hard
dependency on composefs, but not expressed it as a package dep.
While I'm trying to get that fixed, let's ensure the podman and
toolbox tests don't fail on it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR builds on some elements of the current upgrade process,
such as upgrade_boot, upgrade_preinstall, upgrade_postinstall, but
replaces the upgrade_run with graphical_upgrade_run to use graphical
methods to upgrade the system.
This would not be possible without necessary settings, that are
performed by graphical_upgrade_prerequisites.
Works for both Gnome and KDE.
This is obviously more prone to mistypes, but firewall-config
seems to be timing out if we take more than 25 seconds to type
the password, and we take juuust too long with type_very_safely,
even after tweaking the sleeps to shorter wait_still_screens
here. We could twiddle with those even more, but let's just go
with type_safely for now, if that turns out to be too unreliable
I'll change tack.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is failing quite consistently lately because we're typing
too fast, we need to wait a bit after the sudo su at least. Let's
be safer.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This comes from trying to fix the annoying recurring problem with
mistypes in KDE which has been going on since at least December.
First, we add the attempt to kind of 'precache' the kicker menu
in aasetting.pm. Then, I thought, all this snapshot loading has
to be putting a lot of load on the workers. And when each subtest
passes, it shouldn't really be necessary - they all end with
quit_with_shortcut(), which verifies that the app exited and we
got back to a blank desktop, so successful subtests should not
usually interfere with each other. We probably only want to
rollback on *failed* subtests, which is in fact openQA's default
behavior. There only seems to be one case where a test changes the
system state such that later tests might be affected, so I kept
always_rollback just for that one. I've run this through three
cycles on GNOME and KDE and it looks good.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Various changes to the Tour text needed needle updates. The
final screen doesn't say "Have a nice day!" any more, so let's
rename that needle.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Since 46, the 1 minute button is a quickstart, it doesn't just
set the timer but starts it. So we can't always expect to have
to click the start button. Let's keep it working both ways for
now for respin testing, we can drop it once we're sure we're not
doing any testing on F39 any more.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
osbuild is struggling with the pre-release warnings ATM:
https://pagure.io/fedora-iot/issue/57https://github.com/osbuild/images/issues/515
Until that mess is cleaned up we can't really make sensible
assertions for osbuild images, so let's make the check a soft
failure for now (now we know about the bugs, we want to let
the rest of the tests run and not block them on this).
Note for IoT the behaviour has never really been correct (IoT
images never get pre-release warnings), but the logic in this
check matches the wrong behaviour (IoT composes always have
RC- labels even when they're clearly not RCs), so the test
didn't fail. While fixing this in osbuild we might try to get
'correct' behaviour for IoT, and then we'd need to tweak the
logic here.
While we're at it, tweak the implementation a bit; without this
tweak, implementing this 'soft fail if osbuild' behaviour is more
awkward and ugly.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR partly solves the issue #301 when it adds the navigation
testing for Gnome. It uses the keyboard combinations to cycle through
running applications and checks that applications could be switched
accordingly. It also tests that you can switch between workspaces
and that you can move an applications to another workspace.
Somehow these two got completely scrambled, testing the wrong
things on the wrong images. Fix them to match the non-blivet
counterparts, which are correct.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The worker containers aren’t using systemd-resolved so
get_host_dns() can’t find the dns server causing tests that need
it to fail. Add an alternative place to look for the dns server address
that doesn’t rely on systemd-resolved.
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
The silverblue tests are flaky because of
https://github.com/fedora-silverblue/issue-tracker/issues/548 .
The desktop_upgrade_encrypted test is flaky on Rawhide (so, when
booting from F40 initially) since we switched to UEFI, not sure
if it's because of UEFI somehow or just a timing coincidence.
Am going to look into it, but for now this should save lots of
manual restarting.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is actually a very useful to wait a little bit before
we try to operate with the started application, especially
if we want to send keys.
Having this wait time here can save us doing this every time,
we start an application.
The mistypes on KDE are bugging me. Let's see if this - mainly
the wait_screen_change, the other just seems like a logical
tweak - helps at all.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
ELN can't boot with Secure Boot enabled currently:
https://github.com/fedora-eln/eln/issues/183
Until that's resolved, let's go back to testing on BIOS (this is
easier than testing on non-SB UEFI for...reasons).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This essentially inverts the x86_64 machines so that '64bit' is
UEFI and instead of a variant 'uefi' machine we have a variant
'bios' machine that is BIOS. The point is to make UEFI testing
the default. We also enable Secure Boot in the UEFI testing,
and add a test of UEFI fallback booting on various products.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
