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.