We could use a common decision task protocol to add new tasks to the current Taskcluster group, after analyzing the target.
As we already have the logic to retrieve target's code and Taskcluster client's setup, we need 2 more things:
- Support some rules to decide if a task is added or not
- Create a new task for each approved one
The .taskcluster.yml file is built with json-e. We could leverage that, and add our own json-e functions while rendering the .taskcluster.yml file from any repository.
A common pattern is to trigger a task only if some file changed in the diff from current revision up to master.
To accomplish that, we could:
- add a json-e function
$files_changed(["pattern/*.cpp", "anything.txt"])
- set the
tasks_for variable to taskboot-decision
- render the target
.taskcluster.yml with these parameters
- if any tasks payload is present in the rendered file, create those tasks.
On the target, the changes are:
- add a taskboot decision task (using published image and command
taskboot decision)
- add the relevant tasks with the syntax:
tasks:
- $if "tasks_for == 'taskboot-decision' and $files_changed(['**.py'])"
then
...
We could use a common decision task protocol to add new tasks to the current Taskcluster group, after analyzing the target.
As we already have the logic to retrieve target's code and Taskcluster client's setup, we need 2 more things:
The
.taskcluster.ymlfile is built with json-e. We could leverage that, and add our own json-e functions while rendering the.taskcluster.ymlfile from any repository.A common pattern is to trigger a task only if some file changed in the diff from current revision up to master.
To accomplish that, we could:
$files_changed(["pattern/*.cpp", "anything.txt"])tasks_forvariable totaskboot-decision.taskcluster.ymlwith these parametersOn the target, the changes are:
taskboot decision)