Third Party App Integrations with GitHub
Not too long ago GitHub introduced their combined status API. Since that time it has become an official component of the API. Today I would like to highlight the power of this approach and the integration possibilities this enables across GitHub’s diverse ecosystem of Satellite Applications.
But first what is a Satellite Application?
The ReviewNinja team at SAP uses the term “satellite application” to refer to any application built on top of the GitHub API, this also includes using the provided oauth mechanism for user authentication. These Satellite Applications enrich the ecosystem around GitHub and provide a strong incentive for using GitHub over competitor offerings. In essence these tools are third party apps that integrate with GitHub, but we think “satellite app” sounds much cooler.
Traditionally, inter-satellite app integrations have been downplayed in favour of integrations directly into GitHub. These statuses are usually surfaced on a pull request level, but can exist on any ref. With the combined status API, any third party tool can create a status on any ref with a given context. Any tool can write into any context, but most tools choose to use a logical namespace, for example we at ReviewNinja use the context “code-review/reviewninja”. Think of these contexts as buckets, for any ref we can throw in as many status updates as we like and watch our ref progress from pending to successful. The combination occurs by taking the latest status for each context (bucket) and reporting the combined status, the aggregation of all states (if one context is failing the combined status is failing, if all are passing the combined status is passing).
Currently, the combined status is not surfaced in GitHub’s UI, surely this will be available soon. Here is how we display this information in ReviewNinja.
As you can see we have two unique contexts reporting into Pull Request #565, but this could expand to any number of integrations. This low-coupled approach allows us to easily and seamlessly integrate with a plethora of Satellite Applications for free! Fantastic!
We are already exploring advanced workflow scenarios for ReviewNinja, for example maybe some contexts do not make sense from a code review perspective and should therefore be ignored. Perhaps certain contexts have more authority than others and should be given higher priority. The combined status API gives us the foundation needed to explore all these possibilities and create the best possible code review tool. This is our goal at ReviewNinja
What is next?
The integrations described here constitute a very light-weight approach. Each context contains a description and can be in one of four states (pending, success, error, or failure). However, no additional information can be provided to enrich the status.
Imagine if a linter could report to the status API a list of all errors and warnings? ReviewNinja could take the integration one step further and report the exact error on the exact line, the same scenario would be possible with testing suites. Such a rich and visually appealing approach to code review simply does not exist right now. But it sure would be fantastic!
These are the ideas and concerns the ReviewNinja team tackle every day. We are constantly looking for feedback and advice to achieve our goal of providing the best code review experience on GitHub. Please feel free to reach out to us by creating an issue or contributing to our feedback request. And don’t forget you can start using ReviewNinja today!