As with the text install test, there's an additional choice on
the 'Time settings' path compared to whatever image garret
developed the test on; right after 'Time settings' you have to
pick 'Set timezone' or 'Configure NTP servers'. So adjust the
test to handle this, just like we did there.
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
I have a better fix for this coming, but it's a big change that
requires review, so for now, do this. The tests are actually
failing because the 30 second wait_still_screen is too short(!)
- it's triggering while the test is sitting at the 'full Fedora
logo' bootsplash screen then doing a 30 second assert_screen
graphical_login, which is failing because it actually takes
more than 60 seconds to get from the 'full F' screen to the
login screen. So let's just make the wait_still_screen 45
seconds for now.
use 'ps' output for Xorg and Xwayland. We'd need some new
openQA var to get this right by 'guessing', as it's vt1 for
Workstation when running live - so long as autologin worked -
but vt2 after install. We'd need a var or some other thing to
detect which case we're running in. LIVE doesn't do it, it's
set even when running a post-install test from a live image.
So instead let's just do it a bit more cleverly. This also
gives us a bit of insurance against changes in GDM, SDDM etc.
behaviour, so long as Xwayland or Xorg is running (and we can
add additional processes to the list, like gnome-shell, if
needed/appropriate). We assume the *final* listed process -
i.e. the most recently-started one - will be the desktop;
this covers gdm's behaviour of starting up on vt1 then running
the user session on vt2. We can make this function more complex
and add args if we ever get to the point where we have multi-
user tests running or anything (e.g. allow to pass a username
and only look for that user's processes).
Landing without review as this broke the live variant of the
test on Workstation in production (kinda not sure why it worked
in testing, or I didn't notice that it failed, but never mind).
I've tested it on staging.
When a package is unsigned, KDE will prompt for authentication.
Let's handle this. But count it as a soft fail, because
puiterwijk claims that Rawhide packages will be autosigned
from next week, so this *should* not happen and would indicate
an unsigned package in the repos. We make the KDE 'update
complete' needle area smaller because the wider area includes
some transparency and so will only match if the update applet
is open; this area will match whether it's open (no auth case)
or not open (auth case - the applet seems to disappear after
you provide the password in the auth prompt).
Pushing without review as the test is in production so I want
to make sure it works correctly.
(Also, hey, check out that array match for assert_screen and
that match_has_tag! This is gonna make some things so much
easier...thanks upstream)
Summary:
this more or less covers desktop_error_checks and desktop_
update_notification, though it can't really distinguish
between them easily. All we know is that if both the live and
postinstall versions of this test pass, both of those tests
pass. Any fails will have to be investigated manually.
Test Plan:
Run the tests for both KDE and Workstation, see
what happens. Workstation will fail for F25 and Rawhide at
present, due to SELinux/abrt notifications.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1004
Summary:
Very similar to the CLI update test, but using the desktops'
update applications. This is based off the CLI update test
branch as it uses the shared functions that branch introduced.
We do not use the fake update packages, as they don't really
do anything useful for these tests; for dnf they can help us
distinguish between issues with the dnf mechanism and issues
with the repos, but we can't really tell that in the graphical
case. So we only use the python3-kickstart package here.
Test Plan:
Run the test on both KDE and GNOME and ensure it
performs as intended. I've been testing it on staging, so you
can see it there.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1010
Summary:
this uses a couple of test repos with fake packages to test the
basic dnf mechanisms are working, then messes around with the
python3-kickstart package a bit to try and test the default repo
configuration is working, keys are in place and so on. We use
python3-kickstart because we should be able to rely on the copy
of that package in the 'stable' repo being installable (or else
the compose would have failed), but it shouldn't be vital to
the operation of the system.
Test Plan: Run the test, see if it works.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1006
Summary:
by waiting for the bootloader in _boot_to_anaconda rather than
_console_wait_login, we can ensure that we use the anaconda
post-fail hook and thus get logs uploaded when a kickstart
install fails.
Test Plan:
Run a kickstart install test that fails and check
anaconda logs get uploaded. Then run one that works and make
sure it...still works.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1005
Summary:
tty2 is where wayland desktop sessions run. I think it makes
sense to use a high tty for the post_fail_hook, so we know the
lower ones can be used by the tests...
Test Plan:
Run a Workstation post-install test that fails, check
the hook works.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1003
seems to affect the network spoke a lot but not anywhere else.
Odd. Anyhow, here we go. Keeping the old needles for now as
F25 still has the old rendering.
I guess this was developed on F24, or an older F25? There is
an additional choice showing up in production: before the tz
choice, it asks if you want to set the tz or configure NTP. So
we have to pick tz.
Summary:
I've been wanting to do this for a while, but
https://github.com/os-autoinst/openQA/issues/786 is making it
difficult. Still, I think the quantity of needles is slowing
down openQA, so I'm doing it the old-fashioned way - looking
through test results and seeing what needles are actually used
now.
Test Plan:
Run full test suite for 24 Atomic, 25 and Rawhide and
make sure all tests still work. This is currently deployed on
staging (along with key-fixes) and I'm testing it there.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D994
Summary:
the main thing this does is try and type slower in X - this
should cover nearly everywhere we type anything in X, and make
it type slower. We also add a bit more safety checking to some
old tests which didn't have it (mainly _do_install_and_reboot)
- wait_still_screen after typing to make sure all the keypresses
were registered before continuing.
This is an attempt to mitigate the problems we've seen where
the wrong text gets typed into the wrong places and the tests
break.
This branch is live on staging atm. It still has *some* issues,
but I do think it's an improvement.
Test Plan:
run the tests (probably several times), compare to
runs without the change, see if it's better or worse...
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D993
so what seems to be going on on the software selection screen
is some kind of GTK+ bug:
https://bugzilla.gnome.org/show_bug.cgi?id=771127
the radio button bullets don't always render correctly - I think
they're not always completing a transition they go through on
selection. I think they can get stuck in any state between 'grey
and small' and 'black and big', but for now these are the needles
I've managed to create from failures; we're missing a 'greyer
KDE' variant, but if that happens, we can add it. If the bug
gets fixed we should be able to drop all these.
cockpit 118 just landed in Rawhide, and it seems the username
field on the login screen is no longer selected by default,
you have to hit tab to navigate to it. We could get smart and
store the cockpit version in a variable or something, but it
doesn't seem worth it for now, let's just use a simple 'if
rawhide' conditional which can be adjusted as necessary as
things change.
https://github.com/cockpit-project/cockpit/issues/5000
Summary:
Pretty straightforward tests which deploy the database
server role and exercise it a bit.
Test Plan: Run the tests, check they work properly.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D991
these rarely get used any more. they're only used when we're
running the filesystem tests on a non-Server image, where the
default fs is ext4 not xfs. With the old nightly process, where
we only got a generic boot.iso, we used them all the time, but
now we get product-ized nightlies, we rarely do. But I did hit
them today running the universal tests with a generic boot.iso
I hand-built to test an anaconda update, so in case we need to
do that kind of thing again in future, we may as well update
the needles.
In F25+, Firefox seems to do kerberos auth automatically, so if
we go to the FreeIPA admin URL while kerberos-authed as test4,
we are logged in right away as test4 - neat! But not what we
wanted. So let's kdestroy.
when we run firefox in a bare X session, by default we get an
800x600 firefox in a 1024x768 X server with some dead black
space to the right and bottom of the screen. Now it turns out
that if the mouse is in the dead space, Firefox will not get
any keystrokes we send.
This didn't used to be a problem, but I made it into one with
this os-autoinst change:
https://github.com/os-autoinst/os-autoinst/pull/559
that makes os-autoinst move the cursor to 1023,767 after each
`assert_and_click`, instead of 0x0 as it did before, unless the
cursor has previously been explicitly place somewhere. So in
this case it gets moved to the dead space, and Firefox stops
responding to keypresses after the first `assert_and_click`.
We could equally well fix this by setting the cursor to 0,0
after running Firefox, but I like this more as it makes sure
we won't run into the same problem some other way, and makes
the videos and screenshots look nicer.
This fixes the realmd_join_cockpit test that's been failing
ever since I installed an os-autoinst with that fix. Committing
without review as it's a straightforward fix and I want the
test working again...
I assumed the 'compose location' sent by fedmsg was https, but
in fact it's http (you get redirected to https when you access
it). Could just change the default back to 4, but why not make
it properly robust. Sending without review so this doesn't go
wrong all weekend.
Summary:
we have a long-standing problem with all the tests that hit
the repositories. The tests are triggered as soon as a compose
completes. At this point in time, the compose is not synced to
the mirrors, where the default 'fedora' repo definition looks;
the sync happens after the compose completes, and there is also
a metadata sync step that must happen after *that* before any
operation that uses the 'fedora' repository definition will
actually use the packages from the new compose. Thus all net
install tests and tests that installed packages have been
effectively testing the previous compose, not the current one.
We have some thoughts about how to fix this 'properly' (such
that the openQA tests wouldn't have to do anything special,
but their 'fedora' repository would somehow reflect the compose
under test), but none of them is in place right now or likely
to happen in the short term, so in the mean time this should
deal with most of the issues. With this change, everything but
the default_install tests for the netinst images should use
the compose-under-test's Everything tree instead of the 'fedora'
repository, and thus should install and test the correct
packages.
This relies on a corresponding change to openqa_fedora_tools
to set the LOCATION openQA setting (which is simply the base
location of the compose under test).
Test Plan:
Do a full test run, check (as far as you can) tests run sensibly
and use appropriate repositories.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D989
Summary:
the dictionary error bug was fixed some time back, so drop this
workaround for it.
Test Plan:
Run all tests for F25 and Rawhide and verify they don't need
this workaround any longer.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D988
Summary: Pretty simple!
Test Plan:
Check the upgrade tests work the same as before the
change.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D979
this needle can actually also match the 'Delete all' button,
resulting in the test not doing what it should. openQA should
prefer the match closer to the area's location in the needle,
but https://openqa.fedoraproject.org/tests/31136 seems to show
this not happening, so let's make the match area wider in all
versions of the needle so it should no longer match the Delete
all button.
font rendering has changed somehow in both Rawhide and F25
updates-testing, retake a bunch of needles for this. Some more
may be needed later in tests that are currently failed or
skipped for other reasons.
this isn't actually f25 specific, I don't think...the tests
that failed are the Workstation network install tests, which
use updates-testing, so I think they're getting the same font
rendering change as just showed up in Rawhide. So these should
actually be correct for both branches, let's just leave the
name as the date.
This adds possiblity to specify more than one test in ENTRYPOINT
variable - test names should be separated with spaces and loading is done
as with POSTINSTALL.
Add _console_shutdown test to ARM image deployment.
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D973
