2016-09-23 23:03:13 +00:00
|
|
|
use base "installedtest";
|
|
|
|
use strict;
|
|
|
|
use testapi;
|
2017-01-18 07:15:44 +00:00
|
|
|
use utils;
|
2016-09-23 23:03:13 +00:00
|
|
|
use packagetest;
|
|
|
|
|
|
|
|
# This test sort of covers QA:Testcase_desktop_update_notification
|
|
|
|
# and QA:Testcase_desktop_error_checks . If it fails, probably *one*
|
|
|
|
# of those failed, but we don't know which (deciphering which is
|
|
|
|
# tricky and involves likely-fragile needles to try and figure out
|
|
|
|
# what notifications we have).
|
|
|
|
|
|
|
|
sub run {
|
|
|
|
my $self = shift;
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
my $desktop = get_var("DESKTOP");
|
2016-09-23 23:03:13 +00:00
|
|
|
# for the live image case, handle bootloader here
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
if (get_var("BOOTFROM")) {
|
2017-01-18 07:15:44 +00:00
|
|
|
do_bootloader(postinstall=>1, params=>'3');
|
2016-09-23 23:03:13 +00:00
|
|
|
}
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
else {
|
2017-01-18 07:15:44 +00:00
|
|
|
do_bootloader(postinstall=>0, params=>'3');
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
}
|
|
|
|
boot_to_login_screen;
|
2016-09-23 23:03:13 +00:00
|
|
|
$self->root_console(tty=>3);
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
# ensure we actually have some package updates available
|
2016-09-23 23:03:13 +00:00
|
|
|
prepare_test_packages;
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
if ($desktop eq 'gnome') {
|
|
|
|
# On GNOME, move the clock forward if needed, because it won't
|
|
|
|
# check for updates before 6am(!)
|
|
|
|
my $hour = script_output 'date +%H';
|
|
|
|
if ($hour < 6) {
|
|
|
|
script_run 'systemctl stop chronyd.service ntpd.service';
|
|
|
|
script_run 'systemctl disable chronyd.service ntpd.service';
|
|
|
|
script_run 'systemctl mask chronyd.service ntpd.service';
|
|
|
|
assert_script_run 'date --set="06:00:00"';
|
|
|
|
}
|
|
|
|
if (get_var("BOOTFROM")) {
|
|
|
|
# Also reset the 'last update notification check' timestamp
|
|
|
|
# to >24 hours ago (as that matters too)
|
|
|
|
my $now = script_output 'date +%s';
|
|
|
|
my $yday = $now - 48*60*60;
|
|
|
|
# have to log in as the user to do this
|
|
|
|
script_run 'exit', 0;
|
|
|
|
console_login(user=>get_var('USER_LOGIN', 'test'), password=>get_var('USER_PASSWORD', 'weakpassword'));
|
|
|
|
script_run "gsettings set org.gnome.software check-timestamp ${yday}", 0;
|
|
|
|
wait_still_screen 3;
|
|
|
|
script_run "gsettings get org.gnome.software check-timestamp", 0;
|
|
|
|
wait_still_screen 3;
|
|
|
|
script_run 'exit', 0;
|
|
|
|
console_login(user=>'root', password=>get_var('ROOT_PASSWORD', 'weakpassword'));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
assert_script_run 'systemctl isolate graphical.target';
|
2018-10-13 04:16:33 +00:00
|
|
|
# we trust systemd to switch us to the right tty here
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
if (get_var("BOOTFROM")) {
|
|
|
|
assert_screen 'graphical_login';
|
|
|
|
wait_still_screen 3;
|
2017-06-07 01:16:52 +00:00
|
|
|
# GDM 3.24.1 dumps a cursor in the middle of the screen here...
|
|
|
|
mouse_hide;
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
if (get_var("DESKTOP") eq 'gnome') {
|
|
|
|
# we have to hit enter to get the password dialog
|
|
|
|
send_key "ret";
|
|
|
|
}
|
|
|
|
assert_screen "graphical_login_input";
|
|
|
|
type_very_safely get_var("USER_PASSWORD", "weakpassword");
|
|
|
|
send_key 'ret';
|
|
|
|
}
|
2020-04-07 00:05:11 +00:00
|
|
|
else {
|
|
|
|
# the "live boot" branch; we may need to work around
|
|
|
|
# https://bugzilla.redhat.com/show_bug.cgi?id=1821499
|
|
|
|
# we should wind up at desktop now, but with that bug we
|
|
|
|
# hit GDM instead
|
|
|
|
if (check_screen "graphical_login", 30) {
|
|
|
|
record_soft_failure "Hit GDM unexpectedly - #1821499";
|
|
|
|
send_key 'ret';
|
|
|
|
}
|
|
|
|
}
|
2017-07-10 18:41:02 +00:00
|
|
|
check_desktop_clean(tries=>30);
|
2016-09-23 23:03:13 +00:00
|
|
|
# now, WE WAIT. this is just an unconditional wait - rather than
|
|
|
|
# breaking if we see an update notification appear - so we catch
|
|
|
|
# things that crash a few minutes after startup, etc.
|
2018-03-29 02:20:29 +00:00
|
|
|
for my $n (1..16) {
|
Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.
Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.
Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 23:23:59 +00:00
|
|
|
sleep 30;
|
2016-09-23 23:03:13 +00:00
|
|
|
mouse_set 10, 10;
|
|
|
|
mouse_hide;
|
|
|
|
}
|
|
|
|
if ($desktop eq 'gnome') {
|
|
|
|
# of course, we have no idea what'll be in the clock, so we just
|
|
|
|
# have to click where we know it is
|
|
|
|
mouse_set 512, 10;
|
|
|
|
mouse_click;
|
2019-05-31 00:03:58 +00:00
|
|
|
if (get_var("BOOTFROM")) {
|
|
|
|
# we should see an update notification and no others
|
|
|
|
assert_screen "desktop_update_notification_only";
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
# for the live case there should be *no* notifications
|
|
|
|
assert_screen "desktop_no_notifications";
|
|
|
|
}
|
2016-09-23 23:03:13 +00:00
|
|
|
}
|
2019-05-31 00:03:58 +00:00
|
|
|
elsif ($desktop eq 'kde') {
|
|
|
|
if (get_var("BOOTFROM")) {
|
|
|
|
assert_screen "desktop_update_notification";
|
|
|
|
# this is the case from F30 and earlier where we know this
|
|
|
|
# was the *only* notification; at this point we've passed
|
|
|
|
return if match_has_tag "desktop_update_notification_only";
|
2019-07-16 20:58:15 +00:00
|
|
|
# otherwise, we need to close the update notification(s)
|
|
|
|
# then check there are no others; see
|
|
|
|
# https://bugzilla.redhat.com/show_bug.cgi?id=1730482 for
|
|
|
|
# KDE showing multiple notifications
|
2019-07-17 16:02:24 +00:00
|
|
|
my @closed = click_unwanted_notifications;
|
|
|
|
if (grep {$_ eq 'akonadi'} @closed) {
|
|
|
|
# this isn't an SELinux denial or a crash, so it's not
|
|
|
|
# a hard failure...
|
2019-10-30 16:02:20 +00:00
|
|
|
record_soft_failure "stuck akonadi_migration_agent popup - RHBZ #1716005";
|
2019-07-17 16:02:24 +00:00
|
|
|
}
|
|
|
|
my @upnotes = grep {$_ eq 'update'} @closed;
|
|
|
|
if (scalar @upnotes > 1) {
|
|
|
|
# Also not a hard failure, but worth noting
|
|
|
|
record_soft_failure "multiple update notifications - RHBZ #1730482";
|
2019-07-16 20:58:15 +00:00
|
|
|
}
|
2019-05-31 00:03:58 +00:00
|
|
|
}
|
2016-09-23 23:03:13 +00:00
|
|
|
# the order and number of systray icons varies in KDE, so we
|
|
|
|
# can't really just use a systray 'no notifications' needle.
|
|
|
|
# instead open up the 'extended systray' thingy and click on
|
|
|
|
# the notifications bit
|
|
|
|
assert_and_click 'desktop_expand_systray';
|
|
|
|
assert_and_click 'desktop_systray_notifications';
|
2018-03-29 02:01:46 +00:00
|
|
|
# In F28+ we seem to get a network connection notification
|
|
|
|
# here. Let's dismiss it.
|
|
|
|
if (check_screen 'desktop_network_notification', 5) {
|
2019-10-30 16:02:20 +00:00
|
|
|
click_lastmatch;
|
|
|
|
}
|
|
|
|
# In F32+ we may also get an 'akonadi did something' message
|
|
|
|
if (check_screen 'akonadi_migration_notification', 5) {
|
|
|
|
click_lastmatch;
|
2018-03-29 02:01:46 +00:00
|
|
|
}
|
2019-05-31 00:03:58 +00:00
|
|
|
# on live path, we should not have got any other notification;
|
|
|
|
# on installed path, we saw an update notification and closed
|
|
|
|
# it, and now there should be no *other* notifications
|
2016-09-23 23:03:13 +00:00
|
|
|
assert_screen "desktop_no_notifications";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
sub test_flags {
|
|
|
|
return { fatal => 1 };
|
|
|
|
}
|
|
|
|
|
|
|
|
1;
|
|
|
|
|
|
|
|
# vim: set sw=4 et:
|