On Thu, 2017-03-02 at 18:08 -0800, Adam Williamson wrote:
It's also the case for listing openQA results in Bodhi:
we'll want Bodhi to grab all results for the update, then de-duplicate
by scenario (taking only the most recent result for each scenario).
Just as a quick note on this - I actually got around to looking at what
Bodhi is *currently* doing here today, and the answer is it's pretty
much inventing the 'scenario' concept on the client end:
https://github.com/fedora-infra/bodhi/blob/develop/bodhi/server/templates...
That is, it uses a nested dict for de-duplication, and assumes all the
results it cares about will have 'test name', 'arch' and 'item'
properties and effectively treats the combination of those three as the
'scenario' for its purposes.
Of course, that wouldn't be safe for openQA results (it'd wind up
considering UEFI and BIOS tests to be dupes, for instance), so if we
were to extend Bodhi to handle openQA results without introducing a
'scenario' concept, I'd have to basically teach Bodhi the openQA
scenario keys. Then if we wanted Bodhi to care about results from some
other system whose scenario was different, we'd have to teach it the
appropriate scenario values for *that* system too and so on. So, I
think this clearly demonstrates the value of the concept :)
If we implement a 'scenario' key, we can then just teach Bodhi to look
for that and combine it with the item, then maybe if it can't find one,
treat 'testname-arch' as the scenario (as a fallback for old results,
results from Taskotron until we teach it to write 'scenario' items into
its results, and a general fallback for cases where 'scenario' is
missing for some reason). That could be the general convention, I
guess: first look for a 'scenario' key, otherwise try and construct one
from very commonly available keys.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net