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>
This commit is contained in:
Adam Williamson 2018-10-11 16:05:38 -07:00
parent 25ad8a6aeb
commit db4ab638da
3 changed files with 37 additions and 1 deletions

View File

@ -0,0 +1,16 @@
{
"area": [
{
"ypos": 366,
"type": "match",
"width": 91,
"height": 77,
"xpos": 471
}
],
"properties": [],
"tags": [
"DESKTOP-gnome",
"desktop_package_tool_uptodate"
]
}

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

View File

@ -46,7 +46,27 @@ sub run {
# refresh updates
assert_and_click 'desktop_package_tool_update_refresh', '', 120;
}
for my $n (1..5) {
# wait for refresh, then apply updates, using a C-style loop so we
# can reset it if needed due to RHBZ #1314991. We will retry a max
# of two times if we hit refresh and wind up being told the system
# is up to date.
my $retries = 2;
for (my $n = 1; $n < 6; $n++) {
# TEST TEST Check if refresh completes and g-s thinks we're
# up-to-date, if so, refresh and restart the loop
if (check_screen 'desktop_package_tool_uptodate', 1) {
if ($retries == 2) {
record_soft_failure "Refresh did not find available update - #1638563. Retrying";
}
if ($retries > 0) {
assert_and_click 'desktop_package_tool_update_refresh';
$n = 1;
}
else {
die "Retried refresh too many times, giving up";
}
$retries -= 1;
}
last if (check_screen 'desktop_package_tool_update_apply', 120);
mouse_set 10, 10;
mouse_hide;