> If grouping at submission is the concern here, then it would be more than > easy to do - the idea here (maybe I did not communicate it properly) was to > use the ExecDB generated UUID as the identifier, the same way we do in the > whole stack. > Since the Groups can be created "on the fly" (meaning, that if you submit a > result, with a group-uuid that is not yet in the database, it is created for > you), we would not need to worry about it at all. > If we wanted to be a bit more descriptive, we could create the Group, and set > the Name/Description during trigger time (probably as a part of creating the > execdb job).
> This would, of course, lead to having the 'exec_url' set in the Group's > 'ref_url' and thus having the back-reference "by convention", as we have it > now, with Job. I don't think that either of the options (exec_url in Result, > or using group "by convention") is necessarily better than the other, it's > mostly about what semantics we want to have. Having the link to execdb in a group (as we do it right now) seems as a fine approach to me. > The last question to ask is, whether the "execution grouping" is even > something usefull - what do we (would we) use the information that "these X > results come from the same execution"? Is it even something we care about? Currently it is the only way to display dist.rpmgrill* (including subchecks) results for a NVR. Also, it is useful when e.g. looking at what a single upgradepath run reported - I can quickly and easily see everything that was reported during that single task execution. > I don't think that having a "This was executed together" group that big of a > deal, the problem I see (and I'm not sure it's really a problem) is that if > we have Result in multiple Groups, then linking from ResultsDB to ExecDB can > not be done programatically (which group is the "this was executed > together", and which are "something else) without relying to convention > (like beginning the name of the "exec" group with "Taskotron Execution"). Using conventions is fine in my POV. Either name prefix, or arbitrary tag on the group, etc. Tim wrote: > This would mean that we can find the job that every result came from > without having to worry about grouping them at submission time. I can > think of use cases where there either be no need for a job UUID/URI or > one would not exist, hence the suggestion that the column could be > empty. What are the use cases? I can think of one - yesterday Adam mentioned he would like to save manual test results into resultsdb (using a frontend). That would have no ExecDB entry (no UUID). Is that a problem in the current design? This also means we would probably not create a group for this result - is that also OK? _______________________________________________ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
