On Wed, 2017-03-01 at 11:18 -0500, Kamil Paral wrote: > So my first thought was to recommend you to also publish just > type=koji_build results and finish this transition. But then I > realized that's wrong. OpenQA operates completely different than the > aforementioned tasks do. We operate on builds, and can distinguish > which build is causing issues. Collating them into bodhi_update > results is just a convenience measure for the consumer. But you > operate on the whole update as a set. You can't distinguish which > build of the update caused the issues, you just know that some of > them did. So the smallest unit for you is bodhi update, and you > should report results as such.
Yes, exactly. > The way forward is, I believe, to extend Bodhi to query both > type=koji_build for all included builds and collate the results (if > needed), and also query type=bodhi_update and shows those results as > well. Because different tasks operate on different type of data, > which influences how they publish the results. And both use cases are > valid. Yep, again, this is what I was expecting to do. > There's one important thing we need to do first, though. Bodhi ID > doesn't identify the thing tested uniquely, because Bodhi updates are > mutable (and the ID is kept). So Bodhi (or any gating tools) can't > rely on just retrieving the latest result for a particular Bodhi ID > and trust that result. It might be old and no longer reflect the > current state. We need to extend bodhi_update results with > "timestamp" key in extra data, that will report the "last_modified" > time of the Bodhi update tested. And Bodhi (or any other tool) must > not only query for item=$bodhi_id&type=bodhi_update, but also for > ×tamp=$timestamp. Only with this we can be sure we've really > tested particular Bodhi update. I'm not so sure it's really necessary, and doing it is actually tricky for openQA. Only the openQA job itself knows what packages it actually tested, and it doesn't have an easy way to get the associated timestamp. The scheduler could easily get the timestamp at the time the job was created, or at the time the job completed, but that will never be 100% reliable, because the job actually goes and does the download somewhere in between those two times. The job can - and already does - log the exact packages it actually got, but I don't think there's an easy way for it to take the 'last_modified' date for the update at the time it does the download. OTOH, I don't think it's really too bad just to show the 'most recent' results. That should usually only be out of date for a few minutes after an update is edited. It might be possible to do a 'tests running...' spinner when there are jobs scheduled or running for the update in question, even. -- 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
