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.



> 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
_______________________________________________
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