Solution - CI Results Tab
For the Change Page we will build a “Checks” tab next to the “Files” and “Comments” tabs for displaying CI status and results.
The data for the Checks tab is exclusively provided by plugins. We will add a new frontend plugin API for this purpose. Multiple plugins can contribute data at the same time. If no plugin provides any data, then the tab is not shown.
The Gerrit backend will not be changed at all. Beyond label votes and robot comments CI results are not stored in Gerrit, but loaded directly from other sources. That implies that such CI results are not indexed and can only block submission indirectly via a label vote.
We will also add 1-3 lines of summary information below the commit message about the data on the Checks tab.
To get a better understanding of the proposed design we have drafted wireframes for the new tab and the new summary. They are drafts and not finalized designs.
Plugins will be able to register themselves as CI data providers using the frontend plugin API. When they have done that they will be notified during Change Page load about the change number and the latest patchset number, and are requested to return an array of CheckRuns and CheckResults, see data model section below.
The data provider will be polled for updates, if a polling interval was set during registration. Updates can also be pushed.
The API will also include methods for managing the login workflow, if the data provider needs to establish authentication and authorization. If APIs prove to be insufficient, then we will consider other means such as iframes and external links. Note that it is also possible to avoid making direct HTTP calls to other systems from the data provider plugin. Instead the data provider could make calls to its backend plugin code and make calls to the CI system from the backend. Even storing the CI data within Gerrit by a plugin would be an option.
The goal of the “CI Results Tab” is to create a consistent user experience for a deeper integration of CI systems into Gerrit’s UI, but there is such a variety of CI systems being used by Gerrit hosts that we cannot expect to meet all the special needs of each system with one unified UI. We are therefore planning to add extension points to the tab and the summary such that individual plugins can easily customize the UI with their own labels, buttons and widgets.
The CI Results Tab will be developed as a core feature and not as a plugin itself, because
- We would like to avoid plugins being dependent on plugins.
- We would like to avoid plugins offering plugin extension points for other plugins.
- We would like to use complex widgets and infrastructure of core that are not available to plugins.
- We believe that CI integration is a must-have feature for Gerrit hosts and we want to establish one consistent, smooth and well tested solution.
“CheckRun” and “CheckResult” are the central entities that are passed in from data providers. While this design doc intentionally glosses over some details, we believe that it is vitally important to get an agreement on the data model for runs and results, so this is modeled here at a very detailed level, so that it is possible to check whether existing integrations can be converted to the new model.
The UI will respect the order of the returned lists of runs and results, so plugins can control which Checks appear first and thus make up for the absence of a priority field in the data model. If multiple plugins provide data, then the results from earlier installed plugins are shown first.