Workaround F26 base image g-i-s issue for upgrade tests too

Since April there's been some kind of issue in the F26 base
image which means gnome-initial-setup doesn't run on the first
user login (as it should). The F25 base image is fine. I've
not yet had the time to look into this.

I put a workaround in place to prevent this problem causing
false fails of update tests that boot from the F26 base image,
but didn't apply the same workaround to upgrade tests, which
is why upgrade tests from F26 Workstation always fail - they
expect g-i-s to run on first login (which happens after the
upgrade, in upgrade tests) and it doesn't. So let's just extend
the workaround to apply to upgrade tests too, for now, until we
can figure out why this happens.
This commit is contained in:
Adam Williamson 2017-10-20 12:21:31 -07:00
parent 4323d8f533
commit 7b7b63abc1

View File

@ -58,13 +58,13 @@ sub run {
if (get_var("DESKTOP") eq 'gnome' && (get_var("ADVISORY") || !get_var("START_AFTER_TEST"))) {
# as this test gets loaded twice on the ADVISORY flow, and
# we might be on the INSTALL_NO_USER flow, check whether
# this happened already. Also, as of 2017-04 there's a bug
# this happened already. Also, as of 2017-10 there's a bug
# in the F26 base image which stops g-i-s running at all;
# for update testing purposes we don't want to fail, we
# just want to go ahead. So if we see the getting_started
# screen, just handle that instead.
# for update and upgrade testing purposes we don't want to
# fail, we just want to go ahead. So if we see the
# getting_started screen, just handle that instead.
unless (get_var("_setup_done")) {
if (get_var("ADVISORY")) {
if (get_var("ADVISORY") || get_var("UPGRADE")) {
assert_screen ["next_button", "getting_started"], 120;
if (match_has_tag("next_button")) {
gnome_initial_setup();