2016-05-20 14:53:45 +00:00
|
|
|
use base "installedtest";
|
2015-03-18 21:28:03 +00:00
|
|
|
use strict;
|
|
|
|
|
use testapi;
|
2017-01-18 07:15:44 +00:00
|
|
|
use utils;
|
2015-03-18 21:28:03 +00:00
|
|
|
|
|
|
|
|
sub run {
|
2016-09-12 17:24:30 +00:00
|
|
|
my $self = shift;
|
2016-05-05 23:39:47 +00:00
|
|
|
# If KICKSTART is set, then the wait_time needs to consider the
|
|
|
|
|
# install time. if UPGRADE, we have to wait for the entire upgrade
|
2016-07-08 15:56:57 +00:00
|
|
|
# unless ENCRYPT_PASSWORD is set (in which case the postinstall
|
|
|
|
|
# test does the waiting)
|
2016-05-05 23:39:47 +00:00
|
|
|
my $wait_time = 300;
|
|
|
|
|
$wait_time = 1800 if (get_var("KICKSTART"));
|
2016-07-08 15:56:57 +00:00
|
|
|
$wait_time = 6000 if (get_var("UPGRADE") && !get_var("ENCRYPT_PASSWORD"));
|
2015-03-18 21:28:03 +00:00
|
|
|
|
|
|
|
|
# Wait for the login screen
|
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(timeout => $wait_time);
|
2016-05-05 23:39:47 +00:00
|
|
|
# do user login unless USER_LOGIN is set to string 'false'
|
|
|
|
|
unless (get_var("USER_LOGIN") eq "false") {
|
|
|
|
|
if (get_var("DESKTOP") eq 'gnome') {
|
|
|
|
|
# we have to hit enter to get the password dialog
|
|
|
|
|
send_key "ret";
|
|
|
|
|
}
|
|
|
|
|
assert_screen "graphical_login_input";
|
2016-12-16 17:40:29 +00:00
|
|
|
my $password = get_var("USER_PASSWORD", "weakpassword");
|
|
|
|
|
if (get_var("SWITCHED_LAYOUT")) {
|
|
|
|
|
# see _do_install_and_reboot; when layout is switched
|
|
|
|
|
# user password is doubled to contain both US and native
|
|
|
|
|
# chars
|
2016-12-21 16:41:00 +00:00
|
|
|
desktop_switch_layout 'ascii';
|
2016-12-16 17:40:29 +00:00
|
|
|
type_very_safely $password;
|
|
|
|
|
desktop_switch_layout 'native';
|
|
|
|
|
type_very_safely $password;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
type_very_safely $password;
|
|
|
|
|
}
|
2015-03-18 21:28:03 +00:00
|
|
|
send_key "ret";
|
2016-05-05 23:39:47 +00:00
|
|
|
|
|
|
|
|
# Handle initial-setup, for GNOME, unless START_AFTER_TEST
|
Add support for testing updates
Summary:
This adds an entirely new workflow for testing distribution
updates. The `ADVISORY` variable is introduced: when set,
`main.pm` will load an early post-install test that sets up
a repository containing the packages from the specified update,
runs `dnf -y update`, and reboots. A new templates file is
added, `templates-updates`, which adds two new flavors called
`updates-server` and `updates-workstation`, each containing
job templates for appropriate post-install tests. Scheduler is
expected to post `ADVISORY=(update ID) HDD_1=(base image)
FLAVOR=updates-(server|workstation)`, where (base image) is one
of the stable release base disk images produced by `createhdds`
and usually used for upgrade testing. This will result in the
appropriate job templates being loaded.
We rejig postinstall test loading and static network config a
bit so that this works for both the 'compose' and 'updates' test
flows: we have to ensure we bring up networking for the tap
tests before we try and install the updates, but still allow
later adjustment of the configuration. We take advantage of the
openQA feature that was added a few months back to run the same
module multiple times, so the `_advisory_update` module can
reboot after installing the updates and the modules that take
care of bootloader, encryption and login get run again. This
looks slightly wacky in the web UI, though - it doesn't show the
later runs of each module.
We also use the recently added feature to specify `+HDD_1` in
the test suites which use a disk image uploaded by an earlier
post-install test, so the test suite value will take priority
over the value POSTed by the scheduler for those tests, and we
will use the uploaded disk image (and not the clean base image
POSTed by the scheduler) for those tests.
My intent here is to enhance the scheduler, adding a consumer
which listens out for critpath updates, and runs this test flow
for each one, then reports the results to ResultsDB where Bodhi
could query and display them. We could also add a list of other
packages to have one or both sets of update tests run on it, I
guess.
Test Plan:
Try a post something like:
HDD_1=disk_f25_server_3_x86_64.img DISTRI=fedora VERSION=25
FLAVOR=updates-server ARCH=x86_64 BUILD=FEDORA-2017-376ae2b92c
ADVISORY=FEDORA-2017-376ae2b92c CURRREL=25 PREVREL=24
Pick an appropriate `ADVISORY` (ideally, one containing some
packages which might actually be involved in the tests), and
matching `FLAVOR` and `HDD_1`. The appropriate tests should run,
a repo with the update packages should be created and enabled
(and dnf update run), and the tests should work properly. Also
test a regular compose run to make sure I didn't break anything.
Reviewers: jskladan, jsedlak
Reviewed By: jsedlak
Subscribers: tflink
Differential Revision: https://phab.qa.fedoraproject.org/D1143
2017-01-25 16:16:12 +00:00
|
|
|
# is set in which case it will have been done already. Always
|
|
|
|
|
# do it if ADVISORY is set, as for the update testing flow,
|
|
|
|
|
# START_AFTER_TEST is set but a no-op and this hasn't happened
|
|
|
|
|
if (get_var("DESKTOP") eq 'gnome' && (get_var("ADVISORY") || !get_var("START_AFTER_TEST"))) {
|
|
|
|
|
# as this test gets loaded twice on the ADVISORY flow,
|
|
|
|
|
# keep track of whether this happened already
|
|
|
|
|
unless (get_var("_gis_done")) {
|
|
|
|
|
assert_screen "next_button", 120;
|
|
|
|
|
# wait a bit in case of animation
|
|
|
|
|
wait_still_screen 3;
|
|
|
|
|
for my $n (1..3) {
|
|
|
|
|
# click 'Next' three times, moving the mouse to avoid
|
|
|
|
|
# highlight problems, sleeping to give it time to get
|
|
|
|
|
# to the next screen between clicks
|
|
|
|
|
mouse_set(100, 100);
|
|
|
|
|
wait_screen_change { assert_and_click "next_button"; };
|
|
|
|
|
# for Japanese, we need to workaround a bug on the keyboard
|
|
|
|
|
# selection screen
|
|
|
|
|
if ($n == 1 && get_var("LANGUAGE") eq 'japanese') {
|
|
|
|
|
if (!check_screen 'initial_setup_kana_kanji_selected', 5) {
|
|
|
|
|
record_soft_failure 'kana kanji not selected: bgo#776189';
|
|
|
|
|
assert_and_click 'initial_setup_kana_kanji';
|
|
|
|
|
}
|
2016-12-21 16:41:00 +00:00
|
|
|
}
|
|
|
|
|
}
|
Add support for testing updates
Summary:
This adds an entirely new workflow for testing distribution
updates. The `ADVISORY` variable is introduced: when set,
`main.pm` will load an early post-install test that sets up
a repository containing the packages from the specified update,
runs `dnf -y update`, and reboots. A new templates file is
added, `templates-updates`, which adds two new flavors called
`updates-server` and `updates-workstation`, each containing
job templates for appropriate post-install tests. Scheduler is
expected to post `ADVISORY=(update ID) HDD_1=(base image)
FLAVOR=updates-(server|workstation)`, where (base image) is one
of the stable release base disk images produced by `createhdds`
and usually used for upgrade testing. This will result in the
appropriate job templates being loaded.
We rejig postinstall test loading and static network config a
bit so that this works for both the 'compose' and 'updates' test
flows: we have to ensure we bring up networking for the tap
tests before we try and install the updates, but still allow
later adjustment of the configuration. We take advantage of the
openQA feature that was added a few months back to run the same
module multiple times, so the `_advisory_update` module can
reboot after installing the updates and the modules that take
care of bootloader, encryption and login get run again. This
looks slightly wacky in the web UI, though - it doesn't show the
later runs of each module.
We also use the recently added feature to specify `+HDD_1` in
the test suites which use a disk image uploaded by an earlier
post-install test, so the test suite value will take priority
over the value POSTed by the scheduler for those tests, and we
will use the uploaded disk image (and not the clean base image
POSTed by the scheduler) for those tests.
My intent here is to enhance the scheduler, adding a consumer
which listens out for critpath updates, and runs this test flow
for each one, then reports the results to ResultsDB where Bodhi
could query and display them. We could also add a list of other
packages to have one or both sets of update tests run on it, I
guess.
Test Plan:
Try a post something like:
HDD_1=disk_f25_server_3_x86_64.img DISTRI=fedora VERSION=25
FLAVOR=updates-server ARCH=x86_64 BUILD=FEDORA-2017-376ae2b92c
ADVISORY=FEDORA-2017-376ae2b92c CURRREL=25 PREVREL=24
Pick an appropriate `ADVISORY` (ideally, one containing some
packages which might actually be involved in the tests), and
matching `FLAVOR` and `HDD_1`. The appropriate tests should run,
a repo with the update packages should be created and enabled
(and dnf update run), and the tests should work properly. Also
test a regular compose run to make sure I didn't break anything.
Reviewers: jskladan, jsedlak
Reviewed By: jsedlak
Subscribers: tflink
Differential Revision: https://phab.qa.fedoraproject.org/D1143
2017-01-25 16:16:12 +00:00
|
|
|
# click 'Skip' one time
|
|
|
|
|
mouse_set(100,100);
|
|
|
|
|
wait_screen_change { assert_and_click "skip_button"; };
|
|
|
|
|
send_key "ret";
|
|
|
|
|
# wait for the stupid 'help' screen to show and kill it
|
|
|
|
|
assert_screen "getting_started";
|
|
|
|
|
send_key "alt-f4";
|
|
|
|
|
wait_still_screen 5;
|
|
|
|
|
# don't do it again on second load
|
|
|
|
|
set_var("_gis_done", 1);
|
2016-05-05 23:39:47 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-18 21:28:03 +00:00
|
|
|
# Move the mouse somewhere it won't highlight the match areas
|
|
|
|
|
mouse_set(300, 200);
|
2016-05-05 23:39:47 +00:00
|
|
|
# KDE can take ages to start up
|
|
|
|
|
assert_screen "graphical_desktop_clean", 120;
|
2015-03-18 21:28:03 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
sub test_flags {
|
|
|
|
|
# without anything - rollback to 'lastgood' snapshot if failed
|
|
|
|
|
# 'fatal' - whole test suite is in danger if this fails
|
|
|
|
|
# 'milestone' - after this test succeeds, update 'lastgood'
|
|
|
|
|
# 'important' - if this fails, set the overall state to 'fail'
|
|
|
|
|
return { fatal => 1, milestone => 1 };
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
1;
|
|
|
|
|
|
|
|
|
|
# vim: set sw=4 et:
|