With Rawhide updates, we quite often run into a situation where
a test runs after a *later* version of the package has already
gone stable. This even happens for stable releases too, though
less often. The current shell-based check just always fails on
this case, but it's usually OK, and manually marking every case
like this with an "it's OK!" comment gets tiring. Instead, let's
use a smarter Python script to do the check. We compare the EVR
of all installed update packages with the EVR of the package
from the update. If it's the same, fine. If the installed package
is lower-versioned, that's always an error, and we fail. If the
installed package is higher-versioned, we check whether the
update already went stable. If it did, then we soft fail, because
probably nothing can go wrong at this point (this is the usual
Rawhide case). If the update did not yet go stable, we still
hard fail, because something can go wrong in this case: if the
update *now* goes stable, the older version from the update may
be tagged over the newer version the test got (presumably from
current stable).
If anything goes wrong with the Bodhi check, or the test is
running on a task not an advisory, we treat both cases as fatal.
The script also gives easier-to-understand output than the old
approach, which should be a bonus.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Same conditions as used in main.pm to load the tests in the
normal flow. It makes no sense to do this on non-update tests,
or on the non-matching support server case.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is safer if the advisory stuff was done on a previous test
run. Hilariously, this exposed a dumb mistake I made years ago
in installedtest.pm and never noticed before: the calls to
advisory_* at the bottom of that file are meant to be in the
post_fail_hook, but they weren't, which meant they got called
by the scheduler. This didn't cause any failures because the
first line caused them to return immediately based on a get_var
call (which it's OK to do in the scheduler), but changing it
to a script_run call (which it's *not* OK to do in scheduling)
caused all the tests to blow up immediately and confused me
*a lot* until I spotted this!
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When I enabled _advisory_post for live and ostree install tests,
the point was to check that updated packages were included in
the install media and used during installation. We shouldn't run
a system update in _repo_setup_updates on this path because it
will hide the problem if the updated packages weren't included.
The INSTALL variable is for this purpose - it was previously
used to skip _advisory_post on the same path. At the same time
let's remove some stray settings of this var on non-update tests
as it serves no purpose there.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Per discussion at https://pagure.io/fedora-ci/general/issue/376
it really feels like this is the right thing to do. There are no
buildroot overrides for Rawhide, so we don't have to worry about
cross-pollution. The buildroot repo only contains builds that
have been tagged stable since the most recent Rawhide compose,
and thus will go into the next one. It makes sense to test later
updates against these. This avoids issues like:
https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=38&build=Update-FEDORA-2022-30a952e331&groupid=2
where the tests of an update failed because it requires another
update which had been submitted and tagged stable previously, but
after the last compose.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Also use get_var("TEST") for installer_build - no point trying
to upload these logs for the other tests in the same flavor,
they won't be there.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is like the existing tests that build network install and
live images then install them, only for Silverblue. First we
build an ostree, using the standard configuration for the release
and subvariant but with the 'advisory' and 'workarounds' repos
included, so it will contain current stable packages plus the
packages from the update and any workarounds. Then we build an
ostree installer image with the ostree embedded, again including
advisory and workarounds repos in the installer build config so
packages from them will be included in the installer environment.
The image is uploaded, which completes the _ostree_build test.
Then an install_default_update_ostree test runs, which does a
standard install and boot from the installer image.
We do make a change that affects other tests, too. We now run
_advisory_post on live image install tests, as well as this new
ostree install image install test. It was skipped before because
of an exception that's really only needed for the netinst image
install test. In that test, packages from the update won't be
included in the installed system, so we can't run _advisory_post
on it. But for ostree and live image build/install tests, the
installed system *should* include packages from the update, so
we should check and make sure that it does.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's no need to run this twice (which can happen on some
paths), so if the first file already exists, just bail. Also,
don't bother uploading the config files any more - that was just
for debug while I was making this stuff work, now it works, and
this saves some time.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's one point in the tests where we may log into cockpit for
the second time in one run (it depends how a package update
process goes). When this happens, we don't get prompted again
for admin access, so we need to *not* expect that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It seems to time out a lot on lab but not on prod, for some
reason. Let's just give it a little longer.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
From 280, the cockpit package disabled logging in as root by
default. We could wipe that config file, but it seems better to
respect the default config and log in as the admin user 'test'
instead of as root.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is simpler if we just always lowercase $iso, plus it saves
us when somebody (*cough*) messes up the casing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
mock 3.2 does not allow running as root. This breaks the live
image build tests. It's being reverted upstream, this scratch
build has the reversion backported.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
desktop-backgrounds update went stable, but we also need an
f37-backgrounds update which was only just submitted to fix the
problem.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
podman tests are currently failing for all Rawhide updates. Not
sure what triggered this, but this update seems to fix it, though
it's failing its own test suite so not yet being pushed stable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We use variables to track test state across modules, sometimes.
As this is all internal to the test logic I didn't bother always
making these variables upper-case, but os-autoinst now treats
lower-case variables as a fatal error, so we have to change.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This issue appeared when we started testing Rawhide updates, but
I only noticed it today. When testing Rawhide updates after
Branch point, the upgrade tests upgrade from Branched to Rawhide.
On Branched, updates-testing is enabled by default. We only
disable it when we reach `upgrade_run`, but by that point we've
already done a `dnf -y update` in `upgrade_preinstall` and
potentially installed other packages in steps between
`upgrade_preinstall` and `upgrade_run`. That can cause problems,
like today all FreeIPA upgrade tests on Rawhide are failing
because there's a newer freeipa in updates-testing for F37 than
is in the current Rawhide compose.
Solve this by disabling updates-testing before we do the update
in `upgrade_preinstall`. To avoid excessive code duplication,
factor out the repo disabling code.
We'll do this twice on upgrade tests now, but it shouldn't be a
problem.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When we run Firefox directly on X lately, we often hit a bug
where X just suddenly exits in the middle of doing stuff in
Firefox. I'm not sure if this is a bug in X or in Firefox (if
Firefox crashed, X would immediately exit). Let's see if this
helps get any info on what's going on with Firefox.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
samba-client-libs with an soname bump made today's Rawhide, a
freeipa rebuilt against it did not, so we need this in overrides
or all FreeIPA tests fail on all Rawhide updates.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Editing the files under /ostree/deploy doesn't work on Rawhide
any more because it's been made read-only. Thanks to Timothée
Ravier for pointing out this way of doing it, which is better
anyway and avoids awful quotation issues in the code.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
A samba update was pushed for F37 without rebuilds of sssd and
freeipa (which needed to be rebuilt against it). Tests of any
of those updates on its own will fail, so including them all as
workarounds so the tests for each should work. I'll make sure
they all get pushed stable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The file conflict between older webkit2gtk4.1-jsc and new
javascriptcoregtk4.1 is causing all Workstation update tests to
fail on all Rawhide updates. This new version of webkitgtk adds
obsoletes to javascriptcoregtk4.1 which we hope should fix it.
Adding the x86_64 build directly as other arches aren't done
yet, and we only run the Workstation update tests on x86_64
anyway.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
openQA choked badly on
https://bodhi.fedoraproject.org/updates/FEDORA-2022-6256981a71
because it's, well, huge - 87 builds including texlive, which
has hundreds (thousands?) of subpackages. This exposed several
frailties against such updates.
First of all, we set NUMDISKS to at least 2 for *all* update
tests, which should mean they all stash the RPMs from the update
on a non-system disk and avoid problems with space exhaustion.
After that, just extend a few timeouts in particularly fragile
places, including one which is specific to texlive (as I don't
know of any other source package with so many subpackages).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
F35 to F36 FreeIPA server upgrade test is failing because the
latest F36 package is lower-versioned than the latest F35
package, and FreeIPA's upgrade scripts are written to fail if
this is the case. The update bumps the F36 NVR to be higher
than the F35 one.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
bodhi-client should depend on it, but technically since we have
code that calls `koji` directly here, we should probably also
include it in our install anyway, so not marking this as a
workaround.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR changes the way to download the test data into the VM.
Although it does not use a disk image as suggested in one
of the review, it does not clone the entire repository, but
a simple tar.gz file that holds the data which will be
distributed into the directory structure.
This way, the amount of data needed to be downloaded dropped
from approximately 50MB to below 2MB.
Also, the existing test suites were adapted to this situation.
Now we've ditched syslinux in Rawhide, we should just always
expect to see grub if release number is > 36.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It seems when we quit Firefox back to a VT on ppc64le, the system
hangs. Not sure why, but we can deal with it by rebooting the
system and logging back in as root if it happens. Also take the
opportunity to clean up the flow of quit_firefox so we always
check that we get back to a console then wait 5 seconds for the
console to settle, so all the tests that call it can stop doing
that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
On Rawhide update tests we often don't seem to get to the login
prompt in 10 seconds, so tweak the code a bit to let us specify
a timeout in root_console, and use 30 seconds here.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
After typing the username, on some Rawhide tests, it's taking
over 30 seconds for the password prompt to appear. This isn't
ideal but we don't want the test to fail on this. Give it up
to 45 seconds.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Wow, so the real way to do config overrides is, uh...obscure.
One file pointing to another file, both with mandatory comment
lines and one with a weird required value. Wat. Anyway, this
works in a VM. I still don't know why the policy for the first
run page isn't working as advertised.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The new way isn't working, so put the old way back but change it
to use user_pref instead of pref to see if that helps, and upload
the files for checking.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is required for script_run invocations in current
os-autoinst to tell it what to do if script_run times out, rather
than failing or succeeding (this behaviour was always undefined).
Right now you just get a deprecation warning but at some point
not setting it will be fatal. This tells it to die if script_run
times out; 0 would mean "just keep going, even though the
terminal is probably still blocked waiting for the command to
return".
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Thanks to Mike Kaply in
https://bugzilla.mozilla.org/show_bug.cgi?id=1703903#c18 , this
should avoid Quick Suggest onboarding, "Total Cookie Protection"
onboarding, and future annoying things using the same mechanisms
without using the prefs mechanism or going after each one case
by case.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The Fedora infra workers got changed so their resolv.conf doesn't
have the correct DNS server addresses in it any more, it just
has 127.0.0.53 (the systemd-resolved resolver address). We need
to query resolved to get the correct addresses.
This is quick and hacky; it doesn't accommodate anyone running
a worker host that *isn't* using resolved, and it doesn't handle
IPv6 server addresses correctly if any are present (in infra we
currently don't use any on the worker hosts). I'll try and find
time to refine it but need to deploy this for now to make the
tests pass again.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When we're logging via the serial console when a test fails and
no network is available, we only log the journal from the current
boot. But we might well need to see messages from previous boots.
So let's just log the whole journal.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Otherwise we race between the needle match and the screen scroll
update, and can click the wrong thing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The Cockpit update test relies on scrolling the Cockpit left bar
to find the Software Updates page, but in Firefox 100, the scroll
bars disappear shortly after the last time you moved the mouse.
To deal with this, instead of looking for a scroll bar to scroll,
we'll click the search box in the left bar and hit 'up' to scroll
it to the bottom.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We get these variant needles with the keyboard icon and layout
name at slightly different relative vertical positions every
time we do a Final RC. I think the layout is affected by the
pre-release warning text no longer being present. Usually each
cycle something changes with the icon or with font rendering,
so the needles have to be updated, as in this case.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I meant to include this in the earlier commit that does the same
for type_very_safely, but forgot.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I noticed today that we're timing out all the time on these
wait_still_screens in gnome-terminal, because it uses a big
flashing cursor and the similarity between "cursor there" and
"cursor not there" is less than 45 or 42 (it seems to be 38.x).
So let's drop these levels to 38, hopefully that's not too low.
There are probably more places where this is an issue, I'll
change them as I notice them.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We can't use the default similarity_level for wait_still_screen
when there's a flashing cursor - flashing cursor will always
cause the similarity level to be too low and the wait will just
time out at 30 seconds. Cut it to 42.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
check_desktop tries to catch when the overview is open and close
it. But with GNOME 42, it seems the inactive "Activities" button
is shown briefly on login before GNOME opens the overview. If
check_desktop catches that, it will think the overview isn't
open and it doesn't need to do anything. So if we match on first
cycle through the loop, let's wait_still_screen then match again.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
So these kind of things go through perl *and* bash string
interpretation and the escaping can get pretty wacky. Turns out
we need *eight* slashes here to get four through to bash (which
we need to deal with *sed*'s escaping rules), and it only works
in single quotes for some reason, not double quotes.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's a bug in rpm where doing `rpm -q [NVRA]` doesn't work
if the NVRA contains a caret. To make it work you have to add
a literal slash character before the caret character, so we add
a sed command to do that, when we're checking whether packages
from the update actually got installed.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Scratch build because we don't have a single-build update with
the fix, it's likely gonna be included in the 5.24.2 megaupdate.
I don't want to use that whole thing as a workaround, so I did
a 5.24.1 scratch build with the fix instead.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The intent is that if the ps check finds nothing we'll use the
loginctl output, but that doesn't work because script_output
doesn't return the output if the script fails. There's an arg
you can pass to make it do so, but let's just make it always
succeed instead, by adding a ||: to the second grep like we have
for the first.
Also, I noticed this problem because the ps check started not
working on F36 KDE because none of the processes we check for
are shown as running on a tty, so let's add one more that *is*
shown as running on a tty...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Tests that use Firefox started failing recently because Firefox
grew yet another stupid pop-up thing that *might* show on start
up, this appears to be trying to get you to sign up for a
feature called "quick suggest". After half an hour trawling the
relevant code, this is my best guess as to how to turn it off.
Don't know for sure if it works because the thing doesn't pop
up every time, but it at least doesn't make things worse.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
KDE tests are failing on all F34 updates ATM due to
https://bugzilla.redhat.com/show_bug.cgi?id=2049560 , add the
update to fix it. Also drop 33 from the workarounds hash as it's
EOL.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Adam Williamson
Lukáš Růžička