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
