testing/os-autoinst-distri-rocky-migrated
10
0
Fork 0
Code Issues 12 Pull Requests 1 Packages Projects Releases Wiki Activity

Tweak the desktop update loop again to try and be more robust

Browse Source 
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>
This commit is contained in:
Adam Williamson 2021-06-29 10:53:37 -07:00
parent 4553a9e43b
commit bc611d6975
1 changed files with 14 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
tests/desktop_update_graphical.pm
View File

@ -60,24 +60,30 @@ sub run {
# depending on automatic update checks, 'apply' or 'download' may # depending on automatic update checks, 'apply' or 'download' may
# already be visible at this point, we may not need to refresh # already be visible at this point, we may not need to refresh
assert_screen ['desktop_package_tool_update_apply', 'desktop_package_tool_update_download', 'desktop_package_tool_update_refresh'], 120; assert_screen ['desktop_package_tool_update_apply', 'desktop_package_tool_update_download', 'desktop_package_tool_update_refresh'], 120;
click_lastmatch if (match_has_tag "desktop_package_tool_update_refresh");
# wait for refresh, then apply updates, moving the mouse every two
# minutes to avoid the idle screen blank kicking in. Depending on
# whether this is KDE or GNOME and what Fedora release, we may see
# 'apply' right away, or 'download' then 'apply'.
my $tags = ['desktop_package_tool_update_download', 'desktop_package_tool_update_apply']; my $tags = ['desktop_package_tool_update_download', 'desktop_package_tool_update_apply'];
# Apply updates, moving the mouse every two minutes to avoid the
# idle screen blank kicking in. Depending on whether this is KDE
# or GNOME and what Fedora release, we may see 'apply' right away,
# or 'download' then 'apply', or we may only see 'refresh' and
# need to click it first
for (my $n = 1; $n < 6; $n++) { for (my $n = 1; $n < 6; $n++) {
if (check_screen $tags, 120) { if (check_screen $tags, 120) {
# if we see 'apply', we're done here, quit out of the loop # if we see 'apply', we're done here, quit out of the loop
last if (match_has_tag 'desktop_package_tool_update_apply'); last if (match_has_tag 'desktop_package_tool_update_apply');
# if we see 'download', we're in the GNOME Software 3.30.5+ # if we see 'download', let's hit it, and continue waiting
# two-step process - let's hit it, and continue waiting for
# for apply (only) # for apply (only)
wait_screen_change { click_lastmatch; }; wait_screen_change { click_lastmatch; };
$n -= 1 if ($n > 1); $n -= 1 if ($n > 2);
$tags = ['desktop_package_tool_update_apply']; $tags = ['desktop_package_tool_update_apply'];
next; next;
} }
elsif ($n == 1) {
# if we're in the first iteration of this loop and we can't
# see apply or download, that means we can only see refresh
# and should click it
click_lastmatch;
sleep 2;
}
# move the mouse to stop the screen blanking on idle # move the mouse to stop the screen blanking on idle
mouse_set 10, 10; mouse_set 10, 10;
mouse_hide; mouse_hide;