Bugzilla

> CoT verification rebuilds the decision task to make sure that the task is not similar-to, but different-than, a valid decision task. Removing json-e and moving it all to the code removes this capability.


FWIW, this would simplify CoT verification, since JSON-e is no longer needed. CoT would need the `MOBILE_HEAD_...` values (or equivalent) passed forward (as normal), then would download `.taskcluster.yml`, grab the correct task (e.g.: from `onRelease`), then compare.

-----

But, more importantly, Dustin and I talked directly via Zoom.
This proposal would not be effective for two reasons:

**This proposal would greatly increase the friction for any non-trivial tasks:**
Removing JSON-e would force the declation of tasks that _could_ be in the `.taskcluster.yml` to be moved to a decision task, which has three downsides:
* Performance: we now have the delay of firing up a docker worker before the decision task runs
* It requires project devs to have knowledge of taskcluster + docker, since they have to configure their image and run their script in it
* Any variables that are used by the decision task now need to be piped to it, so there's boilerplate variable-passing in the `payload.command[]`

**There's plans to add more triggers to `.taskcluster.yml`**
This is more theoretical, but it could multiply the issues described above^

### Other notes

* We agree that reading and writing JSON-e (usually) isn't as ergonomic as representing logic in a real programming language
* Running anything dynamic in `.taskcluster.yml` needs to be safe, which is why JSON-e was chosen (running something like python adds additional security challenges to guard against fs/network/etc access)
* We'll talk more at all-hands to see how `.taskcluster.yml` ergonomics can be addressed

> CoT verification rebuilds the decision task to make sure that the task is not similar-to, but different-than, a valid decision task. Removing json-e and moving it all to the code removes this capability.


FWIW, this would simplify CoT verification, since JSON-e is no longer needed. CoT would need the `MOBILE_HEAD_...` values (or equivalent) passed forward (as normal), then would download `.taskcluster.yml`, grab the correct task (e.g.: from `onRelease`), then compare.
Though, this doesn't matter because:

-----

But, more importantly, Dustin and I talked directly via Zoom.
This proposal would not be effective for two reasons:

**This proposal would greatly increase the friction for any non-trivial tasks:**
Removing JSON-e would force the declation of tasks that _could_ be in the `.taskcluster.yml` to be moved to a decision task, which has three downsides:
* Performance: we now have the delay of firing up a docker worker before the decision task runs
* It requires project devs to have knowledge of taskcluster + docker, since they have to configure their image and run their script in it
* Any variables that are used by the decision task now need to be piped to it, so there's boilerplate variable-passing in the `payload.command[]`

**There's plans to add more triggers to `.taskcluster.yml`**
This is more theoretical, but it could multiply the issues described above^

### Other notes

* We agree that reading and writing JSON-e (usually) isn't as ergonomic as representing logic in a real programming language
* Running anything dynamic in `.taskcluster.yml` needs to be safe, which is why JSON-e was chosen (running something like python adds additional security challenges to guard against fs/network/etc access)
* We'll talk more at all-hands to see how `.taskcluster.yml` ergonomics can be addressed

> CoT verification rebuilds the decision task to make sure that the task is not similar-to, but different-than, a valid decision task. Removing json-e and moving it all to the code removes this capability.


FWIW, this would simplify CoT verification, since JSON-e is no longer needed. CoT would need the `MOBILE_HEAD_...` values (or equivalent) passed forward (as normal), then would download `.taskcluster.yml`, grab the correct task (e.g.: from `onRelease`), then compare.
Though, this doesn't matter because:

-----

Dustin and I talked directly via Zoom.
This proposal would not be effective for two reasons:

**This proposal would greatly increase the friction for any non-trivial tasks:**
Removing JSON-e would force the declation of tasks that _could_ be in the `.taskcluster.yml` to be moved to a decision task, which has three downsides:
* Performance: we now have the delay of firing up a docker worker before the decision task runs
* It requires project devs to have knowledge of taskcluster + docker, since they have to configure their image and run their script in it
* Any variables that are used by the decision task now need to be piped to it, so there's boilerplate variable-passing in the `payload.command[]`

**There's plans to add more triggers to `.taskcluster.yml`**
This is more theoretical, but it could multiply the issues described above^

### Other notes

* We agree that reading and writing JSON-e (usually) isn't as ergonomic as representing logic in a real programming language
* Running anything dynamic in `.taskcluster.yml` needs to be safe, which is why JSON-e was chosen (running something like python adds additional security challenges to guard against fs/network/etc access)
* We'll talk more at all-hands to see how `.taskcluster.yml` ergonomics can be addressed