On Mon, Feb 6, 2017 at 6:49 PM, Kamil Paral <kparal@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.

 
I guess it depends whether the extra data will be mandatory and exactly defined ("this item type provides these input values") or not (what will formulas do when they're not there?). Also whether we want to make it still possible to execute a task with simple `--item string` in some kind of fallback mode, to keep local execution on dev machines still easy and simple.


My take on this is, that we will say which variables are provided by the trigger for each type. If a variable is missing, the formula/execution should just crash when it tries to access it.
Not sure about the fallback mode, but my take on this is, that if the user will want to run the task, he will have to just write the "extra data" once to a file, and then it will be just passed in as usual.
We could even make some templates for each item_type (I guess trigger docs are the place for it?), so people can easily just copy-paste it, and make changes.
I also think that providing a sample json file to the existing tasks (that are using it) is a best practice we should strive for.

Makes sense?

Joza