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
