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");
|
2021-04-03 00:00:07 +00:00
|
|
|
my $relnum = get_release_number;
|
2022-07-10 21:05:04 +00:00
|
|
|
my $version_major = get_version_major;
|
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;
|
2020-04-14 19:10:02 +00:00
|
|
|
# use tty1 to avoid RHBZ #1821499 on F32 Workstation live
|
|
|
|
$self->root_console(tty=>1);
|
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")) {
|
2021-03-06 01:56:56 +00:00
|
|
|
# Set a bunch of update checking-related timestamps to
|
|
|
|
# two days ago or two weeks ago to try and make sure we
|
|
|
|
# get notifications, see:
|
|
|
|
# https://wiki.gnome.org/Design/Apps/Software/Updates#Tentative_Design
|
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 $now = script_output 'date +%s';
|
2021-03-06 01:56:56 +00:00
|
|
|
my $yyday = $now - 2*24*60*60;
|
|
|
|
my $longago = $now - 14*24*60*60;
|
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
|
|
|
# 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'));
|
2021-03-06 01:56:56 +00:00
|
|
|
script_run "gsettings set org.gnome.software check-timestamp ${yyday}", 0;
|
|
|
|
script_run "gsettings set org.gnome.software update-notification-timestamp ${longago}", 0;
|
|
|
|
script_run "gsettings set org.gnome.software online-updates-timestamp ${longago}", 0;
|
|
|
|
script_run "gsettings set org.gnome.software upgrade-notification-timestamp ${longago}", 0;
|
|
|
|
script_run "gsettings set org.gnome.software install-timestamp ${longago}", 0;
|
|
|
|
wait_still_screen 5;
|
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
|
|
|
script_run 'exit', 0;
|
|
|
|
console_login(user=>'root', password=>get_var('ROOT_PASSWORD', 'weakpassword'));
|
|
|
|
}
|
|
|
|
}
|
2020-04-14 19:10:02 +00:00
|
|
|
# can't use assert_script_run here as long as we're on tty1
|
|
|
|
type_string "systemctl isolate graphical.target\n";
|
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';
|
2020-11-12 18:16:03 +00:00
|
|
|
wait_still_screen 10, 30;
|
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') {
|
2020-11-12 18:20:34 +00:00
|
|
|
# we have to hit enter to get the password dialog, and it
|
|
|
|
# doesn't always work for some reason so just try it three
|
|
|
|
# times
|
|
|
|
send_key_until_needlematch("graphical_login_input", "ret", 3, 5);
|
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
|
|
|
}
|
|
|
|
assert_screen "graphical_login_input";
|
|
|
|
type_very_safely get_var("USER_PASSWORD", "weakpassword");
|
|
|
|
send_key 'ret';
|
|
|
|
}
|
2020-04-18 21:54:48 +00:00
|
|
|
check_desktop(timeout=>90);
|
2021-04-03 00:00:07 +00:00
|
|
|
# now, WE WAIT. Because KDE on F34+ shows a notification only
|
|
|
|
# briefly we will keep an eye out and record if we saw it (logic
|
|
|
|
# around this comes later). But we wait the whole ten minutes even
|
|
|
|
# if we see it so we catch any unwanted notifications that appear
|
|
|
|
# shortly after boot
|
|
|
|
my $seen = 0;
|
2018-03-29 02:20:29 +00:00
|
|
|
for my $n (1..16) {
|
2021-04-03 00:00:07 +00:00
|
|
|
$seen = 1 if (check_screen "desktop_update_notification", 30);
|
|
|
|
mouse_set 20, 20;
|
2020-08-07 01:03:08 +00:00
|
|
|
send_key "spc";
|
2016-09-23 23:03:13 +00:00
|
|
|
mouse_hide;
|
|
|
|
}
|
|
|
|
if ($desktop eq 'gnome') {
|
2020-10-14 22:31:59 +00:00
|
|
|
# click the clock to show notifications. of course, we have no
|
|
|
|
# idea what'll be in the clock, so we just have to click where
|
|
|
|
# we know it is
|
2016-09-23 23:03:13 +00:00
|
|
|
mouse_set 512, 10;
|
|
|
|
mouse_click;
|
|
|
|
}
|
2020-10-14 22:31:59 +00:00
|
|
|
if ($desktop eq 'kde') {
|
2019-05-31 00:03:58 +00:00
|
|
|
if (get_var("BOOTFROM")) {
|
2020-10-14 22:31:59 +00:00
|
|
|
# first check the systray update notification is there
|
|
|
|
assert_screen "desktop_update_notification_systray";
|
2019-05-31 00:03:58 +00:00
|
|
|
}
|
2020-10-14 22:31:59 +00:00
|
|
|
# now open the notifications view in the systray
|
|
|
|
if (check_screen 'desktop_icon_notifications') {
|
|
|
|
# this is the little bell thing KDE sometimes shows if
|
|
|
|
# there's been a notification recently...
|
2019-10-30 16:02:20 +00:00
|
|
|
click_lastmatch;
|
|
|
|
}
|
2020-10-14 22:31:59 +00:00
|
|
|
else {
|
|
|
|
# ...otherwise you have to expand the systray and click
|
|
|
|
# "Notifications"
|
|
|
|
assert_and_click 'desktop_expand_systray';
|
|
|
|
assert_and_click 'desktop_systray_notifications';
|
|
|
|
}
|
|
|
|
# In F32+ we may get an 'akonadi did something' message
|
2019-10-30 16:02:20 +00:00
|
|
|
if (check_screen 'akonadi_migration_notification', 5) {
|
|
|
|
click_lastmatch;
|
2018-03-29 02:01:46 +00:00
|
|
|
}
|
2020-10-14 22:31:59 +00:00
|
|
|
}
|
|
|
|
if (get_var("BOOTFROM")) {
|
2022-07-10 21:05:04 +00:00
|
|
|
if ($desktop eq 'kde' && (($relnum > 33) || ($version_major > 8))) {
|
2021-06-15 20:56:00 +00:00
|
|
|
# there is not always a permanent notification in F34+,
|
|
|
|
# if we don't see one, check we saw the transient one
|
|
|
|
# earlier. FIXME: maybe drop the 'transient' path here
|
|
|
|
# if the permanent notification seems to be reliably
|
|
|
|
# back after 2021-06-13 Rawhide?
|
|
|
|
assert_screen ["desktop_no_notifications", "desktop_update_notification_only"];
|
|
|
|
if (match_has_tag "desktop_no_notifications") {
|
|
|
|
die "No update notification was shown!" unless $seen;
|
|
|
|
}
|
2021-04-03 00:00:07 +00:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
# we should see an update notification and no others
|
|
|
|
assert_screen "desktop_update_notification_only";
|
|
|
|
}
|
2020-10-14 22:31:59 +00:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
# for the live case there should be *no* notifications
|
2016-09-23 23:03:13 +00:00
|
|
|
assert_screen "desktop_no_notifications";
|
2021-04-03 00:00:07 +00:00
|
|
|
if ($desktop eq 'kde' && $relnum > 33) {
|
|
|
|
# and no tray icon either
|
|
|
|
die "Systray update notification should not be present on live!" if (check_screen "desktop_update_notification_systray");
|
|
|
|
die "Transient notification should not be shown on live!" if $seen;
|
|
|
|
}
|
2016-09-23 23:03:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
sub test_flags {
|
|
|
|
return { fatal => 1 };
|
|
|
|
}
|
|
|
|
|
|
|
|
1;
|
|
|
|
|
|
|
|
# vim: set sw=4 et:
|