srbala/os-autoinst-distri-fedora
1
0
Fork 0
mirror of https://pagure.io/fedora-qa/os-autoinst-distri-fedora.git synced 2024-11-25 23:33:07 +00:00
Code Issues Releases Activity

desktop_update_graphical: always refresh

Browse Source 
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>
This commit is contained in:
Adam Williamson 2022-03-18 11:15:10 -07:00
parent 7d62f3b48e
commit b17fd9c3fe
1 changed files with 6 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
tests/desktop_update_graphical.pm
View File

@ -57,15 +57,15 @@ sub run {
assert_and_click 'desktop_package_tool_update'; assert_and_click 'desktop_package_tool_update';
# wait for things to settle if e.g. GNOME is refreshing # wait for things to settle if e.g. GNOME is refreshing
wait_still_screen 5, 90; wait_still_screen 5, 90;
# depending on automatic update checks, 'apply' or 'download' may # we always want to refresh to make sure we get the prepared update
# already be visible at this point, we may not need to refresh assert_and_click 'desktop_package_tool_update_refresh', timeout=>120;
assert_screen ['desktop_package_tool_update_apply', 'desktop_package_tool_update_download', 'desktop_package_tool_update_refresh'], 120; # wait a bit to make sure the UI clears to a 'refreshing' state
sleep 5;
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 # Apply updates, moving the mouse every two minutes to avoid the
# idle screen blank kicking in. Depending on whether this is KDE # idle screen blank kicking in. Depending on whether this is KDE
# or GNOME and what Fedora release, we may see 'apply' right away, # or GNOME and what Fedora release, we may see 'apply' right away,
# or 'download' then 'apply', or we may only see 'refresh' and # or 'download' then 'apply'
# 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
@ -73,17 +73,10 @@ sub run {
# if we see 'download', let's hit it, and continue waiting # if we see 'download', let's hit it, and continue waiting
# for apply (only) # for apply (only)
wait_screen_change { click_lastmatch; }; wait_screen_change { click_lastmatch; };
$n -= 1 if ($n > 2); $n -= 1 if ($n > 1);
$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;