[coverage_report_view] Enable inline code coverage view in merge request diffs
We must address some performance concerns with performing the code coverage analysis on large datasets before we can remove the
:coverage_report_view feature flag so it is enabled by default. @ayufan has outlined some concerns in !21791 (merged) that will need to be addressed before we can remove the feature flag.
Likely it would be better to store these comparison results in some place that is persistent. Having to recalculate the comparison results each time this is loaded or even using redis to cache portions of that calculation has proven to be inefficient. In order to alleviate performance concerns with this we should establish a persistent storage strategy for the comparison results.
- Most appropriate slack channel to reach out to:
- Best individual to reach out to: @rickywiens / @jheimbuck_gl
From !27744 (closed):
The parsed report is then stored in a new
PipelineProcessedReportmodel as a file in object-store. Merge-requests fetch the file via
ReactiveCachemechanism, frame the results (filter the files, which are shown in the merge-request) and cache it in Redis as part of the mechanism.
This change reduced the load-time of inline coverage information to <5 seconds (initial visit) or immediately (subsequent visits) for 200 MB of raw coverage data (GitLab produces around 20 MB), which is in steep contrast to the original performance measured here.
We should continue the approach proposed in !27744 (closed) and get it to a state where we can work off of it.
What are we expecting to happen?
The inline-code coverage view in the MR diff should load in less than 5 seconds on initial MR diff view for the gitlab-org/gitlab project
The inline-code coverage view in the MR diff should load in less than 1 second on subsequent views of the MR diff for the gitlab-org/gitlab project
What might happen if this goes wrong?
The inline-code-coverage loading does not appear on the MR diff view
The inline-code coverage loads slowly on the MR diff view
More files than we expected are persisted into object store
Larger files than we expected are persisted into object store
Roll Out Steps
- Address concerns
- Establish expectations for rollout
- Establish interested parties for turning feature on early
- Enable on staging
- Test on staging
- Ensure that documentation has been updated
- Enable on GitLab.com for individual groups/projects listed above and verify behaviour
Coordinate a time to enable the flag with
- Announce on the issue an estimated time this will be enabled on GitLab.com
Enable on GitLab.com by running chatops command in
Cross post chatops slack command to
#support_gitlab-comand in your team channel
- Announce on the issue that the flag has been enabled
- Remove feature flag and add changelog entry
After the flag removal is deployed, clean up the feature flag by running chatops command in