I am honestly not sure exactly when we hit this needle, but we
did at least once, and it's mentioned in the comment in the test.
Huh.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In tests of the Rawhide anaconda update that ports to Wayland,
we often hit failures because the first attempt to click on
Installation Destination doesn't work. This only happened on prod
(not staging), it didn't happen every time (but quite often), and
we can't reproduce it manually, so it seems like a weird glitch
that we should just work around. Simply waiting a second and
clicking again seems to do the job, and should be safe even if
the first click works (the second click will just be on an empty
area of the Installation Destination screen, unless we have like
eight disks attached).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
All the KDE flakiness lately is likely caused by the recurrence
of https://bugzilla.redhat.com/show_bug.cgi?id=2312900 , which
came back because the patch to fix it was inadvertently dropped.
This adds the F40 and F41 updates that re-introduce the patch as
workarounds to address the sluggishness.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The others have all been rebased to F41, so we had to bump the
Platform version to 41, but since Cheese is kinda dead these
days, its flatpak hasn't been bumped, and that makes building
the F39 ostree installer image fail. To work around this, sed
it out of the pungi config.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We do a menu_launch_type for kwalletmanager, so we'd better keep
a doublek workaround before that :/
Signed-off-by: Adam Williamson <awilliam@redhat.com>
These seem to be needed as a consequence of the previous commit
changes to desktop_login, not sure why, maybe something to do
with no longer opening the kicker once before we start doing
power actions.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Also be a bit more consistent about asserting we saw a terminal
and waiting a bit before typing stuff. We can drop the doublek
workarounds from the keyring tests as we no longer use the
kicker to launch the terminal on KDE (we use ctrl-alt-t shortcut).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This started out as just factoring out the repeated pattern for
launching a terminal on the desktop that came in with the i3
tests. But as I worked on desktop_login, which is a major user
of it, I noticed some potential cleanups and improvements in the
user switching stuff, and also realized we can turn that test
back on for KDE now - user switching was re-enabled in KDE a year
ago and is advertised to be reliable.
I don't think the "switch user from a lock screen" test fully
worked before, as we did not verify that we'd really switched
back to an existing session rather than starting a new one. Now
we do. Using the terminal to verify the logged-in user on all
desktops just keeps things simpler than using the kicker menu
on KDE (though if typing proves unreliable on KDE I may switch
this back).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Without this, all we did on i3 was hit alt-d and...do nothing,
we didn't type the app name.
I was confused at how we didn't notice this before, but it looks
like at present menu_launch_type isn't actually used in any
test we run on i3 (a lot of tests that use it to run a terminal
got a branch for i3 which uses alt-enter instead). This is an
obvious landmine, though, and it caused things to look weird
when rebasing #323 (which is how I noticed the bug).
This also refactors the sub to use the same logic for all
desktops, just with a different key for i3, since they really
all work the same. i3 doesn't need as much waiting as the other
desktops, probably, but it doesn't really hurt and keeps the code
simple.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We seem to be having quite a few failures lately because the
viewer window in KDE never got maximized. This makes us a bit
more conservative at startup and puts the maximization / sentence
check in a send_key_until_needlematch loop to give it more
chances.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's no obvious reason we're not also running these tests on
updates, so let's do it. We have to skip the advisory and UEFI
post checks for desktop_login as the last step of that test is
shutting down the system.
We leave out desktop_login for now because of
https://gitlab.gnome.org/GNOME/gjs/-/issues/647
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This avoids some magic waits by asserting screens (which is much
more reliable), and combines KDE and GNOME flows in the
passwordless test by adding some needle tags to the nautilus
needles.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The new NetworkManager update needs it. Lack of composes is
starting to bite us more, need to get one through.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Another update depends on it. It's gone stable already, but we
are having issues with composes ATM so it hasn't made a compose.
It's safe to do this as we can be sure the depended-on update
will be in the next stable compose whenever it completes, so we
can't wind up in an inconsistent state.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Over the time, we have changed the test scripts so that the code
in the i3.pm library was no more needed. The only leftover was the
user config subroutine that could be moved to the only file that was
using it and we could get rid of the library file.
There are several other tests doing the same thing (but not as
safely, in some cases). To improve reliability and reduce
duplication, let's factor this out into utils.pm and reuse it
where appropriate.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is still the case on the flatpak build as it runs behind the
RPM build, and would still be the case if we run the test on an
F40 respin for e.g.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
