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

122 lines
4.6 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') {
# if the permanent pop-up notification appeared, get rid of
# it, as it blocks the refresh button...
if (check_screen "desktop_update_notification_popup", 10) {
assert_and_click "desktop_update_notification_popup";
}
# KDE team tells me the 'preferred' update method is the
# systray applet
assert_and_click 'desktop_expand_systray';
}
else {
# work around https://gitlab.gnome.org/GNOME/gnome-software/issues/582
# if it happens
if (check_screen "auth_required", 10) {
record_soft_failure "spurious 'auth required' - https://gitlab.gnome.org/GNOME/gnome-software/issues/582";
# bit sloppy but correct for both...
type_very_safely "weakpassword\n";
# as of 2019-04 when we hit this bug it seems to ask for
# auth *twice*, so handle that
sleep 3;
if (check_screen "auth_required", 1) {
type_very_safely "weakpassword\n";
}
}
# this launches GNOME Software on GNOME, dunno for any other
# desktop yet
sleep 3;
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';
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
unless (check_screen ['desktop_package_tool_update_apply', 'desktop_package_tool_update_download'], 5) {
# refresh updates
_assert_and_click('desktop_package_tool_update_refresh', timeout=>120);
}
# wait for refresh, then 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'.
my $tags = ['desktop_package_tool_update_download', 'desktop_package_tool_update_apply'];
for (my $n = 1; $n < 6; $n++) {
if (check_screen $tags, 120) {
# if we see 'apply', we're done here, quit out of the loop
last if (match_has_tag 'desktop_package_tool_update_apply');
# if we see 'download', we're in the GNOME Software 3.30.5+
# two-step process - let's hit it, and continue waiting for
# for apply (only)
if (match_has_tag 'desktop_package_tool_update_download') {
wait_screen_change { assert_and_click 'desktop_package_tool_update_download'; };
$n -= 1 if ($n > 1);
$tags = ['desktop_package_tool_update_apply'];
next;
}
}
# move the mouse to stop the screen blanking on idle
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) {
send_key 'tab';
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 {
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: