On Fri, 2015-02-13 at 04:47 -0800, Adam Williamson wrote: > OK, I completed my fedfind/wikitcms conversion patch for > openqa_fedora_tools. I also fixed up some of the test case > submission data bits - they broke with relval report-auto (instead > of jskladan's version of non-interactive result submission) because > they didn't quite grok the 'test instance' concept report-auto > follows.
Here's a follow-up (applies on top of the previous three) with my latest work. This revises the openqa bits to take advantage of all the consolidation of version handling across wikitcms/relval/fedfind. This gives us some cool advantages for openqa. The 'current' command works just as before, basically. All the fun is in 'compose'. compose now basically just asks fedfind for images for the release you specify - there's lots of magic guessing now, so you can be sloppy with what you pass to some extent (calling it with no parameters at all tries to run on nightlies for today's date, for e.g.). If you pass --submit-results it does a sanity check to see if it can find a matching wikitcms validation event and disables result submission if not (this isn't really strictly *necessary*, but it seems polite). If it does find a matching validation event and you pass --submit-results, it'll go ahead and submit results at the end. In 'compose', all wikitcms use is optional - you should be able to use it without wikitcms at all, and it'll still run the OpenQA jobs. Both 'current' and 'compose' now use the fedfind.Image.version attribute for identification. For all composes except Rawhide nightlies, this should always be a 'RELEASE MILESTONE COMPOSE' string which we can parse right back into relval parameters, just as with the wikitcms.ValidationEvent.version attribute from the previous commit. For Rawhide nightlies it will be 'Rawhide COMPOSE' (with COMPOSE as a date, obviously), and there's a special case in report_job_results.py to handle that - bit inelegant, but it'll do for now. With this you can absolutely trivially have a bot that runs on Rawhide every day: it should just run 'openqa_trigger.py compose' every day at some point after the compose is usually finished. A bot that tries to run on Branched every day is a bit trickier, because fedfind can't guess Branched. The way I've hooked everything up we can't really have wikitcms do it either, because I made wikitcms' guessing only guess events that exist (which makes sense for wikitcms). We could put a quick hack in openqa_trigger which tries to get the current release from the Wiki and uses that, I'll think about how hacky that would be. Otherwise of course you just have to write a cronjob that passes --release and remember to update it with each new Branched release. Hope this is useful! I'm thinking about whether it's worth setting up a special category for non-nominated nightly composes on the wiki for long-term storage of Coconut results for non-nominated nightlies - it wouldn't be too hard to add such a thing to wikitcms and have openqa report to it. But maybe we can go a bit slow and see how it goes for now. I'd also like to get into the 'needle' stuff and try to make it do useful things on failure, like running through the crash submission procedure when it hits a crash, then filing a 'fail' report linked to the bug. This version of openqa_fedora_tools, along with the latest git fedfind and wikitcms and relval that are needed to use it, is in place on fedora-qa-01 for those with access. Maybe I'll set up some cronjobs on qa-01 tomorrow with a FAS account called 'colada'...:) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ qa-devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/qa-devel
