Endpoint for daily summarized project code coverage data in a group
Problem to solve
As a developer I want to be able to access a CSV of the coverage data for projects within a group via an Endpoint so I can analyze it.
This issue represents the backend endpoint work for this frontend issue: #215104 (closed)
We want to be able to return a CSV containing the daily summarized code coverage data for all projects within a group.
Intended users
Proposal
Implement an endpoint that returns the summarized daily code coverage report data for each project in a group in CSV format.
This will be an internal API only. Not written in Grape.
From: #215104 (closed)
An example of what the CSV might look like:
Date | Project Name | Job Name | Coverage |
---|---|---|---|
2020-04-21 | myProject | myJobRspec | 89.05% |
2020-04-21 | myProject | myJobKarma | 34.05% |
2020-04-21 | myOtherProject | myOtherJobRspec | 89.05% |
2020-04-21 | myOtherProject | myOtherJobKarma | 34.05% |
2020-04-20 | myProject | myJobRspec | 85.55% |
2020-04-20 | myProject | myJobKarma | 30.05% |
2020-04-20 | myOtherProject | myOtherJobRspec | 89.05% |
2020-04-20 | myOtherProject | myOtherJobKarma | 34.05% |
2020-04-19 | myProject | myJobRspec | 81.75% |
2020-04-19 | myProject | myJobKarma | 30.01% |
2020-04-19 | myOtherProject | myOtherJobRspec | 89.05% |
2020-04-19 | myOtherProject | myOtherJobKarma | 34.05% |
note: % sign in last column is optional, if it's easier to not include it that should be acceptable.
Permissions and Security
Any user who can access the group should be able to download the data. This should be available to GitLab Premium and above tiers.
Documentation
Documentation created for the frontend components of this will be sufficient.
Availability & Testing
@zeffmorgan can you foresee any special considerations for this endpoint with respect to testing?
Risks
- Has dependencies on other lower level configuration, such as executing the tool in the pipeline and correctly configuring the extraction at the project level
- Potential for dropping data depending on when we collect and when pipelines are complete
- Difficulty determining when coverage reporting was intended (project code coverage regex exists?) to understand failures (regex or pipeline issues) vs no data returned (not configured)
Risk mitigation:
- Will need to ensure documentation is sufficient, especially for cases where more than one tool is used to provide coverage data and where timing issues may present a problem (long running pipelines/date change during pipeline execution)
- Additional testing
Testing
- Basic unit testing should cover critical points from actual feature functionality
- API testing required
- Eventual E2E test in the next iteration is potentially called for
- Adding an endpoint will not require package-and-qa
@iamricecake do you have any concerns over this endpoint being available to very large groups with lots of tests, like the primary GitLab group? Do you think we should put a feature flag around it?
- Yes, this will be feature flagged, enabled by default. Just like how the other coverage graph related features.
What does success look like, and how can we measure that?
- See the parent epic.
What is the type of buyer?
Dakota - The Application Development Director is the buyer for this feature.
This will be built for GitLab Premium
Is this a cross-stage feature?
This iteration will not be cross-stage