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

19 Commits

Author SHA1 Message Date
Adam Williamson
a0a8e3350d Also run FreeIPA replica tests on updates
We just had an F30 update which broke replicas, so this seems
like a good idea!

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-04-09 17:22:05 -07:00
Adam Williamson
375575cd07 Use a second disk for the update repo in image build tests
This tweaks the update live and installer image build tests to
store the update repo on a separate disk. This should hopefully
avoid the tests failing due to insufficient disk space when the
update is huge (e.g. KDE or GNOME megaupdates).

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-03-13 12:57:57 -07:00
Michel Normand
58d6dbb5e6 Add missing advisory_boot ppc64le in templates-updates
and reorder ppc64 and ppc64le for updates_server* flavor
to ease comparison with x86_64.

Signed-off-by: Michel Normand <normand@linux.vnet.ibm.com>
2019-03-12 19:41:20 +00:00
Michel Normand
1b546261c5 Add PowerPC support for tests upgrade of FreeIPA
This is using the two tests previously added by
"Test upgrade of FreeIPA server and client deployment"

Signed-off-by: Michel Normand <normand@linux.vnet.ibm.com>
2019-03-12 19:41:20 +00:00
Adam Williamson
99302c6fd4 Add a live image build test for updates
Just like the installer image build test, only...it builds a live
image. This involves reimplementing quite a chunk of the Koji
livemedia task. Ah, well. Also involves rethinking the flavor
names a bit here, these seem...better.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-02-07 18:28:24 -08:00
Adam Williamson
8a68b04a3b Run the install_default_update test on UEFI as well
Obviously an installer image may work fine for a BIOS install
but fail for a UEFI install, so we should test it both ways.
This requires the invention of a new (terribly named, but I
couldn't think of anything better...) variable to allow us to
use the 'run test on machine A after test run on machine B'
mechanism without just hardcoding '64bit' as the machine name
in the START_AFTER setting (which would break if we ever wanted
to run update tests on any *other* arch).

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-01-29 15:49:59 +01:00
Adam Williamson
8d1d150798 Handle running update tests on Koji tasks
We quite often want to run the update tests on a Koji task (not
a Bodhi update) for some reason - usually to test a potential
fix for an issue, or at a maintainer's request to test a change
before it is merged upstream and officially sent out as an
update. Up till now I've always hacked up utils.pm on the
staging server by hand to do this, which is horrible. Together
with a commit to fedora_openqa, this should allow us to do it in
a nice, sane way via the CLI. It's mostly just tweaking the
"updates" repo setup in utils.pm as you'd expect, but there's a
bit of subtlety to it because of the installer tests that use
%ADVISORY% as a variable substitution in the disk image name;
you can't do something like `%ADVISORY or KOJITASK%`, sadly, so
I had to have almost-redundant variables ADVISORY, KOJITASK and
ADVISORY_OR_TASK (we could kinda just live with ADVISORY_OR_TASK
except I didn't want to drop ADVISORY as it's an unnecessary
change from previous behavior).

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-01-29 11:54:15 +01:00
Adam Williamson
d1006a38e5 Have update installer test install the update packages (#89)
In https://bugzilla.redhat.com/show_bug.cgi?id=1669256 it became
obvious that there's a missing feature in the new installer test
for updates: the update is both used in the image build process
and built into the installer environment itself, but it is not
actually included in the installed package set. This can be a
problem if the update has a bug that manifests *only* at install
time if it is in the install transaction (which is exactly the
case there), because the test will not catch this, and nor will
any other test.

So this commit makes `support_server` set up the update repo and
serve it out via NFS when it's run in an update context, and
makes the actual update install test run parallel with it and
use that repository. This way the install should include the
package(s) from the update. (It also of course means the test
fails if an update breaks NFS or something like that, but hey,
we want to know that!)

A parallel commit for fedora_openqa is necessary to add the
required CURRREL setting for the updates-installer flavor.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-01-26 19:14:04 +01:00
Adam Williamson
12affb145f Add update tests to build and test a netinst image
This adds a test which builds a netinst image potentially with
the package(s) from the update, and uploads that image. It also
adds a test which runs a default install using that image. This
is intended to check whether the update breaks the creation or
use of install images; particularly this will let us test
anaconda etc. updates. We also update the minimal disk image
name, as we have to make it bigger to accommodate this test,
and making it bigger changes its name - the actual change to
the disk image itself is in createhdds. We also have to redo a
bunch of installer needles for F28 fonts, after I removed them
a month or so back...

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-01-18 08:24:44 -08:00
Adam Williamson
339623c56b Drop the UEFI advisory_boot test, won't work
Of course this won't work as we don't have a UEFI base image.
D'oh. May try to put it back later.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-04 17:01:23 -07:00
Adam Williamson
9f72e8e0dc Fix a stray use of tabs in templates-updates
EVIL EVIL TABS

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-04 16:44:15 -07:00
Adam Williamson
0bf76db7d5 Add a test of bootchain stuff for updates
This adds a new test intended to just check boot chain things
for updates. It doesn't run any test modules besides the stock
update ones, but sets a variable, ADVISORY_BOOT_TEST, which
causes _advisory_update to do some additional stuff after
installing the updates but before rebooting: it forces regen
of the initramfs and bootloader config, and reinstalls the
bootloader on BIOS (not UEFI as it's not relevant). If the
following boot fails, we probably have a bug somewhere.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-04 16:43:15 -07:00
Adam Williamson
1e67cc802f Add Workstation upgrade test to update tests
Since we set up this whole process to run upgrade tests for
updates to run the FreeIPA ones on the Server base image, it
should be easy to also run Workstation upgrade tests on the
Workstation base image. So let's do that! Let's do the most
complex test only, the encrypted upgrade one.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-04-27 17:10:53 -07:00
Adam Williamson
e931cfa0a5 Test FreeIPA upgrade on updates
This adds the FreeIPA server and client upgrade tests to a new
updates-server-upgrade flavor which fedora_openqa will schedule
for updates. This way, we can test whether updates break
FreeIPA upgrades, which is a request the FreeIPA team made to
me. This has been deployed on staging for the last week or so
and appears to work fine.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-04-26 11:35:18 -07:00
Paul Whalen
be5585c5f3 Add aarch64 to templates-updates 2018-03-07 09:53:19 -05:00
Michel Normand
0b5ef9fe84 Add "Fedora PowerPC Updates" group and related server tests
in templates-updates file

Only support "updates-server" flavor
do not support "updates-workstation" neither "updates-kde"

Signed-off-by: Michel Normand <normand@linux.vnet.ibm.com>
2017-11-28 08:18:16 +01:00
Adam Williamson
7c28a05083 Drop update desktop_notifications tests for now
These tests don't work right at all at present: they don't test
the update at all, they just boot the base image and run the
test, which is stupid.

I looked into various ways of fixing this but it's messy and I
don't think it can work properly without a lot of hacking. Even
if we get the test to do 'the right thing' - boot, set up the
update repo, update, reboot, do the test prep, reboot again, do
the actual test - I don't think it'll be quite a valid test,
because I think any AVCs or crashes that happen *before* the
update is installed will still appear as notifications when the
test finally does log into the desktop. So the test can fail
even if there are no post-update crashes or AVCs, I think.

I decided to give up on trying to make this test work properly
for now and just disable it. We can come back to it later if we
have great ideas and/or lots of time...
2017-03-28 12:26:14 -07:00
Adam Williamson
672dd40738 Move update tests into a separate job group
This makes them more visible in the web UI.
2017-03-01 21:10:41 -08:00
Adam Williamson
92d588f245 Add support for testing updates
Summary:
This adds an entirely new workflow for testing distribution
updates. The `ADVISORY` variable is introduced: when set,
`main.pm` will load an early post-install test that sets up
a repository containing the packages from the specified update,
runs `dnf -y update`, and reboots. A new templates file is
added, `templates-updates`, which adds two new flavors called
`updates-server` and `updates-workstation`, each containing
job templates for appropriate post-install tests. Scheduler is
expected to post `ADVISORY=(update ID) HDD_1=(base image)
FLAVOR=updates-(server|workstation)`, where (base image) is one
of the stable release base disk images produced by `createhdds`
and usually used for upgrade testing. This will result in the
appropriate job templates being loaded.

We rejig postinstall test loading and static network config a
bit so that this works for both the 'compose' and 'updates' test
flows: we have to ensure we bring up networking for the tap
tests before we try and install the updates, but still allow
later adjustment of the configuration. We take advantage of the
openQA feature that was added a few months back to run the same
module multiple times, so the `_advisory_update` module can
reboot after installing the updates and the modules that take
care of bootloader, encryption and login get run again. This
looks slightly wacky in the web UI, though - it doesn't show the
later runs of each module.

We also use the recently added feature to specify `+HDD_1` in
the test suites which use a disk image uploaded by an earlier
post-install test, so the test suite value will take priority
over the value POSTed by the scheduler for those tests, and we
will use the uploaded disk image (and not the clean base image
POSTed by the scheduler) for those tests.

My intent here is to enhance the scheduler, adding a consumer
which listens out for critpath updates, and runs this test flow
for each one, then reports the results to ResultsDB where Bodhi
could query and display them. We could also add a list of other
packages to have one or both sets of update tests run on it, I
guess.

Test Plan:
Try a post something like:
HDD_1=disk_f25_server_3_x86_64.img DISTRI=fedora VERSION=25
FLAVOR=updates-server ARCH=x86_64 BUILD=FEDORA-2017-376ae2b92c
ADVISORY=FEDORA-2017-376ae2b92c CURRREL=25 PREVREL=24

Pick an appropriate `ADVISORY` (ideally, one containing some
packages which might actually be involved in the tests), and
matching `FLAVOR` and `HDD_1`. The appropriate tests should run,
a repo with the update packages should be created and enabled
(and dnf update run), and the tests should work properly. Also
test a regular compose run to make sure I didn't break anything.

Reviewers: jskladan, jsedlak

Reviewed By: jsedlak

Subscribers: tflink

Differential Revision: https://phab.qa.fedoraproject.org/D1143
2017-02-22 11:33:32 -08:00