Introduce Checks API
The GitHub introduced: https://blog.github.com/2018-05-07-introducing-checks-api/.
This is actually a great moment for us to do that too.
The idea here is to:
- have a first-class Checks API, the only API that is supported to deliver the status of Merge Request,
- currently we have a lot of different pieces delivered, but without abstraction built-in,
- this would make GitLab CI to use Checks API too,
- make every of the test suites to contribute to Checks API: we could parse on Backend each report and create a good representation of this data in context of Merge Request,
- one of the examples to implement that with checks API would be test suites,
- make Deployment/Environments feature to use Checks API: this would simplify and allow us to easily prioritize the information
The Checks API would replace the existing Commit Status API. Commit Status API would be re-wired to use Checks API internally.
The reason to implementing Checks API would be to make all pieces of information first class and make everyone to be on the same level. This is super important to solve the overcrowded Merge Request Widget, implement the asked JUnit XML tests, solve the Code Climate, SAST and any other feature that makes use of Checks API.
We could also make this explicitly first-class from
test: script: run-my-test-suite reports: codequality: ./codequality.json sast: ./sast.xml junit: ./junit-xml.json
Runner would send each of these reports. GitLab CI would use Checks API to have the representation of Pipeline. Each of the reports would also be reported as separate Checks. By properly looking at backlog we would be able to parse, point to code, present tests failures, right in Checks API tab.