Excerpts from Josef Skladanka's message of 2017-02-07 11:23 +01:00:
> On Mon, Feb 6, 2017 at 6:49 PM, Kamil Paral <kpa...@redhat.com> wrote:
> 
> > The formulas already provide a way to 'query' structured data via the
> > dot-format, so we could do with as much as passing some variable like
> > 'task_data' that would contain the parsed json/yaml.
> >
> >
> > Or are you proposing we add another variable with these extra values, like
> > this?
> >
> > echo " {'branch': 'master', 'commit': '6e4fc7'} " | runtask --item
> > libtaskotron --type pagure_git_commit --data-file - runtask.yaml
> >
> > or this:
> >
> > echo " {'name': 'htop'} " | runtask --item htop-2.0-1.fc25 --type
> > koji_build --data-file - runtask.yaml
> >
> > and then use ${item} and ${data.branch}, ${data.commit}, or ${data.name} ?
> >
> >
> >
> This is what I meant - keeping item as is, but being able to pass another
> structure to the formula, which can then be used from it. I'd still like to
> keep the item to a single string, so it can be queried easily in the
> resultsdb. The item should still represent what was tested. It's just that
> I want to be able to pass arbitrary data to the formulae, without the need
> for ugly hacks like we have seen with the git commits lately.

We ran into a similar problem with how to represent RPMDiff results in 
ResultsDB. The problem for RPMDiff is that the results are not for 
a single build NVR, but for a pair of NVRs (the build being analyzed 
plus the older "baseline" build it is comparing against).

The solution we came up with (not yet implemented) was to use a new item 
type, with two extra data keys "oldnvr" and "newnvr" to specify the two 
builds in the comparison. We would also store "newnvr" as "item" as 
well, for consistency with other result types.

-- 
Dan Callaghan <dcall...@redhat.com>
Senior Software Engineer, Products & Technologies Operations
Red Hat

Attachment: signature.asc
Description: PGP signature

_______________________________________________
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

Reply via email to