Re: openqa_fedora_tools patch: add 'all' mode
On Wed, 2015-02-18 at 10:59 -0800, Adam Williamson wrote: > On Wed, 2015-02-18 at 05:33 -0500, Josef Skladanka wrote: > > I'd really love to see some more comments in you code, which is > > using the wikitcms/relval internal attributes and so on (it gets > > somewhat wild in places). > > One further note on this, in case it isn't obvious. Now fedfind, > relval, and wikitcms have a unified approach to versioning in all > cases - we always use the 'release, milestone, compose' concept - I > intend for it always to be OK to take a 'release, milestone, > compose' from fedfind and throw it at wikitcms or relval, and vice > versa. To add another design note here (sorry if I'm boring people to tears): The overall flow of the openqa_fedora_tools/Wikitcms integration is that openqa runs on *images*, then can tell Wikitcms 'hey, I have some results for an image with this release, milestone and compose, can you do something with them?' and it's Wikitcms' job to figure out if it can do anything useful with those results. At present it can only do anything useful if it can find a release validation event whose version matches the image version, but that's not *inevitable*. As I suggested at the meeting this week we could, for instance, invent a new type of result page and hence python-wikitcms 'event', for storing automated test results for non-nominated nightly composes. This means there's a rather funny workflow for the 'current validation event' case: 1. OpenQA asks python-wikitcms to find the 'current validation event' 2. OpenQA asks python-wikitcms for the fedfind Release object that matches the event 2. OpenQA asks fedfind for the images from that 'Release' and tests them 3. OpenQA asks relval to report results for 'the validation event that matches the version of these images I just ran some tests on' 4. python-wikitcms does more or less the reverse of what fedfind did back at step 3, and finds (surprise surprise!) that there is a 'matching' validation event, and reports results for that In most cases the release, milestone, compose attributes for both the python-wikitcms and fedfind objects are actually identical, so they just get thrown around a few times and nothing remarkable happens. But for the special case of Rawhide nightlies, at steps 2 and 3/4, fedfind and python-wikitcms have to twiddle with the version attributes a bit: At step 2, python-wikitcms asks fedfind for a Release object for the ValidationEvent whose version attributes are "release: 22, milestone: Rawhide, compose: 20150207" (for instance). fedfind.release.get_release() translates this to a Release with the version attributes "release: Rawhide, milestone: '', compose: 20150207", which is appropriate for fedfind. The fedfind Image objects inherit those attributes. At step 3, OpenQA uses the fedfind Image version attributes, so it runs : relval report-auto --release "Rawhide" --milestone "" --compose "20150207" ... and python-wikitcms wiki.Wiki.get_validation_page() has to do the opposite of the conversion fedfind did: it converts 'release: Rawhide, milestone: '', compose: 20150207' back to 'release: 22, milestone: Rawhide, compose: 20150207' and finds the correct ValidationEvent. All of this is a bit baroque, but still I think actually the best way to do it given the constraints of the system and the information available: * We don't want circular deps between wikitcms and fedfind so fedfind can find the 'current validation event' itself (and then what? the Image objects for Rawhide nightly composes 'nominated for testing' would have different version attributes from the Image objects for Rawhide nightly composes *not* 'nominated for testing'?) * I don't want to remove openqa's ability to run against non-event images (which would allow us to tie it strongly to *event* versioning rather than *image* versioning). The concept of a 'validation event' is really one that's kind of bound up with manual testing, it's not an appropriate concept to tie an automatic testing system to. * We *could* special case openqa so that when it knows it's running for a specific validation event it uses the event's 'version' as the BUILD, not the image's 'version'. That would avoid the double conversion for Rawhide nightlies. But every time I write it that way, it just seems wrong. And it would mean that if the current validation event was '22 Rawhide 20150207' and you ran: openqa_trigger.py current openqa_trigger.py --release 22 --milestone Rawhide --compose 20150207 then the two sets of jobs would have *different* BUILD identifiers, which seems wrong. * I don't see a way to get openqa to run against TC/RC images using only fedfind, *without* openqa or fedfind asking python-wikitcms to find 'events' for it. It would be pretty ugly to teach fedfind to scrape stage/ so you could ask it for TCs/RCs that currently 'exist'. Unless releng is providing the information in a sanely-consumable format s
Re: openqa_fedora_tools patch: add 'all' mode
On Wed, 2015-02-18 at 10:06 -0800, Adam Williamson wrote: > On Wed, 2015-02-18 at 09:53 -0800, Adam Williamson wrote: > > > > Patch attached which more or less brings it to my intended > > version, with !='s and get_release() exception handling added and > > your cleanups preserved. sorry for the mixup! Consider the > > previous version an example of my personal kinds of silly thinkos > > that get fixed up when I first test the code :P > > Gack, that patch had another stray parser_current.set_defaults() > line in it. Here's a copy with that taken out. So to update people on current status - jskladan has merged this (thanks!). I cut releases of fedfind, wikitcms and relval with all the necessary changes to back the current openqa bits the day before yesterday. So all the bits are currently in a fairly clean and consistent state. I have qa-01 running latest git of everything and a cron job that runs 'all' at 8am every day (that's one hour after a cron job on one of my boxes runs 'relval nightly -i' to nominate a new nightly if needed). It also has fedmsg installed from pypi, but I hadn't done anything with it yet. That's about all I've done to it that's notable. So I'm fine with qa-01 being turned into a production box now if that's what needs doing. I don't have another dev environment, but if I want to work on any further changes I can set one up locally, and there's nothing that I *need* to do right now, the current code should be perfectly usable. It would be fine to have either 'current' or 'all' as the regular job for our production instance, I believe. Results for images for which wikitcms can't find an associated release validation event do not go anywhere, at present, they just sit in OpenQA, but we can always examine them from there. Whether you use 'current' or 'all', it should always wind up running on the images for new validation events the first time it's run after the event is created, and reporting results to the wiki; it should handle the switchover from nightlies to TCs/RCs for the 'validation events' cleanly with no manual intervention required, at least if I lined all the bits up right. :) I set up 'colada' as another account for my own tinkering just to make it clear where results from my dev code came from. The password for that account is in the ~/.fedora/credentials file for both 'projectqa' and 'root'. We can always use it for similar purposes in future. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: openqa_fedora_tools patch: add 'all' mode
On Wed, 2015-02-18 at 05:33 -0500, Josef Skladanka wrote: > I'd really love to see some more comments in you code, which is > using the wikitcms/relval internal attributes and so on (it gets > somewhat wild in places). One further note on this, in case it isn't obvious. Now fedfind, relval, and wikitcms have a unified approach to versioning in all cases - we always use the 'release, milestone, compose' concept - I intend for it always to be OK to take a 'release, milestone, compose' from fedfind and throw it at wikitcms or relval, and vice versa. This is why the 'all' patch incidentally dropped the 'sanity check' in run_compose; it was really just duplicating wikitcms work (it was kind of a hangover from an implementation when I still had openqa doing some 'conversion' of version attributes between fedfind and wikitcms approaches). Broadly I intend that it should always be safe to run the report_results() function from report_job_results.py on any OpenQA job whose 'BUILD' is a (release, milestone, compose) tuple that's been run through '_'.join() - even if the (release, milestone, compose) attributes come from fedfind not wikitcms. It's wikitcms' job to figure out if there's a 'validation event' which matches. This should be safe because 'relval report-auto' runs through the get_validation_page() wikitcms method which has all the guessing logic in it (principally for handling the tricky 'Rawhide nightly' case). relval will report against the correct event if wikitcms can find it; if there's no corresponding event relval will fail harmlessly, saying it couldn't find a corresponding event. openqa_fedora_tools doesn't really have to worry about all the details, all it needs to do is make sure it sets the 'BUILD' property for each job correctly. If we ever hit a case where relval reports against the wrong event, or doesn't find a corresponding event for a fedfind (release, milestone, compose) triplet when it should, that should be considered a bug in wikitcms (or possibly fedfind or even relval, but not the openqa stuff). In the 'all' mode at present we have to guess a release number for the day's Branched compose, because fedfind won't do it. We just use the 'release' attribute of the current validation event for this purpose. In practice this is pretty robust; I can't think of a time when this will do the wrong thing. It's *possible* to make fedfind discover the Branched release number, but it's pretty icky. It would have to grab the HTML of http://kojipkgs.fedoraproject.org/mash/branched-20150218/ (or whatever date you wanted) and find the subdirectory whose name is a number (with a regex match or whatever), then make that the 'release'. I kinda found that too icky when I was first writing fedfind and refused to do it, but I *may* go ahead and do it now on the basis that requiring callers to know what the current Branched release number is, or guess it from the wikitcms 'current_compose' or 'current_event' in order to pass it to fedfind, is also a bit inconvenient, I guess. Opinions on this would be welcome... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: openqa_fedora_tools patch: add 'all' mode
On Wed, 2015-02-18 at 09:53 -0800, Adam Williamson wrote:
>
> Patch attached which more or less brings it to my intended version,
> with !='s and get_release() exception handling added and your
> cleanups preserved. sorry for the mixup! Consider the previous
> version an example of my personal kinds of silly thinkos that get
> fixed up when I first test the code :P
Gack, that patch had another stray parser_current.set_defaults() line
in it. Here's a copy with that taken out.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
From 8a95ff8494343cc10d869af64aded16202e11972 Mon Sep 17 00:00:00 2001
From: Adam Williamson
Date: Wed, 18 Feb 2015 09:48:30 -0800
Subject: [PATCH] 'all' sub-command cleanup and bugfix
The patch jskladan applied was an older broken one I sent
accidentally; apologies. This is more or less my intended
version, with some of the cleanups from jskladan preserved
and a couple of his suggestions added (!= instead of not ==,
and a bit of just-in-case exception handling).
---
tools/openqa_trigger/openqa_trigger.py | 61 +++---
1 file changed, 41 insertions(+), 20 deletions(-)
diff --git a/tools/openqa_trigger/openqa_trigger.py b/tools/openqa_trigger/openqa_trigger.py
index a390d34..cce5dad 100755
--- a/tools/openqa_trigger/openqa_trigger.py
+++ b/tools/openqa_trigger/openqa_trigger.py
@@ -169,32 +169,49 @@ def run_compose(args, wiki=None):
sys.exit()
def run_all(args, wiki=None):
-"""Do everything we can: test both Rawhide and Branched nightlies
-if they exist, and test current compose if it's different from
-either and it's new.
+"""Do everything we can: test current validation event compose if
+it's new, amd test both Rawhide and Branched nightlies if they
+exist and aren't the same as the 'current' compose.
"""
-skip = None
+skip = ''
+
+# Run for 'current' validation event.
(jobs, currev) = jobs_from_current(wiki)
print("Jobs from current validation event: {0}".format(jobs))
-yesterday = datetime.datetime.utcnow() - datetime.timedelta(days=1)
-if currev and currev.compose == yesterday.strftime('%Y%m%d'):
+utcdate = datetime.datetime.utcnow()
+if args.yesterday:
+utcdate = utcdate - datetime.timedelta(days=1)
+if currev and currev.compose == utcdate.strftime('%Y%m%d'):
+# Don't schedule tests for the same compose as both "today's
+# nightly" and "current validation event"
skip = currev.milestone
-if not skip.lower() == 'rawhide':
-rawhide_ffrel = fedfind.release.get_release(
-release='Rawhide', compose=yesterday)
-rawjobs = jobs_from_fedfind(rawhide_ffrel)
-print("Jobs from {0}: {1}".format(rawhide_ffrel.version, rawjobs))
-jobs.extend(rawjobs)
-
-if not skip.lower() == 'branched':
-branched_ffrel = fedfind.release.get_release(
-release=currev.release, compose=yesterday)
-branchjobs = jobs_from_fedfind(branched_ffrel)
-print("Jobs from {0}: {1}".format(branched_ffrel.version, branchjobs))
-jobs.extend(branchjobs)
+# Run for day's Rawhide nightly (if not same as current event.)
+if skip.lower() != 'rawhide':
+try:
+rawhide_ffrel = fedfind.release.get_release(
+release='Rawhide', compose=utcdate)
+rawjobs = jobs_from_fedfind(rawhide_ffrel)
+print("Jobs from {0}: {1}".format(rawhide_ffrel.version, rawjobs))
+jobs.extend(rawjobs)
+except ValueError as err:
+print("Rawhide image discovery failed: {0}".format(err))
+# Run for day's Branched nightly (if not same as current event.)
+# We must guess a release for Branched, fedfind cannot do so. Best
+# guess we can make is the same as the 'current' validation event
+# compose (this is why we have jobs_from_current return currev).
+if skip.lower() != 'branched':
+try:
+branched_ffrel = fedfind.release.get_release(
+release=currev.release, milestone='Branched', compose=utcdate)
+branchjobs = jobs_from_fedfind(branched_ffrel)
+print("Jobs from {0}: {1}".format(branched_ffrel.version,
+ branchjobs))
+jobs.extend(branchjobs)
+except ValueError as err:
+print("Branched image discovery failed: {0}".format(err))
if jobs:
report_results(jobs)
sys.exit()
@@ -241,7 +258,11 @@ if __name__ == "__main__":
parser_all = subparsers.add_parser(
'all', description="Run for the current validation event (if needed) "
-"and today's Rawhide and Branched nightly's (if found).")
+"and today's Rawhide and Branched nightly's (if found). 'Today' is "
+"calculated for the UTC time zone, no matter the system timezone.")
+p
Re: openqa_fedora_tools patch: add 'all' mode
On Wed, 2015-02-18 at 05:33 -0500, Josef Skladanka wrote:
> Adam,
>
> the run_all code does not really make much sense to me, to be
> honest. After some minor cleanup, the code looks like this:
>
> 171 def run_all(args, wiki=None):
> 172 """Do everything we can: test both Rawhide and Branched
> nightlies
> 173 if they exist, and test current compose if it's different
> from 174 either and it's new.
> 175 """
> 176 skip = None
> 177 (jobs, currev) = jobs_from_current(wiki)
> 178 print("Jobs from current validation event:
> {0}".format(jobs)) 179
> 180 yesterday = datetime.datetime.utcnow() -
> datetime.timedelta(days=1)
> 181 if currev and currev.compose ==
> yesterday.strftime('%Y%m%d'): 182 skip = currev.milestone
> 183
> 184 if not skip.lower() == 'rawhide':
> 185 rawhide_ffrel = fedfind.release.get_release(
> 186 release='Rawhide', compose=yesterday)
> 187 rawjobs = jobs_from_fedfind(rawhide_ffrel)
> 188 print("Jobs from {0}: {1}".format(rawhide_ffrel.version,
> rawjobs))
> 189 jobs.extend(rawjobs)
> 190
> 191 if not skip.lower() == 'branched':
> 192 branched_ffrel = fedfind.release.get_release(
> 193 release=currev.release, compose=yesterday)
> 194 branchjobs = jobs_from_fedfind(branched_ffrel)
> 195 print("Jobs from {0}:
> {1}".format(branched_ffrel.version, branchjobs))
> 196 jobs.extend(branchjobs)
> 197
> 198 if jobs:
> 199 report_results(jobs)
> 200 sys.exit()
>
>
> Which on lines:
> 177-178: Runs the OpenQA jobs for "current" event
> 180: Creates a yesterday's date (formerly done on three lines
> in a weird way)
> 181-182: IIUIC checks whether the "current" compose is from
> yesterday, and if so, then sets skip to either Rawhide or Branched
> 184&191: Fails terribly, when the if-clause on 181 was False
> (because skip equals None in that case) => no job results will be
> reported to wiki matrices
Whoops - I've somehow sent an older version of the patch. Which is odd
because I was using the same file to apply on qa-01. I fixed all of
the above in the next rev. Looks like I had copies of the patch lying
in two directories and I sent the wrong one :(
The 'yesterday' thing is intended to be conditional on a --yesterday
parameter (it's basically a hack for the fact that at the time I was
testing it, the 02-18 nightly compose hadn't finished, but I figured
I'd leave it in as an option because you might hit that scenario
again). Though you're right about doing it more efficiently, dunno how
I wound up with it the silly way it was.
In the latest version skip is initially set to ''. :)
> Also, it is kind of non-clear at the first read, that what
> it does is basically "when you should not skip rawhide, run jobs for
> rawhide and do the same for branched".
> I'd much rather see something like `if skip.lower() !=
> 'rawhide':` and with a proper comment
I'd already added the comments in the latest version. I tend to have
'not ==' rather than '!=' as a tic, not sure why, I don't mind
changing it at all.
> I'm not really sure how the whole 181 if clause works, and why is it
> evidently always True, since you have not encountered the error.
I did encounter the error, don't worry ;)
The point of the clause is a scenario that was actually true
yesterday: the case where one of the day's nightly builds is also the
'current validation event'. Yesterday, 22 Branched 20150217 was both
the 'current validation event' and the day's nightly Branched compose.
It would be wasteful to run jobs for it twice. So what that clause
does is check if the 'compose' for the current event is the same date
as the date we're testing nightlies for (utcdate); if it is, we check
what 'milestone' the current event is for and skip running the nightly
jobs for that milestone, since they're probably (really, certainly)
the same thing.
When I was testing it would do this: find that the current event is
'22 Branched 20150217', run against that (or skip if it had already
done so in a previous test), figure out 'utcdate', realize that it was
20150217 - the same as the current event - read out 'Branched' as the
current event's milestone, set 'skip' to 'branched', and therefore not
schedule any 'branchjobs'.
It could print a message when it skips a nightly for this reason, but
you can actually already tell, because it won't print a "Jobs from:"
message for that nightly. Unless it's skipped it will always print
such a message, even when there are no jobs.
> Also, you mention a --yesterday parameter, which I have not really
> found in the code.
Yeah, later version :/
> I pushed the slightly polished code to the repos, so make sure to
> pull :)
Whoops, please don't push stuff it it seems broken, I trust your
review :) I'm attaching a patch on top of your last commit which
should clean things up.
> I'd re
Re: openqa_fedora_tools patch: add 'all' mode
Adam,
the run_all code does not really make much sense to me, to be honest.
After some minor cleanup, the code looks like this:
171 def run_all(args, wiki=None):
172 """Do everything we can: test both Rawhide and Branched nightlies
173 if they exist, and test current compose if it's different from
174 either and it's new.
175 """
176 skip = None
177 (jobs, currev) = jobs_from_current(wiki)
178 print("Jobs from current validation event: {0}".format(jobs))
179
180 yesterday = datetime.datetime.utcnow() - datetime.timedelta(days=1)
181 if currev and currev.compose == yesterday.strftime('%Y%m%d'):
182 skip = currev.milestone
183
184 if not skip.lower() == 'rawhide':
185 rawhide_ffrel = fedfind.release.get_release(
186 release='Rawhide', compose=yesterday)
187 rawjobs = jobs_from_fedfind(rawhide_ffrel)
188 print("Jobs from {0}: {1}".format(rawhide_ffrel.version, rawjobs))
189 jobs.extend(rawjobs)
190
191 if not skip.lower() == 'branched':
192 branched_ffrel = fedfind.release.get_release(
193 release=currev.release, compose=yesterday)
194 branchjobs = jobs_from_fedfind(branched_ffrel)
195 print("Jobs from {0}: {1}".format(branched_ffrel.version,
branchjobs))
196 jobs.extend(branchjobs)
197
198 if jobs:
199 report_results(jobs)
200 sys.exit()
Which on lines:
177-178: Runs the OpenQA jobs for "current" event
180: Creates a yesterday's date (formerly done on three lines in a weird
way)
181-182: IIUIC checks whether the "current" compose is from yesterday, and if
so, then sets skip to either Rawhide or Branched
184&191: Fails terribly, when the if-clause on 181 was False (because skip
equals None in that case) => no job results will be reported to wiki matrices
Also, it is kind of non-clear at the first read, that what it does is
basically "when you should not skip rawhide, run jobs for rawhide and do the
same for branched".
I'd much rather see something like `if skip.lower() != 'rawhide':`
and with a proper comment
I'm not really sure how the whole 181 if clause works, and why is it evidently
always True, since you have not encountered the error.
Also, you mention a --yesterday parameter, which I have not really found in the
code.
I pushed the slightly polished code to the repos, so make sure to pull :)
I'd really love to see some more comments in you code, which is using the
wikitcms/relval internal attributes and so on (it gets somewhat wild in places).
Please have a look at the run_all() method and:
* make sure that it handles the possible exceptions (please really do _not_
use empty except clause, it is the root of all evil)
* document the if-clause on #181 and what it means
Thanks,
Josef
----- Original Message -
> From: "Adam Williamson"
> To: qa-devel@lists.fedoraproject.org
> Sent: Wednesday, February 18, 2015 9:24:17 AM
> Subject: openqa_fedora_tools patch: add 'all' mode
>
> This adds an 'all' mode which runs for the current validation event
> compose if it hasn't already been done, then runs for the current
> date's Rawhide and Branched nightlies, if they exist and aren't the
> same as the current validation event. Has a --yesterday parameter to
> run on the nightlies from a day earlier instead, if your timezone /
> cron config don't hook up great with releng's. (In future we ought to
> have a daemon that listens for compose events from fedmsg or
> something). 'Today' and 'yesterday' are calculated in UTC.
>
> Right now the non-'validation event' results are just going to sit in
> OpenQA, but I have Grand Plans to get 'em out via fedmsg and/or
> special wiki pages. For now only folks with VPN access or their own
> Coconut instance will be able to see the results, sorry!
>
> We *may* wind up running the tests for a nominated nightly compose
> twice - once before it gets nominated, once after - but that doesn't
> seem like a huge problem. Obviously we ought to build one Glorious
> Unified Sausage Machine for nightlies which pre-flights 'em via OpenQA
> then does the nomination if that passes, but for now this is fine, I
> think.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
> ___
> qa-devel mailing list
> qa-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/qa-devel
>
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel
openqa_fedora_tools patch: add 'all' mode
This adds an 'all' mode which runs for the current validation event
compose if it hasn't already been done, then runs for the current
date's Rawhide and Branched nightlies, if they exist and aren't the
same as the current validation event. Has a --yesterday parameter to
run on the nightlies from a day earlier instead, if your timezone /
cron config don't hook up great with releng's. (In future we ought to
have a daemon that listens for compose events from fedmsg or
something). 'Today' and 'yesterday' are calculated in UTC.
Right now the non-'validation event' results are just going to sit in
OpenQA, but I have Grand Plans to get 'em out via fedmsg and/or
special wiki pages. For now only folks with VPN access or their own
Coconut instance will be able to see the results, sorry!
We *may* wind up running the tests for a nominated nightly compose
twice - once before it gets nominated, once after - but that doesn't
seem like a huge problem. Obviously we ought to build one Glorious
Unified Sausage Machine for nightlies which pre-flights 'em via OpenQA
then does the nomination if that passes, but for now this is fine, I
think.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
From d211b7ed4a284688f37152bad2f5bd7fbfd77813 Mon Sep 17 00:00:00 2001
From: Adam Williamson
Date: Tue, 17 Feb 2015 23:24:08 -0800
Subject: [PATCH] add an 'all' mode to try and run against everything we can
---
tools/openqa_trigger/openqa_trigger.py | 135 +
1 file changed, 86 insertions(+), 49 deletions(-)
diff --git a/tools/openqa_trigger/openqa_trigger.py b/tools/openqa_trigger/openqa_trigger.py
index 9a43b6c..4f43ed4 100755
--- a/tools/openqa_trigger/openqa_trigger.py
+++ b/tools/openqa_trigger/openqa_trigger.py
@@ -8,6 +8,7 @@ import os.path
import sys
import subprocess
import argparse
+import datetime
# We can at least find images and run OpenQA jobs without wikitcms
try:
import wikitcms.wiki
@@ -77,12 +78,15 @@ def run_openqa_jobs(isoname, arch, image_version):
else:
return []
-# run OpenQA on current compose if it is newer version since last run
-def run_current(args, wiki):
+def jobs_from_current(wiki):
+"""Schedule jobs against the 'current' release validation event
+(according to wikitcms) if we have not already. Returns a tuple,
+first value is the job list, second is the current event.
+"""
if not wiki:
-sys.exit("python-wikitcms is required for --current. Try "
- "--compose to run against today's Rawhide nightly "
- "without wiki result submission.")
+print("python-wikitcms is required for current validation event "
+ "discovery.")
+return ([], None)
last_versions, json_parsed = read_last()
currev = wiki.current_event
print("Current event: {0}".format(currev.version))
@@ -101,14 +105,49 @@ def run_current(args, wiki):
f.write(json.dumps(json_parsed))
f.close()
+return (jobs, currev)
+
+def jobs_from_fedfind(ff_release, arches=VERSIONS):
+"""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.
+"""
+# Find boot.iso images for our arches; third query is a bit of a
+# bodge till I know what 22 TCs/RCs will actually look like,
+# ideally we want a query that will reliably return one image per
+# arch without us having to filter further, but we can always just
+# take the first image for each arch if necessary
+jobs = []
+queries = (
+fedfind.release.Query('imagetype', ('boot',)),
+fedfind.release.Query('arch', arches),
+fedfind.release.Query('payload', ('server', 'generic')))
+
+for image in ff_release.find_images(queries):
+print("{0} {1}".format(image.url, image.desc))
+isoname = download_image(image)
+version = '_'.join(
+(ff_release.release, ff_release.milestone, ff_release.compose))
+job_ids = run_openqa_jobs(isoname, image.arch, version)
+jobs.extend(job_ids)
+return jobs
+
+## SUB-COMMAND FUNCTIONS
+
+def run_current(args, wiki):
+"""run OpenQA for current release validation event, if we have
+not already done it.
+"""
+jobs = jobs_from_current(wiki)[0]
# wait for jobs to finish and display results
-print jobs
-report_results(jobs)
+if jobs:
+print jobs
+report_results(jobs)
sys.exit()
def run_compose(args, wiki=None):
"""run OpenQA on a specified compose, optionally reporting results
-if a matching wikitcms ValidationEvent can be found.
+if a matching wikitcms ValidationEvent is found by relval/wikitcms
"""
# get the fedfind release object
try:
@@ -118,26 +157,6 @@ def run_compose(args, wiki=None):
except Valu
