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

10 Commits

Author SHA1 Message Date
Adam Williamson
ff0f5de643 dump get_release, just use VERSION
we've always set VERSION as the release anyhow, so just use
lc(get_var("VERSION")) whenever we want the release number or
'rawhide'.
2016-02-23 11:08:45 -08:00
Adam Williamson
d3193be3f7 remember to shift when we use $self... 2016-02-23 11:08:45 -08:00
Adam Williamson
35735f21cd Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.

Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.

For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-02-23 11:08:45 -08:00
Adam Williamson
35c42da79b add a comment explaining a perl-ism
this was requested by jskladan in D650, I forgot to add it
before committing.
2015-12-07 15:46:20 -08:00
Adam Williamson
3ecef54b51 explicitly check for DNF "system is not ready for upgrade"
Summary:
Instead of sitting there waiting 6000 seconds twice, when DNF
explicitly tells us it failed, just die.

This is why we haven't been getting proper compose check reports
lately; the upgrade tests are failing, waiting 6000 seconds to
time out, then being cloned and tried again, waiting another 6000
seconds. This is just barely going beyond check-compose's 8 hour
wait limit, as it's some time before the upgrade tests even get
started (they're low in the priority list). We're still going to
have that problem if the tests fail any other way, but this at
least catches that case.

Test Plan:
Run the upgrade tests and see that they fail quicker
(assuming the dependency problems they're dying on aren't fixed).
Maybe also do a 22-23 upgrade test and check it still succeeds
properly.

Reviewers: jskladan, garretraziel

Reviewed By: garretraziel

Subscribers: tflink

Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D650
2015-11-18 11:17:49 -08:00
Jan Sedlák
ec6b3ff4a3 use validate_script_output instead of typing and needles matching
Use validate_script_output and regex matching instead
of type_string and needles.

Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D637
2015-11-04 14:38:36 +01:00
Adam Williamson
52ceed6f39 upgrade: disable screen blanking before long-running commands
Summary:
Updating the stable release prior to doing the update can take
a long time if the image hasn't been updated for a while, and
the upgrade download process itself can take a long time. If
the screen blanks out in either case, either the following
needle match may fail (if we're waiting for a needle) or 'still
screen' may be detected early (if we're waiting for a still
screen), so let's disable screen blanking to avoid it.

Test Plan: Run the upgrade tests and see if they work.

Reviewers: garretraziel, jskladan

Reviewed By: jskladan

Subscribers: tflink

Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D628
2015-10-26 18:02:22 -07:00
Adam Williamson
68acecb6d4 convert upgrade tests to dnf-plugin-system-upgrade
Summary:
This is a first cut which more or less works for now. Issues:

1) We're not really testing the BUILD, here. All the test does
is try and upgrade to the specified VERSION - so it'll be using
the latest 'stable' for the given VERSION at the time the test
runs. This isn't really that terrible, but especially for TC/RC
validation, we might want to make things a bit more elaborate
and set up the repo for the actual BUILD (and disable the main
repos).

2) We'd actually need --nogpgcheck for non-Rawhide, at one
specific point in the release cycle - after Branching but
before Bodhi activation (which is when we can be sure all
packages are signed). This won't matter until 24 branches, and
maybe releng will have it fixed by then...if not, I'll tweak
it.

3) We don't really test that the upgrade actually *happened*
for desktop, at the moment - the only thing in the old test
that really checked that was where we checked for the fedup
boot menu entry, but that has no analog in dnf. What we should
probably do is check that GUI login works, then switch to a
console and check /etc/fedora-release just as the minimal test
does.

Test Plan:
Run the tests. Note that creating the desktop disk
image doesn't work ATM, so I can't verify the desktop test
works, but the minimal one seems to (with D565). There'll be
a matching diff for openqa_fedora_tools to update the test
case names there.

Reviewers: jskladan, garretraziel

Reviewed By: jskladan, garretraziel

Subscribers: tflink

Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D567
2015-09-10 14:49:13 -07:00
Jan Sedlák
e000209967 add comments and documentation
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D481
2015-08-05 08:23:59 +02:00
Garret Raziel
c8f02969f2 add fedup desktop test
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D451
2015-07-17 12:52:56 +02:00