- Comments: #130
- Proposed by: @djmitche, @owlishDeveloper (author of this document)
We want to implement Checks API without dropping the support os Statuses API. Statuses API would be the default. Our users
will have the freedom to choose which API they want by indicating their choice in .taskcluster.yml.
So GitHub has come up with a new API to create status indicators in its UI, called Checks. Checks API isn't in any way compatible with the current Statuses API - status created with one cannot be updated with another; they are two totally separate sets of data. Calling both APIs would result in two sets of status indicators in the UI. Any third party tools and integrations that rely on Statuses API to work would stop working after we switched to Checks API.
We want to implement Checks because it seems to be the future, and because it gives a much richer output and a whole bunch of controls for our users.
At the same time, we want to preserve compatibility with Statuses because some of our users use tools and integration that rely on them.
Currently we create a task and a status in a single function that listens
to github webhooks. The idea is to create a task in separate function that listens to webhooks and creates tasks;
then listen to the pulse message (namely, task defined) on a certain queue that signals about creation of a task.
The messages would go to this or that queue based on some indication in taskcluster.yml - like a line reporting: 'checks-v1'
in a task definition.
The user interface in this case is .taskcluster.yml. The presence of the indication in the .taskcluster.yml would
result in adding a route (like a path to a queue?) to the task.
We can also have something like reporting: ['github-checks', 'github-statuses', 'irc://irc.mozilla.org:6667/#myproject']
to report through various channels. Status API will be enabled by default for all tasks; Checks API will be disabled
for all tasks. Users will be able to set up either Statuses API or Checks API, as well as both for each individual task.
We would have two separate sets of listeners for task defined event - one would create statuses using Checks API, and another
would use Statuses API. Similarly, status updates would come in through separate channels as well, so we would have two
separate sets of status listeners - one for updating status indicators through Statuses API, and another through Checks.
It's not possible to create several check-suites (sets of checkruns) for each individual revision, commit or PR. Therefore,
we must treat certain tasks with dependencies as a single checkrun, giving that checkrun the subgroup status to display
on GitHub. Envisioning @dustin's desire to make this as customizable as possible, we would make it possible for users
to set this in .taskcluster.yml for each individual task.
An initial version will just map each task to a checkrun inside a checksuite. Later we can either bump the version or in a backward-compatible way allow people to create some sort of artifact that specifies which runs they want us to report and how.
I (owlish) will be implementing this. I am not familiar with the concept of routes and very vaguely familiar with the concept of scheduler ID. I'll be going through the docs today, but if you have any relevant links - those would be greatly appreciated.