1
0
mirror of https://pagure.io/fedora-qa/os-autoinst-distri-fedora.git synced 2024-12-05 03:23:09 +00:00
Commit Graph

55 Commits

Author SHA1 Message Date
Adam Williamson
1a65993d36 Add a perltidy check and apply it to the entire codebase
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-28 14:38:38 -07:00
Adam Williamson
14942f86e7 Some safety around Discover maximize in desktop_update_graphical
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-08 15:58:11 -07:00
Adam Williamson
cf969061ce Wait for Discover to run before maximizing it
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-04 10:07:13 -07:00
Adam Williamson
be39c0e3a1 desktop_update_graphical: maximize Discover on launch
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>
2022-07-04 09:47:56 -07:00
Adam Williamson
375c7409af Drop another unnecessary release number condition
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-05-16 16:07:59 -07:00
Adam Williamson
a22d3b28b6 Drop a pre-F34 path for launching update tool on KDE
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>
2022-05-16 16:04:33 -07:00
Adam Williamson
06c66dcd30 desktop_update_graphical: explicitly check refresh on GNOME
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>
2022-03-18 13:51:33 -07:00
Adam Williamson
4dab8520b0 Bump the wait after hitting the Refresh button
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>
2022-03-18 11:24:07 -07:00
Adam Williamson
b17fd9c3fe desktop_update_graphical: always refresh
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>
2022-03-18 11:15:10 -07:00
Adam Williamson
bc611d6975 Tweak the desktop update loop again to try and be more robust
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>
2021-06-29 10:53:37 -07:00
Adam Williamson
0b45cd4adc Try and clean up desktop update needles a bit
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>
2021-06-14 12:32:27 -07:00
Adam Williamson
5d4cf014a2 Add a wait_still_screen to desktop_update_graphical for safety
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>
2021-05-28 15:04:37 -07:00
Adam Williamson
b9df4c4671 More fiddling with this goddamn KDE logic loop
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>
2021-03-30 12:50:32 -07:00
Adam Williamson
16ded56935 Add KDE package refresh needle, tweak retry logic a bit
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>
2021-03-30 12:27:34 -07:00
Adam Williamson
075d479b58 Note the bug number for the Plasma Discover problem
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-03-28 09:51:43 -07:00
Adam Williamson
e25ffe2f05 Try to handle KDE 'apply updates' button not always working
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>
2021-03-28 08:56:27 -07:00
Adam Williamson
1fc2edfda4 Fix desktop update test for KDE in F34+
We now have to run Plasma Discover, not use the systray thing.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-03-27 23:44:12 -07:00
Adam Williamson
e1a6d2c22b Handle KDE defaulting to offline updates in F34+
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>
2021-02-25 16:10:20 -08:00
Adam Williamson
de36bd2d12 Tweak desktop update matching logic
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>
2021-02-25 14:33:17 -08:00
Adam Williamson
5652b62484 Wait a bit longer for desktop_package_tool_update_apply
In current KDE we get it on start of the tool, but only after a
few more seconds...

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-30 10:46:16 -08:00
Adam Williamson
a5c0f7ffbb Enable several desktop tests on Workstation aarch64 disk image
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-04 11:55:33 -08:00
Adam Williamson
fc93309b41 Drop _assert_and_click shim
We're on newer code on both deployments now, no longer needed.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-10 14:22:20 -08:00
Adam Williamson
b82a1dec6f Add test for QA:Testcase_Anaconda_User_Interface_VNC
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>
2019-11-05 14:46:10 -08:00
Adam Williamson
25f408ea7e Factor out clicking of update and akonadi notifications in KDE
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>
2019-07-17 09:02:24 -07:00
Adam Williamson
dfce3e522d desktop_update: handle multiple KDE update available notifications
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-07-10 12:37:26 -07:00
Adam Williamson
7953fb91d1 Try to handle spurious 'auth required' on KDE update test too
Sigh, now *this* is showing up in KDE too. Fun.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-05-30 17:54:27 -07:00
Adam Williamson
2e56facb68 Try to handle changes to KDE update notifications in Rawhide
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>
2019-05-30 17:34:09 -07:00
Adam Williamson
43b990195c Add a wrapper around assert_and_click to handle signature change
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>
2019-05-28 09:41:33 -07:00
Adam Williamson
87456f6b1d Use new arg style for assert_and_click
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>
2019-05-27 14:28:17 -07:00
Adam Williamson
6c22b55be5 Drop another part of branched buildroot repo workaround
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-05-01 13:49:18 -07:00
Adam Williamson
ccb67bd5a7 Extend gnome-software/issues/582 workaround to 2 auth requests
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>
2019-04-17 10:32:04 -07:00
Adam Williamson
dc81c64f4f Use type_very_safely for the desktop auth workaround
type_safely just ain't safe enough, it seems.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-04-10 12:46:45 -07:00
Adam Williamson
e396341f31 Handle 'authentication required' appearing on Boxes startup
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>
2019-03-26 12:30:47 -07:00
Adam Williamson
d6c339e9ff Disable the 'f30-build' repo for the desktop update test
...GNOME Software doesn't like it.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-03-06 19:51:09 -08:00
Adam Williamson
5cbc7df810 Work around GGO gnome-software/582 till it's fixed
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>
2019-02-07 09:58:10 -08:00
Adam Williamson
3d35ec9670 Update a comment to not mention a removed workaround
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-12-17 14:36:10 -08:00
Adam Williamson
ef3555aaa1 Drop another old workaround (KDE package signature check)
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>
2018-12-17 12:24:09 -08:00
Adam Williamson
1fd0097d1d Simplify an 'if >F26' thing
We don't care about anything older than 27 any more.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-12-17 12:19:44 -08:00
Adam Williamson
d1e7b89efd Fix a potential race in desktop update test
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>
2018-12-17 12:10:06 -08:00
Adam Williamson
517750443e Remove RHBZ #1638563 workaround
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>
2018-12-17 12:02:57 -08:00
Adam Williamson
70ef3404f0 Tweak previous commit to avoid some bugs
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>
2018-10-31 12:45:11 -07:00
Adam Williamson
fd753b2e3a Handle split of 'download' and 'apply' phases in gnome-software
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>
2018-10-31 11:50:14 -07:00
Adam Williamson
17b6d9f708 Tweak the workaround to work for F27 too
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>
2018-10-11 22:23:53 -07:00
Adam Williamson
63d8f34a0e Tweak the workaround loop a bit, refresh the comments
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-11 16:18:04 -07:00
Adam Williamson
db4ab638da Restore modified version of the #1314991 workaround for #1638563
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>
2018-10-11 16:07:58 -07:00
Adam Williamson
25ad8a6aeb Drop workaround for #1314991, it doesn't work any more
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>
2018-10-10 13:45:51 -07:00
Adam Williamson
acc4ccd7cc Add a sleep to desktop_update_graphical
Try and avoid failure to launch alt-f1 dialog...

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-07-30 11:23:59 -07:00
Adam Williamson
baa7ac4e39 Handle KDE update test when KDE has aleady found updates
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>
2018-03-28 19:53:19 -07:00
Adam Williamson
4323d8f533 Fix desktop_update_graphical for recent F27+ GNOME change
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).
2017-10-19 12:46:40 -07:00
Adam Williamson
99a203b8e0 Catch RHBZ #1314991 and handle it, with a soft failure
We can deal with this annoying bug by looking out for the error
we see when it happens, hitting the 'refresh' button again, and
resetting the loop counter to 1 (requires changing the loop to
a C-style loop).
2017-09-06 14:19:37 -07:00