Taskcluster views.json proposal

example-views.json

{
  "taskGroupId": "<taskGroupId>",
  "views": [
    {
      "type": "subtask",
      "tasks": ["<task id>", "<task id>", "..."],
      "context": {
        "description": "Linux64 opt Mochitest",
        "symbol": "M",
        "platform": "linux64/opt",
      },
    },
    {
      "type": "subtask",
      "tasks": ["<task id>", "<task id>", "..."],
      "context": {
        "description": "Windows10 64 opt Mochitest",
        "symbol": "M",
        "platform": "windows10-64/opt",
      },
    },
    {
      "type": "taskcluster-unit",
      "tasks": ["<task id>"],
      "context": {
        "description": "set allowed key (twice)",
        "format": "tap",
        "artifact": "report.tap",
      },
    },
    {
      "type": "taskcluster-unit",
      "tasks": ["<task id>"],
      "context": {
        "description": "set disallowed key",
        "format": "tap",
        "artifact": "report.tap",
      },
    },
  ],
}

I think that part can definitely go in the task definition. There are two parts that I think make sense as artifacts. First is a "manifest" from the decision task stating which "subtasks" make up which larger tasks. Second is a "result" of sorts that is more fitting for my taskcluster-unit use-case.

Actually, a good thing I just remembered is that task-graph.json will end up with all of the tasks and their details as in this one. That wouldn't cover tasks added via actions though so we might need to think further on that. If you think you can get away with not having treeherder look at any details from decision tasks maybe that is easiest. It would be nice to know beforehand which tasks to expect in some ways though?

In the taskcluster-unit case, I would write out a file that specifies the results of running the tests so views.json would be self-referential really. Maybe putting it in the task definition would make the most sense in that case.

For the record I think a separate manifest (e.g views.json) would be fine to have as a separate artifact. But using my earlier example in the first comment, treeherder could theoretically group all tasks that have the same "symbol" (and platform). In that case I don't think a separate artifact would be necessary.

I guess if there's additional metadata that only applies to the parent task, defining that in task-graph.json would be clunky, and at that point a separate manifest/artifact might be better. But there's a chance the two problems we're trying to solve are different enough from one another that we're forcing round and square pegs into a triangular hole. (I do agree we should at least try to solve them both in a generic way)