Graph the average code coverage of all of a group's projects
<!-- The first three sections: "Problem to solve", "Intended users" and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. -->
### Release notes
The previously released [Repository Analytics for Group Test Coverage](https://about.gitlab.com/releases/2020/11/22/gitlab-13-6-released/) is an easy way to see the current test coverage for projects in a group and get data for visualization outside of GitLab. Group Test Coverage now includes a graph of the average of all project test coverage over time to provide at a glance how test coverage for the group is trending over time.
### Problem to solve
As a development team lead, I want a single image to show the current code coverage and how it's trending over time, so I can quickly get the test coverage data that [Dakota](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/#dakota---the-application-development-director) is asking for and get back to work.
**From the epic:** As a development team lead, I want a single page of code coverage data for my group's projects, so I can quickly get the test coverage data [Dakota](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/#dakota---the-application-development-director) is asking for and get back to work.
<!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." -->
### Intended users
* [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
### Further details
<!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. -->
* Ultimately Dakota wants one graph to tell the story that code coverage is increasing. This is that graph.
* This saves Delaney the step of creating the graph themselves after downloading the data.
### Proposal
<!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->
* By default include all projects that belong to a group and have jobs with coverage data calculated.
* This does not include sub-groups at this time. We'll cover this in a [future iteration](https://gitlab.com/gitlab-org/gitlab/-/issues/273527).
* By default include just the value(s) from the default branch for each project
* We know that "average" of these is not a great number but by providing [links into projects](https://gitlab.com/gitlab-org/gitlab/-/issues/215135) and [other data within the projects](https://gitlab.com/gitlab-org/gitlab/-/issues/21550) Delaney and their team can make informed decisions. This is intended to provide a starting point for conversation.
* Average in this case will be (sum of job coverage values / number of jobs with coverage value)
* Add the data to the GraphQL API for historic coverage data to build the graph of the average coverage over time @morefice can you help fill in the technical bits and schema with @mfluharty
#### Frontend
Add a new section/component (`TestCoverageGraph`?) to [`group_repository_analytics.vue`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/assets/javascripts/analytics/repository_analytics/components/group_repository_analytics.vue#L4) to handle the following:
* Load recent coverage data (`codeCoverageActivities`) via ~GraphQL, see example query below
* Display the data as a line graph using [GlAreaChart](https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/charts-area-chart--default) with coverage value as the vertical axis and time as the horizontal axis - we can steal some inspiration from the `Code coverage statistics for master` section of the existing [Project Repository Analytics page](https://gitlab.com/gitlab-org/gitlab/-/graphs/master/charts) ([source code link](https://gitlab.com/gitlab-org/gitlab/blob/master/app/assets/javascripts/pages/projects/graphs/components/code_coverage.vue))
```
{
group(fullPath: "gitlab-org") {
name
id
codeCoverageActivities(startDate: "2020-10-20") {
nodes {
projectCount
averageCoverage
coverageCount
date
}
}
}
}
```
### Permissions and Security
None.
### Documentation
* Add a screenshot and a blurb to the [existing documentation](https://docs.gitlab.com/ee/user/group/#repositories-analytics)
* Add any caveats, exceptions, etc. to the documentation
### Availability & Testing
<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.
What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?
Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change
See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->
### What does success look like, and how can we measure that?
#### Acceptance Criteria
* Graph is displayed by default on the page
* The page loads in around 1 second (without graph) and the graph loads within 10 seconds for the [gitlab.org group page](https://gitlab.com/groups/gitlab-org/-/analytics/repository_analytics).
### Measures of success
* We expect that 30 days after launch of this feature weekly page views of the analytics page will increase to 100 per week on gitlab.com.
### What is the type of buyer?
<!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/
In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers -->
[Dakota - The Application Development Director](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/#dakota---the-application-development-director) is the buyer for this feature.
This will be built for ~"GitLab Premium"
### Is this a cross-stage feature?
No.
### Links / references
issue