2015-01-27 15:02:14 +00:00
|
|
|
#!/usr/bin/env python
|
|
|
|
|
|
|
|
import json
|
|
|
|
import urlgrabber
|
|
|
|
import os.path
|
|
|
|
import sys
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
import argparse
|
2015-02-18 09:02:50 +00:00
|
|
|
import datetime
|
2015-07-09 08:31:53 +00:00
|
|
|
import logging
|
drop 'all', add 'current' check and waiting to 'compose'
Summary:
This is an alternative to D516. It drops the 'all' subcommand
entirely and adds some capabilities to 'compose' to make it
suitable for scripting. --ifnotcurrent will check if the compose
is the same as the current validation event, and bail out if it
is. --wait waits for the compose to be available. I've also
enhanced fedfind (in 1.4.1) to allow passing just 'Branched'
as the milestone; it will guess the release and date, now (it
didn't before).
With all of that taken together, we could have three cron jobs,
one for 'current', one for 'branched', and one for 'rawhide'.
That way we don't have to do any clever multiprocess/round-robin
waiting stuff, and the jobs for each release will be run and
reported as fast as possible (and we can run the compose report
right after the trigger script and have that sent out
efficiently too).
Test Plan:
Try all the possibilities with 'compose' - especially
check that it works with just '-m Rawhide' and '-m Branched',
and that the --wait and --ifnotcurrent args work as intended.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D525
2015-08-24 18:38:50 +00:00
|
|
|
import time
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
# We can at least find images and run OpenQA jobs without wikitcms
|
|
|
|
try:
|
|
|
|
import wikitcms.wiki
|
2015-07-09 08:31:53 +00:00
|
|
|
except ImportError:
|
|
|
|
wikitcms = None
|
handle errors while waiting for compose smartly
Summary:
So the first attempt to use the waiting stuff in production
failed because, at some point, koji_done got a socket.error
from the server. Not sure if that was a Koji outage or some
kind of rate control, but even if it's rate control and we need
to tweak the wait interval, this seems advisable: we shouldn't
die the first time we hit any kind of error while waiting, we
should retry a few times first (with increasingly long delays
between the retry attempts). I know bare except clauses are BAD,
but I think it's OK here as we can't really cover every possible
exception which might get raised in any module during a 'go hit
a server and do a bunch of stuff' operation, and if the error
keeps happening we *are* going to raise it eventually.
Test Plan:
Check I didn't break the 'normal' case, and try causing
an error to appear somehow (e.g. disconnect from the network or
hack up the 'client' instantiation in fedfind to use the wrong URL)
and see if the error handling works as intended.
Reviewers: garretraziel, jskladan
Reviewed By: garretraziel, jskladan
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D532
2015-08-27 22:51:15 +00:00
|
|
|
import fedfind.exceptions
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
import fedfind.release
|
2015-01-28 09:58:51 +00:00
|
|
|
|
2015-07-10 08:40:31 +00:00
|
|
|
from openqa_client.client import OpenQA_Client
|
2015-01-30 13:58:12 +00:00
|
|
|
from report_job_results import report_results
|
2015-01-27 15:02:14 +00:00
|
|
|
|
2015-01-29 09:08:05 +00:00
|
|
|
PERSISTENT = "/var/tmp/openqa_watcher.json"
|
|
|
|
ISO_PATH = "/var/lib/openqa/factory/iso/"
|
2015-08-16 01:10:50 +00:00
|
|
|
ARCHES = ['x86_64', 'i386']
|
2015-07-09 08:31:53 +00:00
|
|
|
|
|
|
|
|
|
|
|
class TriggerException(Exception):
|
|
|
|
pass
|
|
|
|
|
2015-01-27 15:02:14 +00:00
|
|
|
|
|
|
|
# read last tested version from file
|
|
|
|
def read_last():
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.debug("reading latest checked version from %s", PERSISTENT)
|
2015-01-28 09:58:51 +00:00
|
|
|
result = {}
|
2015-01-27 15:02:14 +00:00
|
|
|
try:
|
|
|
|
f = open(PERSISTENT, "r")
|
|
|
|
json_raw = f.read()
|
|
|
|
f.close()
|
|
|
|
json_parsed = json.loads(json_raw)
|
|
|
|
except IOError:
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.warning("cannot read file %s", PERSISTENT)
|
2015-01-28 09:58:51 +00:00
|
|
|
return result, {}
|
|
|
|
|
2015-07-09 08:31:53 +00:00
|
|
|
for arch in ARCHES:
|
|
|
|
result[arch] = json_parsed.get(arch, None)
|
|
|
|
logging.info("latest version for %s: %s", arch, result[arch])
|
2015-01-28 09:58:51 +00:00
|
|
|
return result, json_parsed
|
2015-01-27 15:02:14 +00:00
|
|
|
|
2015-07-09 08:31:53 +00:00
|
|
|
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
def download_image(image):
|
2015-03-18 21:51:01 +00:00
|
|
|
"""Download a given image with a name that should be unique.
|
|
|
|
Returns the filename of the image (not the path).
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
"""
|
2015-03-18 21:51:01 +00:00
|
|
|
ver = image.version.replace(' ', '_')
|
|
|
|
if image.imagetype == 'boot':
|
|
|
|
isoname = "{0}_{1}_{2}_boot.iso".format(ver, image.payload, image.arch)
|
|
|
|
else:
|
|
|
|
isoname = "{0}_{1}".format(ver, image.filename)
|
2015-01-28 09:58:51 +00:00
|
|
|
filename = os.path.join(ISO_PATH, isoname)
|
2015-01-30 13:58:12 +00:00
|
|
|
if not os.path.isfile(filename):
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.info("downloading %s (%s) to %s", image.url, image.desc, filename)
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
# Icky hack around a urlgrabber bug:
|
|
|
|
# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715416
|
|
|
|
urlgrabber.urlgrab(image.url.replace('https', 'http'), filename)
|
2015-07-09 08:31:53 +00:00
|
|
|
else:
|
|
|
|
logging.info("%s already exists", filename)
|
2015-01-29 09:08:05 +00:00
|
|
|
return isoname
|
2015-01-28 09:58:51 +00:00
|
|
|
|
2015-07-09 08:31:53 +00:00
|
|
|
|
2015-07-10 08:40:31 +00:00
|
|
|
def run_openqa_jobs(client, isoname, flavor, arch, build):
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
"""# run OpenQA 'isos' job on selected isoname, with given arch
|
2015-07-10 08:40:31 +00:00
|
|
|
and a version string. **NOTE**: the version passed to OpenQA as
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
BUILD and is parsed back into the 'relval report-auto' arguments
|
|
|
|
by report_job_results.py; it is expected to be in the form of a
|
|
|
|
3-tuple on which join('_') has been run, and the three elements
|
|
|
|
will be passed as --release, --compose and --milestone. Returns
|
|
|
|
list of job IDs.
|
|
|
|
"""
|
2015-07-10 08:40:31 +00:00
|
|
|
logging.info("sending jobs on OpenQA")
|
2015-01-28 09:58:51 +00:00
|
|
|
|
2015-01-29 09:08:05 +00:00
|
|
|
# starts OpenQA jobs
|
2015-07-10 08:40:31 +00:00
|
|
|
params = {
|
|
|
|
'ISO': isoname,
|
|
|
|
'DISTRI': 'fedora',
|
2015-08-21 06:48:26 +00:00
|
|
|
'VERSION': build.split('_')[0],
|
2015-07-10 08:40:31 +00:00
|
|
|
'FLAVOR': flavor,
|
|
|
|
'ARCH': arch,
|
|
|
|
'BUILD': build
|
|
|
|
}
|
|
|
|
output = client.openqa_request('POST', 'isos', params)
|
|
|
|
|
|
|
|
logging.debug("executed")
|
|
|
|
logging.info("planned jobs: %s", output["ids"])
|
2015-01-29 09:08:05 +00:00
|
|
|
|
2015-07-10 08:40:31 +00:00
|
|
|
return output["ids"]
|
2015-07-09 08:31:53 +00:00
|
|
|
|
2015-07-10 08:40:31 +00:00
|
|
|
|
|
|
|
def jobs_from_current(wiki, client):
|
2015-02-18 09:02:50 +00:00
|
|
|
"""Schedule jobs against the 'current' release validation event
|
drop 'all', add 'current' check and waiting to 'compose'
Summary:
This is an alternative to D516. It drops the 'all' subcommand
entirely and adds some capabilities to 'compose' to make it
suitable for scripting. --ifnotcurrent will check if the compose
is the same as the current validation event, and bail out if it
is. --wait waits for the compose to be available. I've also
enhanced fedfind (in 1.4.1) to allow passing just 'Branched'
as the milestone; it will guess the release and date, now (it
didn't before).
With all of that taken together, we could have three cron jobs,
one for 'current', one for 'branched', and one for 'rawhide'.
That way we don't have to do any clever multiprocess/round-robin
waiting stuff, and the jobs for each release will be run and
reported as fast as possible (and we can run the compose report
right after the trigger script and have that sent out
efficiently too).
Test Plan:
Try all the possibilities with 'compose' - especially
check that it works with just '-m Rawhide' and '-m Branched',
and that the --wait and --ifnotcurrent args work as intended.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D525
2015-08-24 18:38:50 +00:00
|
|
|
(according to wikitcms) if we have not already. Returns the job
|
|
|
|
list.
|
2015-02-18 09:02:50 +00:00
|
|
|
"""
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
if not wiki:
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.warning("python-wikitcms is required for current validation event discovery.")
|
2015-02-18 09:02:50 +00:00
|
|
|
return ([], None)
|
2015-01-29 09:08:05 +00:00
|
|
|
last_versions, json_parsed = read_last()
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
currev = wiki.current_event
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.info("current event: %s", currev.version)
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
runarches = []
|
2015-07-09 08:31:53 +00:00
|
|
|
for arch in ARCHES:
|
2015-01-29 09:08:05 +00:00
|
|
|
last_version = last_versions.get(arch, None)
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
if last_version and last_version >= currev.sortname:
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.info("skipped: %s: %s is newer or equal to %s",
|
|
|
|
arch, last_version, currev.sortname)
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
else:
|
|
|
|
runarches.append(arch)
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.debug("%s will be tested in version %s", arch, currev.sortname)
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
json_parsed[arch] = currev.sortname
|
2015-01-29 09:08:05 +00:00
|
|
|
|
2015-07-09 08:31:53 +00:00
|
|
|
jobs = []
|
2015-01-29 09:08:05 +00:00
|
|
|
|
2015-07-09 08:31:53 +00:00
|
|
|
try:
|
2015-07-10 08:40:31 +00:00
|
|
|
jobs = jobs_from_fedfind(currev.ff_release, client, runarches)
|
2015-08-10 18:14:37 +00:00
|
|
|
logging.info("planned jobs: %s", ' '.join(str(j) for j in jobs))
|
2015-07-09 08:31:53 +00:00
|
|
|
|
|
|
|
# write info about latest versions
|
|
|
|
f = open(PERSISTENT, "w")
|
|
|
|
f.write(json.dumps(json_parsed))
|
|
|
|
f.close()
|
|
|
|
logging.debug("written info about newest version")
|
|
|
|
except TriggerException as e:
|
|
|
|
logging.error("cannot run jobs: %s", e)
|
2015-02-18 10:33:45 +00:00
|
|
|
|
drop 'all', add 'current' check and waiting to 'compose'
Summary:
This is an alternative to D516. It drops the 'all' subcommand
entirely and adds some capabilities to 'compose' to make it
suitable for scripting. --ifnotcurrent will check if the compose
is the same as the current validation event, and bail out if it
is. --wait waits for the compose to be available. I've also
enhanced fedfind (in 1.4.1) to allow passing just 'Branched'
as the milestone; it will guess the release and date, now (it
didn't before).
With all of that taken together, we could have three cron jobs,
one for 'current', one for 'branched', and one for 'rawhide'.
That way we don't have to do any clever multiprocess/round-robin
waiting stuff, and the jobs for each release will be run and
reported as fast as possible (and we can run the compose report
right after the trigger script and have that sent out
efficiently too).
Test Plan:
Try all the possibilities with 'compose' - especially
check that it works with just '-m Rawhide' and '-m Branched',
and that the --wait and --ifnotcurrent args work as intended.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D525
2015-08-24 18:38:50 +00:00
|
|
|
return jobs
|
2015-02-18 09:02:50 +00:00
|
|
|
|
2015-07-09 08:31:53 +00:00
|
|
|
|
2015-07-10 08:40:31 +00:00
|
|
|
def jobs_from_fedfind(ff_release, client, arches=ARCHES):
|
2015-02-18 09:02:50 +00:00
|
|
|
"""Given a fedfind.Release object, find the ISOs we want and run
|
|
|
|
jobs on them. arches is an iterable of arches to run on, if not
|
|
|
|
specified, we'll use our constant.
|
|
|
|
"""
|
2015-03-18 21:51:01 +00:00
|
|
|
# Find currently-testable images for our arches.
|
2015-02-18 09:02:50 +00:00
|
|
|
jobs = []
|
|
|
|
queries = (
|
2015-03-18 21:51:01 +00:00
|
|
|
fedfind.release.Query('imagetype', ('boot', 'live')),
|
2015-02-18 09:02:50 +00:00
|
|
|
fedfind.release.Query('arch', arches),
|
2015-03-18 21:51:01 +00:00
|
|
|
fedfind.release.Query('payload', ('server', 'generic', 'workstation')))
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.debug("querying fedfind for images")
|
2015-03-18 21:51:01 +00:00
|
|
|
images = ff_release.find_images(queries)
|
|
|
|
|
2015-07-09 08:31:53 +00:00
|
|
|
if len(images) == 0:
|
|
|
|
raise TriggerException("no available images")
|
|
|
|
|
2015-03-18 21:51:01 +00:00
|
|
|
# Now schedule jobs. First, let's get the BUILD value for openQA.
|
2015-07-09 08:31:53 +00:00
|
|
|
build = '_'.join((ff_release.release, ff_release.milestone, ff_release.compose))
|
2015-03-18 21:51:01 +00:00
|
|
|
|
|
|
|
# Next let's schedule the 'universal' tests.
|
|
|
|
# We have different images in different composes: nightlies only
|
|
|
|
# have a generic boot.iso, TC/RC builds have Server netinst/boot
|
2015-07-09 08:31:53 +00:00
|
|
|
# and DVD. We always want to run *some* tests -
|
2015-03-18 21:51:01 +00:00
|
|
|
# default_boot_and_install at least - for all images we find, then
|
|
|
|
# we want to run all the tests that are not image-dependent on
|
|
|
|
# just one image. So we have a special 'universal' flavor and
|
|
|
|
# product in openQA; all the image-independent test suites run for
|
|
|
|
# that product. Here, we find the 'best' image we can for the
|
|
|
|
# compose we're running on (a DVD if possible, a boot.iso or
|
|
|
|
# netinst if not), and schedule the 'universal' jobs on that
|
|
|
|
# image.
|
|
|
|
for arch in arches:
|
|
|
|
okimgs = (img for img in images if img.arch == arch and
|
2015-07-09 08:31:53 +00:00
|
|
|
any(img.imagetype == okt for okt in ('dvd', 'boot', 'netinst')))
|
2015-03-18 21:51:01 +00:00
|
|
|
bestscore = 0
|
|
|
|
bestimg = None
|
|
|
|
for img in okimgs:
|
|
|
|
if img.imagetype == 'dvd':
|
|
|
|
score = 10
|
|
|
|
else:
|
|
|
|
score = 1
|
|
|
|
if img.payload == 'generic':
|
|
|
|
score += 5
|
|
|
|
elif img.payload == 'server':
|
|
|
|
score += 3
|
|
|
|
elif img.payload == 'workstation':
|
|
|
|
score += 1
|
|
|
|
if score > bestscore:
|
|
|
|
bestimg = img
|
|
|
|
bestscore = score
|
|
|
|
if not bestimg:
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.warn("no universal tests image found for %s", arch)
|
2015-03-18 21:51:01 +00:00
|
|
|
continue
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.info("running universal tests for %s with %s", arch, bestimg.desc)
|
2015-03-18 21:51:01 +00:00
|
|
|
isoname = download_image(bestimg)
|
2015-07-10 08:40:31 +00:00
|
|
|
job_ids = run_openqa_jobs(client, isoname, 'universal', arch, build)
|
2015-03-18 21:51:01 +00:00
|
|
|
jobs.extend(job_ids)
|
2015-02-18 09:02:50 +00:00
|
|
|
|
2015-03-18 21:51:01 +00:00
|
|
|
# Now schedule per-image jobs.
|
|
|
|
for image in images:
|
2015-02-18 09:02:50 +00:00
|
|
|
isoname = download_image(image)
|
2015-03-18 21:51:01 +00:00
|
|
|
flavor = '_'.join((image.payload, image.imagetype))
|
2015-07-10 08:40:31 +00:00
|
|
|
job_ids = run_openqa_jobs(client, isoname, flavor, image.arch, build)
|
2015-02-18 09:02:50 +00:00
|
|
|
jobs.extend(job_ids)
|
|
|
|
return jobs
|
|
|
|
|
2015-07-09 08:31:53 +00:00
|
|
|
|
|
|
|
# SUB-COMMAND FUNCTIONS
|
|
|
|
|
2015-02-18 09:02:50 +00:00
|
|
|
|
2015-07-10 08:40:31 +00:00
|
|
|
def run_current(args, client, wiki):
|
2015-02-18 09:02:50 +00:00
|
|
|
"""run OpenQA for current release validation event, if we have
|
|
|
|
not already done it.
|
|
|
|
"""
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.info("running on current release")
|
drop 'all', add 'current' check and waiting to 'compose'
Summary:
This is an alternative to D516. It drops the 'all' subcommand
entirely and adds some capabilities to 'compose' to make it
suitable for scripting. --ifnotcurrent will check if the compose
is the same as the current validation event, and bail out if it
is. --wait waits for the compose to be available. I've also
enhanced fedfind (in 1.4.1) to allow passing just 'Branched'
as the milestone; it will guess the release and date, now (it
didn't before).
With all of that taken together, we could have three cron jobs,
one for 'current', one for 'branched', and one for 'rawhide'.
That way we don't have to do any clever multiprocess/round-robin
waiting stuff, and the jobs for each release will be run and
reported as fast as possible (and we can run the compose report
right after the trigger script and have that sent out
efficiently too).
Test Plan:
Try all the possibilities with 'compose' - especially
check that it works with just '-m Rawhide' and '-m Branched',
and that the --wait and --ifnotcurrent args work as intended.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D525
2015-08-24 18:38:50 +00:00
|
|
|
jobs = jobs_from_current(wiki, client)
|
2015-01-29 09:08:05 +00:00
|
|
|
# wait for jobs to finish and display results
|
2015-02-18 09:02:50 +00:00
|
|
|
if jobs:
|
2015-08-10 18:14:37 +00:00
|
|
|
logging.info("waiting for jobs: %s", ' '.join(str(j) for j in jobs))
|
2015-07-10 08:40:31 +00:00
|
|
|
report_results(jobs, client)
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.debug("finished")
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
sys.exit()
|
2015-01-27 15:02:14 +00:00
|
|
|
|
2015-07-09 08:31:53 +00:00
|
|
|
|
2015-07-10 08:40:31 +00:00
|
|
|
def run_compose(args, client, wiki=None):
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
"""run OpenQA on a specified compose, optionally reporting results
|
2015-02-18 09:02:50 +00:00
|
|
|
if a matching wikitcms ValidationEvent is found by relval/wikitcms
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
"""
|
|
|
|
# get the fedfind release object
|
|
|
|
try:
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.debug("querying fedfind on specific compose: %s %s %s", args.release,
|
|
|
|
args.milestone, args.compose)
|
|
|
|
ff_release = fedfind.release.get_release(release=args.release, milestone=args.milestone,
|
|
|
|
compose=args.compose)
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
except ValueError as err:
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.critical("compose %s %s %s was not found", args.release, args.milestone,
|
|
|
|
args.compose)
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
sys.exit(err[0])
|
|
|
|
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.info("running on compose: %s", ff_release.version)
|
drop 'all', add 'current' check and waiting to 'compose'
Summary:
This is an alternative to D516. It drops the 'all' subcommand
entirely and adds some capabilities to 'compose' to make it
suitable for scripting. --ifnotcurrent will check if the compose
is the same as the current validation event, and bail out if it
is. --wait waits for the compose to be available. I've also
enhanced fedfind (in 1.4.1) to allow passing just 'Branched'
as the milestone; it will guess the release and date, now (it
didn't before).
With all of that taken together, we could have three cron jobs,
one for 'current', one for 'branched', and one for 'rawhide'.
That way we don't have to do any clever multiprocess/round-robin
waiting stuff, and the jobs for each release will be run and
reported as fast as possible (and we can run the compose report
right after the trigger script and have that sent out
efficiently too).
Test Plan:
Try all the possibilities with 'compose' - especially
check that it works with just '-m Rawhide' and '-m Branched',
and that the --wait and --ifnotcurrent args work as intended.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D525
2015-08-24 18:38:50 +00:00
|
|
|
|
|
|
|
if args.ifnotcurrent:
|
|
|
|
try:
|
|
|
|
currev = wiki.current_event
|
|
|
|
# Compare currev's fedfind release version with ours
|
|
|
|
if currev.ff_release.version == ff_release.version:
|
|
|
|
logging.info("Compose is the current validation compose. Exiting.")
|
|
|
|
sys.exit()
|
|
|
|
except AttributeError:
|
|
|
|
sys.exit("Wikitcms is required for --ifnotcurrent.")
|
|
|
|
|
|
|
|
if args.wait:
|
|
|
|
logging.info("Waiting up to %s mins for compose", str(args.wait))
|
handle errors while waiting for compose smartly
Summary:
So the first attempt to use the waiting stuff in production
failed because, at some point, koji_done got a socket.error
from the server. Not sure if that was a Koji outage or some
kind of rate control, but even if it's rate control and we need
to tweak the wait interval, this seems advisable: we shouldn't
die the first time we hit any kind of error while waiting, we
should retry a few times first (with increasingly long delays
between the retry attempts). I know bare except clauses are BAD,
but I think it's OK here as we can't really cover every possible
exception which might get raised in any module during a 'go hit
a server and do a bunch of stuff' operation, and if the error
keeps happening we *are* going to raise it eventually.
Test Plan:
Check I didn't break the 'normal' case, and try causing
an error to appear somehow (e.g. disconnect from the network or
hack up the 'client' instantiation in fedfind to use the wrong URL)
and see if the error handling works as intended.
Reviewers: garretraziel, jskladan
Reviewed By: garretraziel, jskladan
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D532
2015-08-27 22:51:15 +00:00
|
|
|
try:
|
|
|
|
ff_release.wait(waittime=args.wait)
|
|
|
|
except fedfind.exceptions.WaitError:
|
|
|
|
sys.exit("Waited too long for compose to appear!")
|
drop 'all', add 'current' check and waiting to 'compose'
Summary:
This is an alternative to D516. It drops the 'all' subcommand
entirely and adds some capabilities to 'compose' to make it
suitable for scripting. --ifnotcurrent will check if the compose
is the same as the current validation event, and bail out if it
is. --wait waits for the compose to be available. I've also
enhanced fedfind (in 1.4.1) to allow passing just 'Branched'
as the milestone; it will guess the release and date, now (it
didn't before).
With all of that taken together, we could have three cron jobs,
one for 'current', one for 'branched', and one for 'rawhide'.
That way we don't have to do any clever multiprocess/round-robin
waiting stuff, and the jobs for each release will be run and
reported as fast as possible (and we can run the compose report
right after the trigger script and have that sent out
efficiently too).
Test Plan:
Try all the possibilities with 'compose' - especially
check that it works with just '-m Rawhide' and '-m Branched',
and that the --wait and --ifnotcurrent args work as intended.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D525
2015-08-24 18:38:50 +00:00
|
|
|
|
2015-07-09 08:31:53 +00:00
|
|
|
jobs = []
|
|
|
|
try:
|
|
|
|
if args.arch:
|
2015-07-10 08:40:31 +00:00
|
|
|
jobs = jobs_from_fedfind(ff_release, client, [args.arch])
|
2015-07-09 08:31:53 +00:00
|
|
|
else:
|
2015-07-10 08:40:31 +00:00
|
|
|
jobs = jobs_from_fedfind(ff_release, client)
|
2015-07-09 08:31:53 +00:00
|
|
|
except TriggerException as e:
|
|
|
|
logging.error("cannot run jobs: %s", e)
|
2015-08-10 18:14:37 +00:00
|
|
|
logging.info("planned jobs: %s", ' '.join(str(j) for j in jobs))
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
if args.submit_results:
|
2015-07-10 08:40:31 +00:00
|
|
|
report_results(jobs, client)
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.debug("finished")
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
sys.exit()
|
|
|
|
|
2015-07-09 08:31:53 +00:00
|
|
|
|
2015-01-29 09:08:05 +00:00
|
|
|
if __name__ == "__main__":
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
test_help = "Operate on the staging wiki (for testing)"
|
|
|
|
parser = argparse.ArgumentParser(description=(
|
|
|
|
"Run OpenQA tests for a release validation test event."))
|
|
|
|
subparsers = parser.add_subparsers()
|
|
|
|
|
|
|
|
parser_current = subparsers.add_parser(
|
|
|
|
'current', description="Run for the current event, if needed.")
|
|
|
|
parser_current.set_defaults(func=run_current)
|
|
|
|
|
|
|
|
parser_compose = subparsers.add_parser(
|
|
|
|
'compose', description="Run for a specific compose (TC/RC or nightly)."
|
|
|
|
" If a matching release validation test event can be found and "
|
|
|
|
"--submit-results is passed, results will be reported.")
|
|
|
|
parser_compose.add_argument(
|
|
|
|
'-r', '--release', type=int, required=False, choices=range(12, 100),
|
|
|
|
metavar="12-99", help="Release number of a specific compose to run "
|
|
|
|
"against. Must be passed for validation event discovery to succeed.")
|
|
|
|
parser_compose.add_argument(
|
|
|
|
'-m', '--milestone', help="The milestone to operate on (Alpha, Beta, "
|
|
|
|
"Final, Branched, Rawhide). Must be specified for a TC/RC; for a "
|
|
|
|
"nightly, will be guessed if not specified", required=False,
|
|
|
|
choices=['Alpha', 'Beta', 'Final', 'Branched', 'Rawhide'])
|
|
|
|
parser_compose.add_argument(
|
|
|
|
'-c', '--compose', help="The version to run for; either the compose "
|
|
|
|
"(for a TC/RC), or the date (for a nightly build)", required=False,
|
|
|
|
metavar="{T,R}C1-19 or YYYYMMDD")
|
|
|
|
parser_compose.add_argument(
|
|
|
|
'-a', '--arch', help="The arch to run for", required=False,
|
|
|
|
choices=('x86_64', 'i386'))
|
|
|
|
parser_compose.add_argument(
|
|
|
|
'-s', '--submit-results', help="Submit the results to the release "
|
|
|
|
"validation event for this compose, if possible", required=False,
|
|
|
|
action='store_true')
|
drop 'all', add 'current' check and waiting to 'compose'
Summary:
This is an alternative to D516. It drops the 'all' subcommand
entirely and adds some capabilities to 'compose' to make it
suitable for scripting. --ifnotcurrent will check if the compose
is the same as the current validation event, and bail out if it
is. --wait waits for the compose to be available. I've also
enhanced fedfind (in 1.4.1) to allow passing just 'Branched'
as the milestone; it will guess the release and date, now (it
didn't before).
With all of that taken together, we could have three cron jobs,
one for 'current', one for 'branched', and one for 'rawhide'.
That way we don't have to do any clever multiprocess/round-robin
waiting stuff, and the jobs for each release will be run and
reported as fast as possible (and we can run the compose report
right after the trigger script and have that sent out
efficiently too).
Test Plan:
Try all the possibilities with 'compose' - especially
check that it works with just '-m Rawhide' and '-m Branched',
and that the --wait and --ifnotcurrent args work as intended.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D525
2015-08-24 18:38:50 +00:00
|
|
|
parser_compose.add_argument(
|
|
|
|
'-w', '--wait', help="Wait NN minutes for the compose to appear, if "
|
|
|
|
"it doesn't yet exist", type=int, metavar="NN", default=0,
|
|
|
|
required=False)
|
|
|
|
parser_compose.add_argument(
|
|
|
|
'-i', '--ifnotcurrent', help="Only run if the compose is not the "
|
|
|
|
"'current' validation compose. Mainly intended for cron runs on "
|
|
|
|
"nightly builds, to avoid duplicating jobs run by a 'current' "
|
|
|
|
"cron job. Requires wikitcms", action='store_true')
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
parser_compose.set_defaults(func=run_compose)
|
|
|
|
|
2015-07-09 08:31:53 +00:00
|
|
|
parser.add_argument(
|
|
|
|
'-t', '--test', help=test_help, required=False, action='store_true')
|
|
|
|
parser.add_argument(
|
|
|
|
'-f', '--log-file', help="If given, log into specified file. When not provided, stdout"
|
|
|
|
" is used", required=False)
|
|
|
|
parser.add_argument(
|
|
|
|
'-l', '--log-level', help="Specify log level to be outputted", required=False)
|
|
|
|
parser.add_argument('-i', '--iso-directory', help="Directory for downloading isos, default"
|
|
|
|
" is %s" % PERSISTENT, required=False)
|
|
|
|
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
args = parser.parse_args()
|
|
|
|
|
2015-07-09 08:31:53 +00:00
|
|
|
if args.log_level:
|
|
|
|
log_level = getattr(logging, args.log_level.upper(), None)
|
|
|
|
if not isinstance(log_level, int):
|
2015-07-29 12:31:05 +00:00
|
|
|
log_level = logging.INFO
|
2015-07-09 08:31:53 +00:00
|
|
|
else:
|
2015-07-29 12:31:05 +00:00
|
|
|
log_level = logging.INFO
|
2015-07-09 08:31:53 +00:00
|
|
|
if args.log_file:
|
|
|
|
logging.basicConfig(format="%(levelname)s:%(name)s:%(asctime)s:%(message)s",
|
|
|
|
filename=args.log_file, level=log_level)
|
|
|
|
else:
|
|
|
|
logging.basicConfig(level=log_level)
|
|
|
|
|
|
|
|
if args.iso_directory:
|
|
|
|
ISO_PATH = args.iso_directory
|
|
|
|
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
wiki = None
|
|
|
|
if args.test:
|
2015-07-09 08:31:53 +00:00
|
|
|
logging.debug("using test wiki")
|
|
|
|
if wikitcms:
|
|
|
|
wiki = wikitcms.wiki.Wiki(('https', 'stg.fedoraproject.org'), '/w/')
|
|
|
|
else:
|
|
|
|
logging.warn("wikitcms not found, reporting to wiki disabled")
|
2015-01-29 09:08:05 +00:00
|
|
|
else:
|
2015-07-09 08:31:53 +00:00
|
|
|
if wikitcms:
|
Use python-wikitcms and fedfind
The basic approach is that openqa_trigger gets a ValidationEvent from
python-wikitcms - either the Wiki.current_event property for
'current', or the event specified, obtained via the newly-added
Wiki.get_validation_event(), for 'event'. For 'event' it then just
goes ahead and runs the jobs and prints the IDs. For 'current' it
checks the last run compose version for each arch and runs if needed,
as before. The ValidationEvent's 'sortname' property is the value
written out to PERSISTENT to track the 'last run' - this property is
intended to always sort compose events 'correctly', so we should
always run when appropriate even when going from Rawhide to Branched,
Branched to a TC, TC to RC, RC to (next milestone) TC.
On both paths it gets a fedfind.Release object via the ValidationEvent
- ValidationEvents have a ff_release property which is the
fedfind.Release object that matches that event. It then queries
fedfind for image locations using a query that tries to get just *one*
generic-ish network install image for each arch. It passes the
location to download_image(), which is just download_rawhide_iso()
renamed and does the same job, only it can be simpler now.
From there it works pretty much as before, except we use the
ValidationEvent's 'version' property as the BUILD setting for OpenQA,
and report_job_results get_relval_commands() is tweaked slightly to
parse this properly to produce a correct report-auto command.
Probably the most likely bits to break here are the sortname thing
(see wikitcms helpers.py fedora_release_sort(), it's pretty stupid, I
should re-write it) and the image query, which might wind up getting
more than one image depending on how exactly the F22 Alpha composes
look. I'll keep a close eye on that. We can always take the list from
fedfind and further filter it so we have just one image per arch.
Image objects have a .arch attribute so this will be easy to do if
necessary. I *could* give the fedfind query code a 'I'm feeling lucky'-
ish mode to only return one image per (whatever), but not sure if that
would be too specialized, I'll think about it.
2015-02-16 17:01:58 +00:00
|
|
|
wiki = wikitcms.wiki.Wiki(('https', 'fedoraproject.org'), '/w/')
|
2015-07-09 08:31:53 +00:00
|
|
|
else:
|
|
|
|
logging.warn("wikitcms not found, reporting to wiki disabled")
|
2015-07-10 08:40:31 +00:00
|
|
|
|
|
|
|
client = OpenQA_Client() # uses first server from ~/.config/openqa/client.conf
|
|
|
|
|
|
|
|
args.func(args, client, wiki)
|