2016-09-20 22:32:44 +00:00
|
|
|
use base "installedtest";
|
|
|
|
use strict;
|
|
|
|
use testapi;
|
2017-01-18 07:15:44 +00:00
|
|
|
use utils;
|
2016-09-20 22:32:44 +00:00
|
|
|
use packagetest;
|
|
|
|
|
|
|
|
sub run {
|
|
|
|
my $self = shift;
|
|
|
|
my $desktop = get_var('DESKTOP');
|
2021-02-25 22:54:00 +00:00
|
|
|
my $relnum = get_release_number;
|
2022-07-10 21:05:04 +00:00
|
|
|
my $version_major = get_version_major;
|
2016-09-20 22:32:44 +00:00
|
|
|
# use a tty console for repo config and package prep
|
|
|
|
$self->root_console(tty=>3);
|
|
|
|
assert_script_run 'dnf config-manager --set-disabled updates-testing';
|
|
|
|
prepare_test_packages;
|
|
|
|
# get back to the desktop
|
2016-09-24 19:42:39 +00:00
|
|
|
desktop_vt;
|
2019-05-31 00:52:51 +00:00
|
|
|
|
2016-09-20 22:32:44 +00:00
|
|
|
# run the updater
|
2021-06-14 19:27:20 +00:00
|
|
|
# FIXME: when F33 goes EOL, remove all the KDE < F34 stuff below
|
|
|
|
# and drop 'desktop_package_tool_update' tag from
|
|
|
|
# desktop_update_notification_systray-kde-20200929.json
|
2016-09-20 22:32:44 +00:00
|
|
|
if ($desktop eq 'kde') {
|
2021-03-27 22:01:31 +00:00
|
|
|
# KDE team tells me until F34 the 'preferred' update method
|
|
|
|
# was the systray applet...
|
2022-07-10 21:05:04 +00:00
|
|
|
if (($relnum < 34) || ($version_major < 9)) {
|
2021-03-27 22:01:31 +00:00
|
|
|
# get rid of notifications which get in the way of the things
|
|
|
|
# we need to click
|
|
|
|
click_unwanted_notifications;
|
|
|
|
assert_and_click 'desktop_expand_systray';
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
# ...from F34 onwards, it's Plasma Discover app
|
|
|
|
menu_launch_type('discover');
|
|
|
|
}
|
2016-09-20 22:32:44 +00:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
# this launches GNOME Software on GNOME, dunno for any other
|
|
|
|
# desktop yet
|
2018-07-30 18:23:59 +00:00
|
|
|
sleep 3;
|
2017-01-18 07:15:44 +00:00
|
|
|
menu_launch_type('update');
|
2016-09-20 22:32:44 +00:00
|
|
|
}
|
|
|
|
# GNOME Software has a welcome screen, get rid of it if it shows
|
|
|
|
# up (but don't fail if it doesn't, we're not testing that)
|
|
|
|
if ($desktop eq 'gnome' && check_screen 'gnome_software_welcome', 10) {
|
|
|
|
send_key 'ret';
|
|
|
|
}
|
2021-03-27 22:01:31 +00:00
|
|
|
# go to the 'update' interface. For GNOME or KDE on F34+, we
|
|
|
|
# may be waiting some time at a 'Software catalog is being
|
|
|
|
# loaded' screen.
|
|
|
|
if ($desktop eq 'gnome' || ($desktop eq 'kde' && $relnum > 33)) {
|
2016-09-20 22:32:44 +00:00
|
|
|
for my $n (1..5) {
|
|
|
|
last if (check_screen 'desktop_package_tool_update', 120);
|
|
|
|
mouse_set 10, 10;
|
|
|
|
mouse_hide;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
assert_and_click 'desktop_package_tool_update';
|
2021-05-28 22:04:37 +00:00
|
|
|
# wait for things to settle if e.g. GNOME is refreshing
|
|
|
|
wait_still_screen 5, 90;
|
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 20:10:06 +00:00
|
|
|
# depending on automatic update checks, 'apply' or 'download' may
|
|
|
|
# already be visible at this point, we may not need to refresh
|
2021-02-25 22:33:17 +00:00
|
|
|
assert_screen ['desktop_package_tool_update_apply', 'desktop_package_tool_update_download', 'desktop_package_tool_update_refresh'], 120;
|
2018-12-17 20:02:57 +00:00
|
|
|
my $tags = ['desktop_package_tool_update_download', 'desktop_package_tool_update_apply'];
|
2021-06-29 17:53:37 +00:00
|
|
|
# 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
|
2018-10-11 23:05:38 +00:00
|
|
|
for (my $n = 1; $n < 6; $n++) {
|
2018-10-31 19:45:11 +00:00
|
|
|
if (check_screen $tags, 120) {
|
2018-10-11 23:18:04 +00:00
|
|
|
# if we see 'apply', we're done here, quit out of the loop
|
2018-10-31 18:43:00 +00:00
|
|
|
last if (match_has_tag 'desktop_package_tool_update_apply');
|
2021-06-29 17:53:37 +00:00
|
|
|
# if we see 'download', let's hit it, and continue waiting
|
2018-12-17 22:36:10 +00:00
|
|
|
# for apply (only)
|
2020-11-03 00:34:43 +00:00
|
|
|
wait_screen_change { click_lastmatch; };
|
2021-06-29 17:53:37 +00:00
|
|
|
$n -= 1 if ($n > 2);
|
2020-11-03 00:34:43 +00:00
|
|
|
$tags = ['desktop_package_tool_update_apply'];
|
|
|
|
next;
|
2018-10-11 23:05:38 +00:00
|
|
|
}
|
2021-06-29 17:53:37 +00:00
|
|
|
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;
|
|
|
|
}
|
2018-10-11 23:18:04 +00:00
|
|
|
# move the mouse to stop the screen blanking on idle
|
2016-09-20 22:32:44 +00:00
|
|
|
mouse_set 10, 10;
|
|
|
|
mouse_hide;
|
|
|
|
}
|
2021-03-28 15:56:27 +00:00
|
|
|
# Magic wait, clicking this right after the last click sometimes
|
|
|
|
# goes wrong
|
2017-03-02 23:33:23 +00:00
|
|
|
wait_still_screen 5;
|
2016-09-20 22:32:44 +00:00
|
|
|
assert_and_click 'desktop_package_tool_update_apply';
|
|
|
|
# on GNOME, wait for reboots.
|
|
|
|
if ($desktop eq 'gnome') {
|
|
|
|
# handle reboot confirm screen which pops up when user is
|
|
|
|
# logged in (but don't fail if it doesn't as we're not testing
|
|
|
|
# that)
|
|
|
|
if (check_screen 'gnome_reboot_confirm', 15) {
|
2018-12-17 20:19:44 +00:00
|
|
|
send_key 'tab';
|
2016-09-20 22:32:44 +00:00
|
|
|
send_key 'ret';
|
|
|
|
}
|
consolidate login waits, use postinstall not entrypoint for base
Summary:
I started out wanting to fix an issue I noticed today where
graphical upgrade tests were failing because they didn't wait
for the graphical login screen properly; the test was sitting
at the 'full Fedora logo' state of plymouth for a long time,
so the current boot_to_login_screen's wait_still_screen was
triggered by it and the function wound up failing on the
assert_screen, because it was still some time before the real
login screen appeared.
So I tweaked the boot_to_login_screen implementation to work
slightly differently (look for a login screen match, *then* -
if we're dealing with a graphical login - wait_still_screen
to defeat the 'old GPU buffer showing login screen' problem
and assert the login screen again). But while working on it,
I figured we really should consolidate all the various places
that handle the bootloader -> login, we were doing it quite
differently in all sorts of different places. And as part of
that, I converted the base tests to use POSTINSTALL (and thus
go through the shared _wait_login tests) instead of handling
boot themselves. As part of *that*, I tweaked main.pm to not
require all POSTINSTALL tests have the _postinstall suffix on
their names, as it really doesn't make sense, and renamed the
tests.
Test Plan: Run all tests, see if they work.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1015
2016-09-27 18:48:15 +00:00
|
|
|
boot_to_login_screen;
|
2016-09-20 22:32:44 +00:00
|
|
|
}
|
2021-02-25 22:54:00 +00:00
|
|
|
elsif ($desktop eq 'kde' && $relnum > 33) {
|
|
|
|
# KDE does offline updates now, we have to trigger the reboot
|
2021-03-28 16:51:43 +00:00
|
|
|
# FIXME: also sometimes the update apply button just doesn't
|
|
|
|
# work, so keep clicking till it does:
|
|
|
|
# https://bugzilla.redhat.com/show_bug.cgi?id=1943943
|
2021-03-28 15:56:27 +00:00
|
|
|
for my $n (1..10) {
|
|
|
|
sleep 2;
|
|
|
|
assert_screen ['kde_offline_update_reboot', 'desktop_package_tool_update_apply'];
|
|
|
|
# break out if we reached the reboot button
|
|
|
|
last if (match_has_tag 'kde_offline_update_reboot');
|
2021-03-30 19:50:32 +00:00
|
|
|
# otherwise, try refresh and apply or reboot
|
2021-03-30 19:27:34 +00:00
|
|
|
assert_and_click 'desktop_package_tool_update_refresh';
|
2021-03-30 19:50:32 +00:00
|
|
|
assert_screen ['kde_offline_update_reboot', 'desktop_package_tool_update_apply'];
|
|
|
|
last if (match_has_tag 'kde_offline_update_reboot');
|
|
|
|
click_lastmatch;
|
2021-03-28 15:56:27 +00:00
|
|
|
}
|
2021-02-25 22:54:00 +00:00
|
|
|
assert_and_click 'kde_offline_update_reboot';
|
|
|
|
boot_to_login_screen;
|
|
|
|
}
|
2016-09-20 22:32:44 +00:00
|
|
|
else {
|
2018-12-17 20:24:09 +00:00
|
|
|
assert_screen 'desktop_package_tool_update_done', 180;
|
2016-09-20 22:32:44 +00:00
|
|
|
}
|
|
|
|
# back to console to verify updates
|
|
|
|
$self->root_console(tty=>3);
|
|
|
|
verify_updated_packages;
|
|
|
|
}
|
|
|
|
|
|
|
|
sub test_flags {
|
|
|
|
return { fatal => 1 };
|
|
|
|
}
|
|
|
|
|
|
|
|
1;
|
|
|
|
|
|
|
|
# vim: set sw=4 et:
|