Bugzilla

Increasingly projects that ship on iOS are relying on Bitrise for their CI/CD needs. While we haven't quite established Bitrise as the recommended place to run iOS CI/CD, we are shaping up towards that point. That said, we don't want to discard the years of other release automation and standards that we have developed in Taskcluster everywhere else.

It's clear we need some sort of integration between Taskcluster and Bitrise.

The good news is that Bitrise has an API, and you can schedule workflows / pipelines with it. The bad news is that the token used to access the API doesn't have fine grained permissions to schedule specific workflows. This means, there's no way to allow a pull request to run build + test workflows without also allowing them to run release related workflows.

The solution is a new `bitrisescript` worker in scriptworker-scripts. With this, we can securely schedule sensitive Bitrise workflows by implementing new scopes that contain the name of the workflow or pipeline to trigger. This will also make scheduling Bitrise pipelines CoT friendly, so we can insert them into the release process (either before or after existing Taskcluster release tasks).

I think we'll have at least two sets of scopes, apps and workflows. E.g task might declare the following scopes:
```
project:mobile:bitrise:app:firefox-ios
project:mobile:bitrise:workflow:release
```

In Bitrise, pipelines are a series of workflows. We could either invent a third type of scope for those, e.g:
```
project:mobile:bitrise:pipeline:release
```

Or we could use the Bitrise API to retrieve the names of the workflows it runs, then only trigger the pipeline if the task has scopes for *all* workflows therein. A side effect to this is that we'd need to maintain a list of workflows in the task definitions. On the one hand, this could generate busy work. On the other, it could protect against previously "safe" pipelines being modified to have less safe workflows added. For that reason, I like this approach better.

I don't think it's worth adding a separate scope to control an `action` (e.g `trigger-workflow` or `trigger-pipeline`) like we have in other scripts. I believe the `workflow` / `pipeline` scopes already cover this. We can look at adding it in the future if we want to implement additional capabilities beyond triggering workflows.

Increasingly projects that ship on iOS are relying on Bitrise for their CI/CD needs. While we haven't quite established Bitrise as the recommended place to run iOS CI/CD, we are shaping up towards that point. That said, even if Bitrise were the recommended solution, we don't want to discard the years of other release automation and standards that we have developed in Taskcluster.

It's clear we need some sort of integration between Taskcluster and Bitrise.

The good news is that Bitrise has an API, and you can schedule workflows / pipelines with it. The bad news is that the token used to access the API doesn't have fine grained permissions to schedule specific workflows. This means, there's no way to allow a pull request to run build + test workflows without also allowing them to run release related workflows.

The solution is a new `bitrisescript` worker in scriptworker-scripts. With this, we can securely schedule sensitive Bitrise workflows by implementing new scopes that contain the name of the workflow or pipeline to trigger. This will also make scheduling Bitrise pipelines CoT friendly, so we can insert them into the release process (either before or after existing Taskcluster release tasks).

I think we'll have at least two sets of scopes, apps and workflows. E.g task might declare the following scopes:
```
project:mobile:bitrise:app:firefox-ios
project:mobile:bitrise:workflow:release
```

In Bitrise, pipelines are a series of workflows. We could either invent a third type of scope for those, e.g:
```
project:mobile:bitrise:pipeline:release
```

Or we could use the Bitrise API to retrieve the names of the workflows it runs, then only trigger the pipeline if the task has scopes for *all* workflows therein. A side effect to this is that we'd need to maintain a list of workflows in the task definitions. On the one hand, this could generate busy work. On the other, it could protect against previously "safe" pipelines being modified to have less safe workflows added. For that reason, I like this approach better.

I don't think it's worth adding a separate scope to control an `action` (e.g `trigger-workflow` or `trigger-pipeline`) like we have in other scripts. I believe the `workflow` / `pipeline` scopes already cover this. We can look at adding it in the future if we want to implement additional capabilities beyond triggering workflows.