...because it comes out as 'cleqr'. Note, this may be fragile if
we start doing more stuff post-install, but for now I think it's
safe, I don't *think* we should ever hit this after running
`loadkeys us`.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is getting annoying. We're getting, like, 94-95% matches
for the recent needles sometimes. Instead of continuing to make
more and more needles, let's try dropping the required match
threshold a bit. The kde-20191206 needle doesn't *seem* to be
needed so let's get rid of it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It seems like the situation where we need to pull an update from
updates-testing into all update tests to work around some known
issue is going to keep happening. So instead of constantly
adding and then entirely removing bespoke lines for each specific
workaround, let's have a permanent mechanism for doing this: a
hash with release numbers as keys, and arrayrefs of update IDs
as values, and a block to call `bodhi updates download` on the
appropriate array for the release under test. This way, to add
or remove a workaround you just update the hash. If we're at a
point where *no* workarounds are needed the %workarounds hash
can be made entirely empty (it must exist, though) and the code
will be a clean no-op.
The actual workaround here pulls in Lmod updates I just sent out
to work around this issue in one of the KDE update tests:
https://openqa.fedoraproject.org/tests/497160#step/base_update_cli/11
there's some code in Lmod that gets sourced in bash profiles
which breaks openQA's `validate_script_output` by blurping two
lines of informational output into the output of the script.
The update backports a change from upstream Lmod master that
sends that informational output to stderr instead of stdout.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're bumping this in createhdds because we're changing the image
content; we need to match it here.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The jss updates all went stable already. Now we have a problem
with SELinux, upower and container-selinux (we need a newer
selinux-policy to avoid upower failures in the services_start
test, but the first attempt to fix it caused the desktop_updates
test to start failing because container-selinux needed adapting
to changes in selinux-policy...let's just pull in the updates
with the latest versions of both to be safe), and one with NSS
that causes Firefox to give false certificate errors sometimes
(this is particularly affecting the FreeIPA browser test). As
usual these should be dropped once the updates go stable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is for KDE. KDE and GNOME have different font rendering,
and they both look slightly different between a few days ago
and today, I think because of a change to the width of the
columns on the page itself.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Slight font rendering changes from the last GNOME version of
this needle, not sure if there's actually a font library change
or it's just hinting changes caused by the column being a bit
further right than before...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Lately launching anaconda on the KDE live image seems pretty
unreliable and we're not sure why. My last attempt to fix it
doesn't seem to be working, here's another effort based on the
idea it might be caused by moving the mouse from the hidden
position to the icon and back again, let's try moving the mouse
close to the icon before we assert and click it...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Seems the latest Firefox builds in F30 and F31 updates render
fonts a little differently again, not sure why this is.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We don't produce Atomic Host images any more now F29 is EOL, so
we don't need tests for them any more.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We no longer produce a Workstation network install image, so we
don't need to be capable of scheduling tests for it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We don't have the upgrade_2 variant of these tests ATM but we
should, because it's in the criteria. Easy enough to add these.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Not sure what changed; it seems like mostly browser needles got
broken, but there's a few installer needles too.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We still have a 'apps_run_firefox_stop' needle tag which is for
the same thing as 'firefox_close_tabs'. That's dumb. Get rid of
it and only have the firefox_close_tabs tag and needles. Also
clean up some old firefox_close_tabs needles that haven't matched
for months and all the 'apps_run_firefox_stop' needles.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
On Rawhide Cloud_Base boots, there's some SSH key and network
information printed above the 'login:' prompt, so we can't
expect empty space there. Also tweak console_login() to clear
the screen after logging in, so the login prompt is cleared and
doesn't confuse things on subsequent runs (like it did first
time we tried this). And add a new user logged in needle, as it
seems after we clear the screen the tilde appears in a slightly
different position and the existing needle doesn't match.
https://openqa.fedoraproject.org/tests/489003#step/_console_wait_login/7
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit f66f510832.
Turns out this breaks lots of stuff, so it needs to go back.
I'll have to figure another way to handle the cloud login.
On Rawhide Cloud_Base boots, there's some SSH key and network
information printed above the 'login:' prompt, so we can't
expect empty space there. Let's just hope not looking for the
empty space doesn't break anything else.
https://openqa.fedoraproject.org/tests/489003#step/_console_wait_login/7
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Upstream decided @ was better, : still works for now but will
probably be taken out at some point. You need openqa
4.6-37.20191121git8fcf81f or higher for this.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
KDE tests are quite frequently failing lately because anaconda
doesn't launch. I'm hoping this will help.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
autocloud is dying soon. So, we want to run the tests in openQA
instead. This adds a test module called 'autocloud' and a test
suite called 'cloud_autocloud' which basically replicate what
autocloud does (download a tarball full of tests and run each
one), and the necessary template bits to run it on Cloud_Base
qcow2 images.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
...otherwise the VNC client tests fail on aarch64 because we try
to apply the 'console=tty0' workaround for #1661288. Fortunately
we don't really need that for the VNC install test to work, so
let's just skip it. We can make this more sophisticated later if
it turns out to be necessary.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
os-autoinst has this code when doing `script_run` on a serial
terminal that does a `wait_serial` for '# ' before running the
command. For some reason when we switch to the anaconda root
console and run a couple of commands after finishing install on
ppc64, the first of these prompt checks times out, which means
the test sits there doing nothing for 90 seconds unnecessarily.
Let's try and avoid that by hacking the prompt check regex to
be empty.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There is nothing inherently 'root'-y about these so it makes no
sense to prefix their names with 'root-'. And why change from
'console' to 'terminal' compared to the naming used in the
actual qemu command and the log files? It's just confusing.
Let's be consistent (except for using - instead of _ here...
but - is easier to type!)
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The French install/boot test fails on aarch64 due to a bit of an
ordering issue:
https://openqa.stg.fedoraproject.org/tests/665124
we run `uefi_postinstall`, which does `loadkeys us`, before we
run `_console_login`, which still expects the French layout, so
it breaks. The safest way to solve this I think is to add a new
variable that lets us skip `uefi_postinstall` - I don't want to
change the ordering so we load `uefi_postinstall` after we read
`POSTINSTALL` in case that breaks things somewhere else.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
