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;
|
2016-09-20 22:32:44 +00:00
|
|
|
# use a tty console for repo config and package prep
|
2022-07-28 20:32:57 +00:00
|
|
|
$self->root_console(tty => 3);
|
2023-06-20 10:41:52 +00:00
|
|
|
disable_updates_repos;
|
2022-12-17 07:22:20 +00:00
|
|
|
# for update tests, disable koji-rawhide at this point, otherwise
|
|
|
|
# gnome-software will complain about things being unsigned even
|
|
|
|
# though the repo has gpgcheck=0
|
|
|
|
if (get_var("ADVISORY_OR_TASK") && get_var("VERSION") eq get_var("RAWREL")) {
|
2023-06-20 10:41:52 +00:00
|
|
|
assert_script_run 'sed -i -e "s,enabled=1,enabled=0,g" /etc/yum.repos.d/koji-rawhide.repo';
|
2022-12-17 07:22:20 +00:00
|
|
|
}
|
2023-03-18 16:39:19 +00:00
|
|
|
prepare_test_packages;
|
2016-09-20 22:32:44 +00:00
|
|
|
# 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
|
|
|
|
if ($desktop eq 'kde') {
|
2024-05-03 21:22:59 +00:00
|
|
|
# try and avoid double-typing issues, same way we do
|
|
|
|
# for apps_startstop test
|
|
|
|
wait_screen_change { send_key 'super'; };
|
|
|
|
wait_still_screen 3;
|
|
|
|
send_key "k";
|
|
|
|
wait_still_screen 5;
|
|
|
|
send_key "esc";
|
2022-05-16 23:04:33 +00:00
|
|
|
menu_launch_type('discover');
|
2022-07-04 17:07:13 +00:00
|
|
|
# Wait for it to run and maximize it to make sure we see the
|
|
|
|
# Updates entry
|
|
|
|
assert_screen('discover_runs');
|
|
|
|
wait_still_screen 2;
|
2022-07-08 22:58:11 +00:00
|
|
|
wait_screen_change { send_key "super-pgup"; };
|
|
|
|
wait_still_screen 2;
|
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
|
|
|
}
|
2023-01-09 18:34:27 +00:00
|
|
|
# GNOME Software 44+ has a 3rd party source pop-up, 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_ignore', 10) {
|
2024-02-16 20:50:05 +00:00
|
|
|
# keep clicking till we hit it, it tends to wobble around,
|
|
|
|
# especially with GNOME 46 - part of
|
|
|
|
# https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2442
|
|
|
|
click_lastmatch;
|
2024-05-27 19:17:40 +00:00
|
|
|
wait_still_screen 2;
|
2024-02-16 20:50:05 +00:00
|
|
|
my $count = 20;
|
|
|
|
while (check_screen 'gnome_software_ignore', 3) {
|
|
|
|
die "couldn't get rid of ignore screen!" if ($count == 0);
|
|
|
|
$count -= 1;
|
|
|
|
click_lastmatch;
|
2024-05-27 19:17:40 +00:00
|
|
|
wait_still_screen 2;
|
2024-02-16 20:50:05 +00:00
|
|
|
}
|
2016-09-20 22:32:44 +00:00
|
|
|
}
|
2022-05-16 23:04:33 +00:00
|
|
|
# go to the 'update' interface. We may be waiting some time at a
|
|
|
|
# 'Software catalog is being loaded' screen.
|
2022-07-28 20:32:57 +00:00
|
|
|
for my $n (1 .. 5) {
|
2022-05-16 23:04:33 +00:00
|
|
|
last if (check_screen 'desktop_package_tool_update', 120);
|
|
|
|
mouse_set 10, 10;
|
|
|
|
mouse_hide;
|
2016-09-20 22:32:44 +00:00
|
|
|
}
|
2024-02-16 20:50:05 +00:00
|
|
|
if ($desktop eq 'gnome') {
|
|
|
|
# wait for it to settle, it seems to take a long time and sometimes
|
|
|
|
# go into 'app is not responding' mode - part of
|
|
|
|
# https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2442
|
|
|
|
wait_still_screen 10;
|
|
|
|
# try to click in a 'neutral' area of the UI to get rid of the
|
|
|
|
# weird 'short window' state - another part of
|
|
|
|
# https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2442
|
|
|
|
mouse_set 36, 128;
|
|
|
|
mouse_click;
|
|
|
|
}
|
2016-09-20 22:32:44 +00:00
|
|
|
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;
|
2022-03-18 18:15:10 +00:00
|
|
|
# we always want to refresh to make sure we get the prepared update
|
2022-07-28 20:32:57 +00:00
|
|
|
assert_and_click 'desktop_package_tool_update_refresh', timeout => 120;
|
2022-03-18 18:53:34 +00:00
|
|
|
# for GNOME, the apply/download buttons remain visible for a long
|
|
|
|
# time, annoyingly. So let's actually watch the 'refreshing' state
|
|
|
|
# till it goes away
|
|
|
|
if ($desktop eq 'gnome') {
|
|
|
|
assert_screen 'desktop_package_tool_update_refreshing';
|
|
|
|
# now wait for it to go away
|
2022-07-28 20:32:57 +00:00
|
|
|
for my $n (1 .. 30) {
|
2022-03-18 18:53:34 +00:00
|
|
|
last unless (check_screen 'desktop_package_tool_update_refreshing', 6);
|
|
|
|
# if we matched, we likely matched *immediately*, so sleep
|
|
|
|
# the other five seconds
|
|
|
|
sleep 5;
|
|
|
|
}
|
|
|
|
sleep 3;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
# just wait a bit to make sure the UI clears to a 'refreshing'
|
|
|
|
# state
|
|
|
|
sleep 5;
|
|
|
|
}
|
|
|
|
|
2023-04-27 00:41:25 +00:00
|
|
|
my $tags = ['desktop_package_tool_update_download', 'desktop_package_tool_update_apply']; # testtag
|
|
|
|
|
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,
|
2022-03-18 18:15:10 +00:00
|
|
|
# or 'download' then 'apply'
|
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; };
|
2022-03-18 18:15:10 +00:00
|
|
|
$n -= 1 if ($n > 1);
|
2024-06-11 21:38:18 +00:00
|
|
|
if (get_var("TAG") || get_var("COPR")) {
|
|
|
|
# we might get a 'download unsigned software' prompt
|
|
|
|
# https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2246
|
|
|
|
click_lastmatch if (check_screen "desktop_package_tool_update_download_unsigned", 30);
|
|
|
|
}
|
2020-11-03 00:34:43 +00:00
|
|
|
$tags = ['desktop_package_tool_update_apply'];
|
|
|
|
next;
|
2018-10-11 23:05:38 +00:00
|
|
|
}
|
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)
|
2024-06-11 21:38:18 +00:00
|
|
|
if (get_var("TAG") || get_var("COPR")) {
|
|
|
|
# we might get a 'download unsigned software' prompt
|
|
|
|
# https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2246
|
|
|
|
click_lastmatch if (check_screen "desktop_package_tool_update_download_unsigned", 5);
|
|
|
|
}
|
2016-09-20 22:32:44 +00:00
|
|
|
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
|
|
|
}
|
2022-05-16 23:07:59 +00:00
|
|
|
elsif ($desktop eq 'kde') {
|
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
|
|
|
# back to console to verify updates
|
2022-07-28 20:32:57 +00:00
|
|
|
$self->root_console(tty => 3);
|
2023-03-18 16:39:19 +00:00
|
|
|
verify_updated_packages;
|
2016-09-20 22:32:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
sub test_flags {
|
2022-07-28 20:32:57 +00:00
|
|
|
return {fatal => 1};
|
2016-09-20 22:32:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
1;
|
|
|
|
|
|
|
|
# vim: set sw=4 et:
|