1
0
mirror of https://pagure.io/fedora-qa/os-autoinst-distri-fedora.git synced 2024-12-05 11:33:08 +00:00
Commit Graph

361 Commits

Author SHA1 Message Date
Lukáš Růžička
3439359c68 Create a test suite for Gnome Software. 2023-03-21 10:27:34 +01:00
Adam Williamson
c25db659c0 Add anaconda fix for new pykickstart as a workaround
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-03-17 21:26:39 -07:00
Adam Williamson
ac6ecb1058 Drop workarounds that have gone stable
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-03-17 21:26:16 -07:00
Adam Williamson
cf5532fc3a Add workarounds for ffmpeg/kf5/oneVPL mess
So...there's an ffmpeg update:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-a5e10b188a
which went stable. It includes new sonames of all the ffmpeg
libs. It also pulls in a thing called oneVPL, which has a bug
that breaks ostree composes.

There's a big kf5 update:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-b086a98f78
which contains kf5-kfilemetadata, which is built against ffmpeg.
Neal made sure that update's build of it was built against the
new ffmpeg and submitted both for stable at once - but the tests
on the kf5 update failed because they weren't run against the
new ffmpeg as it wasn't yet stable, and the kf5 update was
ejected from the push because of the failed tests.

So now we have the ffmpeg update stable but not the
kf5-kfilemetadata rebuild for it, which will break KDE stuff,
and the oneVPL issue means ostree composes will all fail.

This adds the ffmpeg update as a workaround so we can re-run the
tests for the kf5 update and get them to pass so we can push it
stable. It also adds the oneVPL update as a workaround so ostree
compose tests don't start failing.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-03-13 18:20:14 -07:00
Adam Williamson
a9a3cea174 Don't use koji-rawhide repo on support_server test
We definitely don't want the support server pulling in random
packages from Rawhide.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-25 10:22:50 -08:00
Adam Williamson
1d3fe8dbb6 Drop workaround that's now stable
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-24 12:57:37 -08:00
Adam Williamson
471ea9d27b workarounds: add plasma-discover with fix for #2173022
Just using a scratch build for now as my fix hasn't been reviewed
and may have dumb mistakes in it, but it does seem to fix the
openQA test at least.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-23 12:15:15 -08:00
Adam Williamson
f42d921b0b Drop workarounds that have gone stable
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-23 12:14:48 -08:00
Adam Williamson
bb3492ac9d Remove repo management packages on update live install path
A different way to address the same problem as 56936df7 . Let's
just *remove* the repo management packages after we're done
creating the repos. dnf will automatically remove the unused
dependencies too. This fixes the python-cryptography case at
least - I tested.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-22 15:57:02 -08:00
Adam Williamson
9a0ef37a25 Revert "Update live install tests: handle awkward install ordering"
This reverts commit 56936df7a5. It
was a lovely idea, but forgot that the 'matching update version'
check doesn't actually use the allpkgs.txt list...
2023-02-22 15:55:24 -08:00
Adam Williamson
56936df7a5 Update live install tests: handle awkward install ordering
There's this awkward path for the live image install tests on
updates. We run the 'are the correct versions of all the packages
installed' check on these tests to ensure the right versions
actually made it onto the live image. So we don't run
`dnf -y update` at the end of repo_setup_updates on that path,
because if we did that, even if the packages on the live image
were old, we'd update them there and hide the problem.

However, this causes a bit of an ordering issue, because in
order to set up the advisory repo, we need to install a few
packages. What if the update under test includes one of those
packages, or a dependency that wasn't already installed? In
that case, we wind up with the older stable version of the
package (because obviously we can't install the newer version
from the advisory repo *before we've set up the advisory repo*),
don't update it later, and so the 'correct version' check at
the end of the test fails. See:
https://openqa.fedoraproject.org/tests/1778707 for a case of
this happening with a python-cryptography update.

Up till now I was trying to handle this by just updating the
specific packages we install, but that doesn't account for
*dependencies* of them. I looked down the path of trying to
generate a list of all those dependencies and update all of
them but it looks a bit mad. So instead let's try this. On that
specific path, we'll generate the "all installed packages" list
*before* we run repo_setup, so it just doesn't include anything
that gets installed during repo_setup. The implementation is a
bit icky but not too horrible.

We *could* just *always* generate the all installed packages
list earlier, but then that would mean we *wouldn't* catch dep
issues in this kind of package on the other test paths, whereas
currently we do. I don't want to lose that.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-22 14:54:18 -08:00
Adam Williamson
a4ff85695b handle_welcome_screen: only set _WELCOME_DONE if we saw it
This is to handle a temporary condition where the screen isn't
present on the KDE base disk images for F38 or F39 yet, so they
only see it on the second boot on update tests, but don't handle
it because we marked it as already 'done'.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-22 08:04:29 -08:00
Adam Williamson
4254906308 Try clicking Skip on the KDE welcome tour thing
It seems like just closing it results in it showing up again on
the next boot...

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-21 19:57:19 -08:00
Adam Williamson
ddb3f44c57 Extend handle_welcome_screen to cover new KDE welcome tour
KDE has a welcome tour now, on F38 and Rawhide at least. Let's
"handle" it with extreme prejudice...

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-21 18:16:13 -08:00
Adam Williamson
ac1a59ef77 workarounds: kwin build that fixes VT switch for F38 and F39
The F38 update that breaks this hasn't gone stable due to gating
and the F39 update will be pulled in once the tests are done
and it goes stable, but doing this anyway so I can re-run the
tests on the F38 plasma-workspace update and push it stable,
and rerun all the failed Rawhide tests without waiting for all
the tests on this update to finish first.
2023-02-20 22:11:31 -08:00
Adam Williamson
19500a4018 drop workarounds that have gone stable
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-20 22:10:40 -08:00
Adam Williamson
7ea4ed733c Sigh, do the are-we-44 check in the right place
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-20 17:29:13 -08:00
Adam Williamson
d0699217a4 Handle g-i-s 44 requiring two tabs at 'set a password' screen
We still need to handle 43 only requiring one for now, and we
can't just make it release-dependent until 44 is stable for both
38 and Rawhide, so let's use a needle match temporarily. Only
44 has these eye/pencil icons on this screen.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-20 17:13:37 -08:00
Adam Williamson
813c329c0c workarounds: add lorax with disabled persistence for 38/39 (#2170544)
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-16 10:44:37 -08:00
Adam Williamson
35eec4062e Drop workarounds that went stable
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-16 10:43:22 -08:00
Adam Williamson
7156881b64 workarounds: add kde-settings for F38 too
This gets us the F38 background in KDE.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-14 11:27:18 -08:00
Adam Williamson
42316bdfb1 workarounds: add desktop-backgrounds too for F38
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-14 09:58:49 -08:00
Adam Williamson
8ce8f2aba4 f38 workarounds: drop updates now stable, add f38-backgrounds
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-14 09:17:49 -08:00
Adam Williamson
6baf67aefd Work around the f39 toolbox container not existing
On Rawhide, just use an f38 toolbox container for now.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-13 19:16:09 -08:00
Adam Williamson
619f5a70fe Add glib2 2.75.3 to f38 workarounds (FEDORA-2023-965f517da3)
GNOME blows up without it.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-13 15:09:14 -08:00
Adam Williamson
860c8e0a09 Add bug F38 GNOME update to workarounds
As we're not getting composes ATM this isn't being pulled into
tests of subsequent updates, but we need it to be or else there
are issues.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-13 12:23:08 -08:00
Adam Williamson
016c78d80b Add FEDORA-2023-ad52b2e4b9 as a workaround for F38
tracker-miners had a bad dep which broke live image builds.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-10 00:05:40 -08:00
Adam Williamson
95de85b33a Adjust a wait_still_screen not to time out on a flashing cursor
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-07 10:02:38 -08:00
Adam Williamson
8bcabe25a8 Give some long-running package install operations a bit longer
These have timed out quite often recently.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-03 09:04:48 -08:00
Adam Williamson
6a7c11466c Get updvercheck.py from main now it's merged
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-02-03 08:58:38 -08:00
Adam Williamson
06bfd2d2ae Make the update non-matching package check smarter
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>
2023-01-31 10:14:45 -08:00
Adam Williamson
6a36fe28d1 Handle a false failure when testing koji updates
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-01-14 02:57:38 -08:00
Adam Williamson
02136a80e1 utils.pm: drop some stuff unneeded after F35 EOL
and associated needles.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-12-13 14:34:34 -08:00
Adam Williamson
6f0478d4b4 gnome_initial_setup: drop a <35 conditional that's not needed
F34 is EOL for a while.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-12-13 14:34:34 -08:00
Adam Williamson
6e9213f4b7 Drop use of _ADVISORY_REPO_DONE, always use file tests
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>
2022-12-12 08:53:02 -08:00
Adam Williamson
7429b438fd Don't update system in repo_setup on update install tests
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>
2022-12-09 13:07:15 -08:00
Adam Williamson
5698525cc7 Enable the buildroot repository for Rawhide update tests
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>
2022-12-08 14:28:09 -08:00
Adam Williamson
ba88dac325 Handle chunked ADVISORY_NVRS_N settings
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-12-01 15:52:20 -08:00
Adam Williamson
03b6663339 Add tests to build a Silverblue installer image and install it
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>
2022-11-30 13:17:28 -08:00
Adam Williamson
c9191b0d4a disable_firefox_studies: don't run twice, skip uploads
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>
2022-11-25 11:39:39 -08:00
Adam Williamson
c9924ecdeb Drop workaround which went stable two weeks ago
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-11-18 13:19:48 -08:00
Adam Williamson
946411cba4 Add layer-shell-qt workaround to make KDE work on Rawhide again
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-11-02 11:04:37 -07:00
Adam Williamson
c1d676e6ae Drop a workaround that went stable weeks ago
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-11-02 11:04:19 -07:00
Adam Williamson
b5c8a8d5f7 Fix tell_source
OK, that last commit was just, uh, wrong.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-10-28 12:06:57 -07:00
Adam Williamson
31826f7938 utils: simply and robustify tell_source
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>
2022-10-28 11:57:33 -07:00
Adam Williamson
6b341097f2 Add some missing underscores to a variable check
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-10-22 14:10:13 -07:00
Adam Williamson
b84125d4f5 Replace scratch build override for mock with official update
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-10-18 09:21:54 -07:00
Adam Williamson
b6fdb4c3fa Add a mock build that works as root to Rawhide workarounds
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>
2022-10-17 07:18:40 -07:00
Adam Williamson
9f1c136c37 Clear pushed workarounds for Rawhide
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-10-17 16:17:43 +02:00
Adam Williamson
1c819304d2 F38 workarounds: replace desktop-backgrounds with f37-backgrounds
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>
2022-10-08 23:13:33 +02:00