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;
|
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")) {
|
|
|
|
# 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'));
|
|
|
|
}
|
|
|
|
}
|
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';
|
|
|
|
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';
|
|
|
|
}
|
Add desktop login test, revise and rename check_desktop
This adds a new test that implementsQA:Testcase_desktop_login
on both GNOME and KDE.
While working on this, we realized that the "desktop_clean"
needles were really "app menu" needles, and for KDE, this was
a duplication with the new "system menu" needles, because on KDE
the app menu and the system menu are the same. So I (Adam)
started to de-duplicate that, but also realized that "app menu
button" is a much more accurate name for these needles, so I was
renaming the old desktop_clean needles to app_menu_button. That
led me to the realization that "check_desktop_clean" is itself a
dumb name, because we don't (at least, any more, way back in the
mists of time we may have done) do anything to check that the
desktop is "clean" - we're really just asserting that we're at a
desktop *at all*. While thinking *that* through, I *also* realized
that the whole "open the overview and look for the app grid icon"
workaround it did is no longer necessary, because GNOME doesn't
use a translucent top bar any more. That went away in GNOME 3.32,
which is in Fedora 30, our oldest supported release.
So I threw that away, renamed the function "check_desktop",
cleaned up all the needle naming and tagging, and also added an
app menu needle for GNOME in Japanese because we were missing
one (the Japanese tests have been using the "app grid icon"
workaround the whole time).
2020-03-20 09:04:43 +00:00
|
|
|
check_desktop(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:
|