On Tue, 2017-04-18 at 06:35 -0600, Tim Flink wrote: > One of the things that seems like it is and will be a pain point for > folks writing package-specific tasks is how to work through the times > when there was an issue in the task and things didn't run well. At the > moment, the only solution we have is to re-build the affected package > or to pester an admin to re-run the trigger - neither of which is an > ideal answer. > > I was thinking about how to improve this in the near future and am > wondering about adding a "reschedule" button to execdb jobs: > > 1. authenticated user clicks on "reschedule" button > 2. execdb makes an api call to the buildmaster to find the parameters > which were used for that task > 3. using the data from 2), execdb starts a new job for just that > item and item type > > I'm not thrilled at the idea of code duplication here between trigger > and execdb but compared to figuring out a web interface for trigger, > this seems like a more tractable solution for the short/medium term. > > Thoughts?
Here's a Half-Baked Idea (tm): What about a thing that's basically a simple web service that allows FAS-authenticated people to trigger the sending of templated fedmsgs? This could be used in various workflows like this. For this case, we'd implement a fedmsg template which would basically say 'authenticated user X asks that you please re-run test Y in test system Z'. Then we could plug little bits of code into Bodhi, execdb, really anything else you like, which would provide a button which, when clicked, calls out to that web service to send the 'restart test' fedmsg. The test dispatchers for Taskotron, openQA etc. would then just need to listen out for such fedmsgs, and do whatever they felt appropriate: you could implement policy at the dispatcher level - ignore requests from users without certain attributes (or even stash them for manual review, or something), accept requests from other users with different priorities, stuff like that. For feedback...well, if the test *did* get restarted, a fedmsg will naturally be emitted which the requesting system could listen out for, and if the scheduler decided to reject or sideline the request, it could emit a fedmsg saying it had done so. OK, like I said, half-baked =) But wdyt? -- 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 To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
