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 <kparal(a)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 <dcallagh(a)redhat.com>
Senior Software Engineer, Products & Technologies Operations
Red Hat