If there are too many categories, we don't see the Updates entry
on the left, and this has been breaking Rawhide and F36 tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Before F34 we had to launch the update tool from the systray.
This isn't the case any more, so we can throw all this code and
these needles away.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
OK, this is annoying. GNOME Software intentionally does *not*
clear the 'download' or 'reboot and update' button when you hit
the refresh button, it just leaves them sitting there while the
refresh happens. So let's specifically require the 'refreshing'
text to appear and go away before we try and click on download
or apply.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Agh, GNOME's UI is *not* helpful here at all. The Apply button
remains visible for a long time after you hit Refresh.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is yet another twiddle to that same damn bit where we try
to apply updates. This more or less reverts the last tweak to
it, where we skipped hitting 'refresh' if 'download' or 'apply'
are already visible. The trouble with that is that the app may
have already found and prepared updates before we got our
"prepared" python3-kickstart update in place - so the update
operation might work perfectly, but not update the package we
expect it to update, and the test may fail.
This time, let's try *always* refreshing, then wait a bit after
hitting the refresh button before we start looking for apply
or download to try and avoid the 'race' we were trying to solve
with the last tweak (where we hit refresh then immediately try
to hit a download or apply button which vanishes before we can
hit it). I think this should be safe as both KDE and GNOME
should always show a refresh button now (this wasn't the case
before, I think, F34).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I've seen some failures caused by a sort of race where both
'apply' and 'refresh' needles match at the first assertion, but
openQA "prefers" the 'refresh' match. So we click the 'refresh'
button and *immediately* check_screen for apply, which is still
visible...but by the time we go to click it, it's gone because
the refresh found something new and now it's showing "Download".
This tweak should help, because if we can 'see' both refresh and
apply at the start, we'll just go ahead and click apply, we
won't refresh. The logic becomes a little more obscure, but I'm
not sure I see a fix for that. At least until KDE's tool finally
settles down for two releases in a row and we might be able to
simplify this whole thing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The 'desktop_pacakge_tool_update-kde-detected' needles and
'desktop_update_notification_systray-kde' needles are actually
matching on exactly the same thing, so drop the redundancy. We
need to have the desktop_package_tool_update tag on the older
(F33) version of this needle because on F33 we click on it to
launch the update tool in the desktop_update_graphical test; from
F34 onwards this is *not* what we want to do so the needle should
not have that tag to avoid throwing the test off. When F33 goes
EOL we can drop that tag from the needle and simplify the
destop_update_graphical test. Also add a needle for the Discover
app's 'update' icon when no updates are found.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Had some repeated failures where there's kind of a race between
Software doing some kind of auto-refresh and the test clicking
on stuff. This seems to help.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Man, this thing can get into a lot of states. Apparently somehow
it can go straight from refresh to reboot?
Signed-off-by: Adam Williamson <awilliam@redhat.com>
KDE update was still often failing on #1943943, so this tries a
bit harder to work around it. We add a 'refresh' needle for KDE,
and tweak the 'retry' logic to click it if we get to that point.
Note adding the needle also changes behaviour slightly - we may
click this needle if we see it on first entering the screen. So
either change may be helping. Either way, this does make the test
more reliable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Sometimes we click the button, it cycles briefly, and...just
comes back. To avoid unpredictable failures on update tests that
have nothing to do with the update, let's try and handle this by
just clicking it till it works.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We need to hit 'restart' after applying updates, and we also
need the 'done' needle *not* to match the restart message, so
change that to match on the text (unfortunately). That also
means we have to add another variant of the needle for F32 as
the background of the text is a different color there.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This gives apply and download longer to show up (which is an
issue for KDE right now) while also not waiting 10 seconds if
they don't.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds a test for QA:Testcase_Anaconda_User_Interface_VNC -
the VNC install test case. It's implemented as a server/client
pair, with the server booting from the Server DVD image with
`inst.vnc` and the client booting from the desktop base disk
image, setting up networking, then running Boxes to connect to
the server and run the install.
There are various little tweaks to test loading and logic to
handle this, mostly pretty clear. We also move the workaround
for 'spurious auth prompt appears on desktop after you switch
away to a VT and back' out of the desktop update test and into
the `desktop_vt` helper function, since now this test can hit
it as well. We enhance _graphical_wait_login to handle the boot
loader if needed (it has never needed to until now).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There are three places where we basically want to click away
pop-up update notifications and the buggy akonadi_migration_agent
notification if it's there, in KDE tests. Let's share this code
between them, and also let's record soft failures for the buggy
cases in the desktop_notifications test.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The way KDE does update notifications has changed - it's now a
permanent pop-up notification. This is a bit awkward for our
logic; it's hard to define a needle that proves this pop-up is
the only notification. Instead, let's dismiss it, then open the
notification tray and assert that there aren't any others. But
we also retain the old behaviour (more or less) for testing old
releases.
The popup notification also blocks the 'refresh' needle in the
systray and so breaks the desktop update test, so we deal with
that too.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
So, turns out new os-autoinst does *not* still accept the old
argument style for assert_and_click...and old os-autoinst
doesn't accept the new one. This adds a wrapper that handles
both, so our tests can work with old and new os-autoinst. We can
drop this once both deployments are on newer os-autoinst.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In the new os-autoinst I just sent to staging, the old style
doesn't work any more, breaks all tests. This style should also
work with the older os-autoinst on stable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It seems that when this problem happens now we get *two* auth
requests, so we need to handle that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In the last few weeks Boxes is showing an auth dialog on start.
I've filed a bug on this; let's have the test handle it as a
soft failure, since this isn't a fatal problem. Do this by
making an existing needle for this dialog a bit more generic
in name and using it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're getting a spurious "Authentication required" for a
background refresh of the system repos sometimes, depending on
whether it happens while we're at a tty. This is now accepted
by upstream, so let's handle it and make it a soft failure for
now.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It seems Rawhide auto-signing is working fine now: openQA claims
this needle has 'never' been matched (which really means 'not
for a long time'), and I can't find any test fail in the last
year which looks like it landed on this 'authenticate' screen
but the needle failed to match, or anything like that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
https://openqa.stg.fedoraproject.org/tests/424393 is a failure
where the 'Download' [updates] button was already visible when
we went to the tab. We already checked whether an 'apply' button
is visible and skipped the 'refresh' click if so, but because
the 'download' button is a new thing, we weren't skipping the
'refresh' click if 'download' was already visible.
So in this case, even though we could already see 'download', we
went ahead and clicked 'refresh'...then *immediately* started
looking for 'download'. It seems that Software did not refresh
and remove the 'Download' button *immediately* when we pressed
'refresh' - it left the 'Download' button visible briefly, and
*in this brief window*, we clicked it. *Then* Software kinda
'noticed' we'd clicked 'Update', and it seems it just sort of
throws away our click on 'Download' at that point and does the
refresh.
So at that point, the test thinks it's clicked 'Download' and
expects to see 'Apply', but actually the 'Download' click got
more or less thrown away, so the test fails, sitting at the
'Download' button.
To solve this, let's just extend the existing check to skip the
'refresh' click if 'download' *or* 'apply' are already visible.
There is a sort of possibility here that we could wind up
downloading and installing some updates that existed and were
noticed *before* we did our python3-kickstart trick, but not
install the python3-kickstart update, and cause the test to fail
because of that, but that doesn't seem to have happened before
when we were seeing the 'update' button, so I think I'm not
going to borrow trouble. If it happens, we'll deal with it I
guess.
The comment talks only about KDE, but clearly it can be the case
that an automatic check makes the button visible on GNOME too,
so let's rewrite the comment too.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The fix for this bug was sent to all releases now, so we should
not need the workaround any more. Let's kill it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The previous commit would lead to the 'workaround' getting hit
incorrectly, and might have had some other issues...tweak it a
bit.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
GNOME Software 3.30.5 split the offline update process into two
separate 'download' and 'apply' phases. So we need to handle
clicking 'download' before 'apply', if that happens.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
On F27 we don't get a 'Software is up to date' screen because
there's an upgrade available. Let's work with the refresh button
instead.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're not seeing *exactly* #1314991 any more, but we're seeing
something that looks quite similar: the first attempt to find
updates just doesn't find any. No error message, no updates. I
have reported a bug for this and am investigating it, in the
meantime, let's restore the workaround, elaborated a bit, and
looking for the 'Software is up to date' screen instead of the
error message.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I rather suspect the *bug* is still basically present and it's
why this test often fails, but we no longer seem to see the
*error message* which lets us detect the bug happening. This
needle has not been hit by any test for six months. So let's
remove the workaround as it adds complexity.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We do the 'desktop update' test for KDE via the notification
icon thingy, and it behaves differently depending on whether it
has already detected there are updates or not. The test only
works at present in the case where it *hasn't* - it expects the
notification icon to be in the extended panel and it expects to
see a 'refresh' button, neither of which is the case if it's
already noticed there are updates to install.
We should also force PackageKit to update its list of available
updates after we set up our 'special' update, otherwise on this
path KDE will only install the updates it found *before* we did
our stuff, and the test will fail as our special update won't be
there.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The default action on the reboot confirmation dialog changed
from Reboot to Cancel, so when we hit enter, we just cancel the
reboot. Tweak this to hit tab on F27+ (but not <F26, so update
tests continue to work too).
