srbala/os-autoinst-distri-fedora
1
0
Fork 0
mirror of https://pagure.io/fedora-qa/os-autoinst-distri-fedora.git synced 2024-11-19 20:53:08 +00:00
Code Issues Releases Activity
1a1da8b33c
os-autoinst-distri-fedora/tests/desktop_update_graphical.pm

104 lines
3.8 KiB
Perl
Raw Normal View History

add a desktop_update_graphical test Summary: Very similar to the CLI update test, but using the desktops' update applications. This is based off the CLI update test branch as it uses the shared functions that branch introduced. We do not use the fake update packages, as they don't really do anything useful for these tests; for dnf they can help us distinguish between issues with the dnf mechanism and issues with the repos, but we can't really tell that in the graphical case. So we only use the python3-kickstart package here. Test Plan: Run the test on both KDE and GNOME and ensure it performs as intended. I've been testing it on staging, so you can see it there. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1010
2016-09-20 22:32:44 +00:00
use base "installedtest";
use strict;
use testapi;
Move all remaining utility functions into exporter modules Summary: This adds a couple of new exporter modules, renames main_common to utils (this is a better name: openSUSE's main_common is functions used in main.pm, utils is what they call their module full of miscellaneous commonly-used functions), and moves a bunch of utility functions that were previously needlessly implemented as instance methods in base classes into the exporter modules. That means we can get rid of all the annoying $self-> syntax for calling them. We get rid of `fedorabase` entirely, as it's no longer useful for anything. Other base classes keep the 'standard' methods (like `post_fail_hook`) and methods which actually need to be methods (like `root_console`, whose behaviour is different in anacondatest and installedtest). Test Plan: Do a full test suite run and check everything lines up. There should be no functional differences from before at all, this is just a re-org. Reviewers: jskladan, garretraziel_but_actually_jsedlak_who_uses_stupid_nicknames Reviewed By: garretraziel_but_actually_jsedlak_who_uses_stupid_nicknames Subscribers: tflink Differential Revision: https://phab.qa.fedoraproject.org/D1080
2017-01-18 07:15:44 +00:00
use utils;
add a desktop_update_graphical test Summary: Very similar to the CLI update test, but using the desktops' update applications. This is based off the CLI update test branch as it uses the shared functions that branch introduced. We do not use the fake update packages, as they don't really do anything useful for these tests; for dnf they can help us distinguish between issues with the dnf mechanism and issues with the repos, but we can't really tell that in the graphical case. So we only use the python3-kickstart package here. Test Plan: Run the test on both KDE and GNOME and ensure it performs as intended. I've been testing it on staging, so you can see it there. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1010
2016-09-20 22:32:44 +00:00
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
detect (rather than guessing) desktop vt use 'ps' output for Xorg and Xwayland. We'd need some new openQA var to get this right by 'guessing', as it's vt1 for Workstation when running live - so long as autologin worked - but vt2 after install. We'd need a var or some other thing to detect which case we're running in. LIVE doesn't do it, it's set even when running a post-install test from a live image. So instead let's just do it a bit more cleverly. This also gives us a bit of insurance against changes in GDM, SDDM etc. behaviour, so long as Xwayland or Xorg is running (and we can add additional processes to the list, like gnome-shell, if needed/appropriate). We assume the *final* listed process - i.e. the most recently-started one - will be the desktop; this covers gdm's behaviour of starting up on vt1 then running the user session on vt2. We can make this function more complex and add args if we ever get to the point where we have multi- user tests running or anything (e.g. allow to pass a username and only look for that user's processes). Landing without review as this broke the live variant of the test on Workstation in production (kinda not sure why it worked in testing, or I didn't notice that it failed, but never mind). I've tested it on staging.
2016-09-24 19:42:39 +00:00
desktop_vt;
add a desktop_update_graphical test Summary: Very similar to the CLI update test, but using the desktops' update applications. This is based off the CLI update test branch as it uses the shared functions that branch introduced. We do not use the fake update packages, as they don't really do anything useful for these tests; for dnf they can help us distinguish between issues with the dnf mechanism and issues with the repos, but we can't really tell that in the graphical case. So we only use the python3-kickstart package here. Test Plan: Run the test on both KDE and GNOME and ensure it performs as intended. I've been testing it on staging, so you can see it there. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1010
2016-09-20 22:32:44 +00:00
# run the updater
if ($desktop eq 'kde') {
# KDE team tells me the 'preferred' update method is the
# systray applet
add a desktop notifications test Summary: this more or less covers desktop_error_checks and desktop_ update_notification, though it can't really distinguish between them easily. All we know is that if both the live and postinstall versions of this test pass, both of those tests pass. Any fails will have to be investigated manually. Test Plan: Run the tests for both KDE and Workstation, see what happens. Workstation will fail for F25 and Rawhide at present, due to SELinux/abrt notifications. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1004
2016-09-23 23:03:13 +00:00
assert_and_click 'desktop_expand_systray';
add a desktop_update_graphical test Summary: Very similar to the CLI update test, but using the desktops' update applications. This is based off the CLI update test branch as it uses the shared functions that branch introduced. We do not use the fake update packages, as they don't really do anything useful for these tests; for dnf they can help us distinguish between issues with the dnf mechanism and issues with the repos, but we can't really tell that in the graphical case. So we only use the python3-kickstart package here. Test Plan: Run the test on both KDE and GNOME and ensure it performs as intended. I've been testing it on staging, so you can see it there. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1010
2016-09-20 22:32:44 +00:00
}
else {
# this launches GNOME Software on GNOME, dunno for any other
# desktop yet
Move all remaining utility functions into exporter modules Summary: This adds a couple of new exporter modules, renames main_common to utils (this is a better name: openSUSE's main_common is functions used in main.pm, utils is what they call their module full of miscellaneous commonly-used functions), and moves a bunch of utility functions that were previously needlessly implemented as instance methods in base classes into the exporter modules. That means we can get rid of all the annoying $self-> syntax for calling them. We get rid of `fedorabase` entirely, as it's no longer useful for anything. Other base classes keep the 'standard' methods (like `post_fail_hook`) and methods which actually need to be methods (like `root_console`, whose behaviour is different in anacondatest and installedtest). Test Plan: Do a full test suite run and check everything lines up. There should be no functional differences from before at all, this is just a re-org. Reviewers: jskladan, garretraziel_but_actually_jsedlak_who_uses_stupid_nicknames Reviewed By: garretraziel_but_actually_jsedlak_who_uses_stupid_nicknames Subscribers: tflink Differential Revision: https://phab.qa.fedoraproject.org/D1080
2017-01-18 07:15:44 +00:00
menu_launch_type('update');
add a desktop_update_graphical test Summary: Very similar to the CLI update test, but using the desktops' update applications. This is based off the CLI update test branch as it uses the shared functions that branch introduced. We do not use the fake update packages, as they don't really do anything useful for these tests; for dnf they can help us distinguish between issues with the dnf mechanism and issues with the repos, but we can't really tell that in the graphical case. So we only use the python3-kickstart package here. Test Plan: Run the test on both KDE and GNOME and ensure it performs as intended. I've been testing it on staging, so you can see it there. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1010
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';
}
# 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';
# refresh updates
Extend a timeout in the graphical update test The 'refresh' button takes a bit longer to appear on F24 respin tests.
2016-12-08 01:27:35 +00:00
assert_and_click 'desktop_package_tool_update_refresh', '', 120;
Catch RHBZ #1314991 and handle it, with a soft failure We can deal with this annoying bug by looking out for the error we see when it happens, hitting the 'refresh' button again, and resetting the loop counter to 1 (requires changing the loop to a C-style loop).
2017-09-06 21:08:53 +00:00
# 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;
}
add a desktop_update_graphical test Summary: Very similar to the CLI update test, but using the desktops' update applications. This is based off the CLI update test branch as it uses the shared functions that branch introduced. We do not use the fake update packages, as they don't really do anything useful for these tests; for dnf they can help us distinguish between issues with the dnf mechanism and issues with the repos, but we can't really tell that in the graphical case. So we only use the python3-kickstart package here. Test Plan: Run the test on both KDE and GNOME and ensure it performs as intended. I've been testing it on staging, so you can see it there. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1010
2016-09-20 22:32:44 +00:00
last if (check_screen 'desktop_package_tool_update_apply', 120);
mouse_set 10, 10;
mouse_hide;
}
handle auth request for unsigned updates on KDE When a package is unsigned, KDE will prompt for authentication. Let's handle this. But count it as a soft fail, because puiterwijk claims that Rawhide packages will be autosigned from next week, so this *should* not happen and would indicate an unsigned package in the repos. We make the KDE 'update complete' needle area smaller because the wider area includes some transparency and so will only match if the update applet is open; this area will match whether it's open (no auth case) or not open (auth case - the applet seems to disappear after you provide the password in the auth prompt). Pushing without review as the test is in production so I want to make sure it works correctly. (Also, hey, check out that array match for assert_screen and that match_has_tag! This is gonna make some things so much easier...thanks upstream)
2016-09-24 00:21:54 +00:00
# KDE annoyingly pops the notification up right over the install
Desktop update: Wait before clicking update apply button We used to do this only for KDE, but I've seen the new update tests sometimes fail at this point for no apparent reason, and I'm thinking a wait may help (in case they're clicking the button before it's really 'ready').
2017-03-02 23:33:23 +00:00
# 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;
add a desktop_update_graphical test Summary: Very similar to the CLI update test, but using the desktops' update applications. This is based off the CLI update test branch as it uses the shared functions that branch introduced. We do not use the fake update packages, as they don't really do anything useful for these tests; for dnf they can help us distinguish between issues with the dnf mechanism and issues with the repos, but we can't really tell that in the graphical case. So we only use the python3-kickstart package here. Test Plan: Run the test on both KDE and GNOME and ensure it performs as intended. I've been testing it on staging, so you can see it there. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1010
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) {
Fix desktop_update_graphical for recent F27+ GNOME change The default action on the reboot confirmation dialog changed from Reboot to Cancel, so when we hit enter, we just cancel the reboot. Tweak this to hit tab on F27+ (but not <F26, so update tests continue to work too).
2017-10-19 19:45:49 +00:00
# on F27+, default is Cancel, earlier, default is Restart
my $version = lc(get_var("VERSION"));
send_key 'tab' if ($version eq 'rawhide' || $version > 26);
add a desktop_update_graphical test Summary: Very similar to the CLI update test, but using the desktops' update applications. This is based off the CLI update test branch as it uses the shared functions that branch introduced. We do not use the fake update packages, as they don't really do anything useful for these tests; for dnf they can help us distinguish between issues with the dnf mechanism and issues with the repos, but we can't really tell that in the graphical case. So we only use the python3-kickstart package here. Test Plan: Run the test on both KDE and GNOME and ensure it performs as intended. I've been testing it on staging, so you can see it there. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1010
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;
add a desktop_update_graphical test Summary: Very similar to the CLI update test, but using the desktops' update applications. This is based off the CLI update test branch as it uses the shared functions that branch introduced. We do not use the fake update packages, as they don't really do anything useful for these tests; for dnf they can help us distinguish between issues with the dnf mechanism and issues with the repos, but we can't really tell that in the graphical case. So we only use the python3-kickstart package here. Test Plan: Run the test on both KDE and GNOME and ensure it performs as intended. I've been testing it on staging, so you can see it there. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1010
2016-09-20 22:32:44 +00:00
}
else {
handle auth request for unsigned updates on KDE When a package is unsigned, KDE will prompt for authentication. Let's handle this. But count it as a soft fail, because puiterwijk claims that Rawhide packages will be autosigned from next week, so this *should* not happen and would indicate an unsigned package in the repos. We make the KDE 'update complete' needle area smaller because the wider area includes some transparency and so will only match if the update applet is open; this area will match whether it's open (no auth case) or not open (auth case - the applet seems to disappear after you provide the password in the auth prompt). Pushing without review as the test is in production so I want to make sure it works correctly. (Also, hey, check out that array match for assert_screen and that match_has_tag! This is gonna make some things so much easier...thanks upstream)
2016-09-24 00:21:54 +00:00
# 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;
}
add a desktop_update_graphical test Summary: Very similar to the CLI update test, but using the desktops' update applications. This is based off the CLI update test branch as it uses the shared functions that branch introduced. We do not use the fake update packages, as they don't really do anything useful for these tests; for dnf they can help us distinguish between issues with the dnf mechanism and issues with the repos, but we can't really tell that in the graphical case. So we only use the python3-kickstart package here. Test Plan: Run the test on both KDE and GNOME and ensure it performs as intended. I've been testing it on staging, so you can see it there. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1010
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:
Reference in New Issue Copy Permalink