os-autoinst-distri-rocky/tests/desktop_update_graphical.pm

108 lines
4.0 KiB
Perl
Raw Normal View History

use base "installedtest";
use strict;
use testapi;
use utils;
use packagetest;
sub run {
my $self = shift;
my $desktop = get_var('DESKTOP');
# 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
desktop_vt;
# run the updater
if ($desktop eq 'kde') {
# KDE team tells me the 'preferred' update method is the
# systray applet
assert_and_click 'desktop_expand_systray';
}
else {
# this launches GNOME Software on GNOME, dunno for any other
# desktop yet
menu_launch_type('update');
}
# 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';
}
# go to the 'update' interface. For GNOME, we may be waiting
# some time at a 'Software catalog is being loaded' screen.
if ($desktop eq 'gnome') {
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';
# if this is KDE and it had already noticed the notification, we
# will already have the apply button at this point
unless (check_screen 'desktop_package_tool_update_apply', 5) {
# refresh updates
assert_and_click 'desktop_package_tool_update_refresh', '', 120;
}
# wait for refresh, then apply updates, using a C-style loop so we
# can reset it if needed due to RHBZ #1314991
for (my $n = 1; $n < 6; $n++) {
# Check if we see the 'cancelled by user action' error we get
# when #1314991 happens, if so, refresh and restart the loop
if (check_screen 'desktop_package_tool_update_bz1314991', 1) {
record_soft_failure "RHBZ #1314991 (background PK operation interfered with update)";
assert_and_click 'desktop_package_tool_update_refresh';
$n = 1;
}
last if (check_screen 'desktop_package_tool_update_apply', 120);
mouse_set 10, 10;
mouse_hide;
}
# KDE annoyingly pops the notification up right over the install
# button, which doesn't help...wait for it to go away. Let's also
# wait on GNOME, as we've had tests fail at this point for no
# obvious reason, a wait may help.
wait_still_screen 5;
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) {
# on F27+, default is Cancel, earlier, default is Restart
my $version = lc(get_var("VERSION"));
send_key 'tab' if ($version eq 'rawhide' || $version > 26);
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;
}
else {
# KDE will prompt for authentication if any package is not
# signed. As of 2016-09-23, puiterwijk claims Rawhide packages
# will be autosigned 'by Monday', so if this happens, we're
# going to treat it as a soft fail, indicating the update
# mechanism works, but a package that should have been signed
# was not.
assert_screen ['desktop_package_tool_update_done', 'desktop_package_tool_update_authenticate'], 180;
if (match_has_tag('desktop_package_tool_update_authenticate')) {
record_soft_failure;
type_very_safely get_var('USER_PASSWORD', 'weakpassword');
send_key 'ret';
assert_screen 'desktop_package_tool_update_done', 180;
}
}
# 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: