Chaps,
we were discussing this many times in the past, and as with the
type-restriction, I think this is the right time to get this done, actually.
It sure ties to the fact, that I'm trying to put together
Taskotron-continuously-testing-Taskotron together - the idea here being that
on each commit to a devel branch on any of the Taskotron components, we will
spin-up a testing instance of the whole stack, and run some integration
tests.
To do this, I added a new consumer to Trigger (
https://phab.qa.fedoraproject.org/D1110 ) that eats Pagure.io commits, and
spins jobs based on that.
This means, that I want to have the repo, branch and commit id as input for
the job, thus making yet-another-nasty-hack to pass the combined data into
the job (
https://phab.qa.fedoraproject.org/D1110#C16697NL18 ) so I can hack
it apart later on either in the formula or in the task itself.
Ewww :) That's the same approach modularity folks need to use for dist_git_commit. We
need to improve this, agreed.
It would be very helpfull to be able to pass some structured data
into the
task instead.
I kind of remember that we agreed on json/yaml.
Yes, that seems reasonable. I guess I'd prefer using yaml parser for that, because it
can also understand classic json. In infra, I guess json will be used (coming from
fedmsgs), but in documentation we can use better readable yaml examples.
The possibilities were either reading it from stdin or file. I
don't really
care that much either way, but would probably feel a bit better about having
a cli-param to pass the filename there.
I propose using a cli-param with a file path, with a special case for "-"
meaning stdin. That is the common syntax for many unix tools.
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.
Here I'm a bit unclear. Are you proposing that "item" itself will be
structured, e.g. like this?
echo " {'repo': 'libtaskotron', 'branch': 'master',
'commit': '6e4fc7'} " | runtask --item-file - --type
pagure_git_commit runtask.yaml
or this:
echo " {'nvr': 'htop-2.0-1.fc25', 'name': 'htop'}
" | runtask --item-file - --type koji_build runtask.yaml
In this case we would be able to use ${item.repo}, ${item.branch}, ${item.commit} or
${item.nvr}, ${item.name} directly in the formula. Would we still keep `--item string`, or
would it no longer have any use?
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} ?
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.