### Problem to solve <!-- 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)." --> 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. ### Intended users * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) - who has to get data from each pipeline individually today. ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> * Dakota needs to report a value up to leadership about how testing is going. Today that number is code coverage and getting that data requires an external tool, a custom implementation through the GitLab API or manually digging into each pipeline by hand. * Delaney wants to see how each of their team's projects code coverage is trending. Today that requires manually getting code coverage each day or an integration with the GitLab API and a spreadsheet. The data is in GitLab it's just hard to get out. This top down view of groups will connect to a similar view at project level which will in turn connect with [individual test history](https://gitlab.com/gitlab-org/gitlab/-/issues/33932), [flaky test detection](https://gitlab.com/gitlab-org/gitlab/-/issues/3673), etc. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> * Create a single source of truth for all projects that belong to a group using the average coverage value of all jobs from the default branch. * Allow a user to select which projects are included. * Provide a graph of the average value over time for selected projects * Show graph for L90. * Provide a data download for selected projects with individual data for each job that has a coverage number calculated from the [matched regex](https://docs.gitlab.com/ee/ci/pipelines/settings.html#test-coverage-parsing). * Provide a link to each project that has code coverage. * Link to the coverage chart for the project. ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> This will be successful if users are: * Downloading data * Clicking through to project graphs ### 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? This feature will not impact other stages or product areas directly. We expect that ~"Category:Release Evidence" will be able to make use of this data for cross project releases. #### Supporting Artifacts * Validation item: https://gitlab.com/gitlab-org/gitlab/-/issues/209969 * Opportunity Canvas: https://docs.google.com/document/d/1Tr4boFxz1fbuqfodOhwbgWmINjvoIOERegLULmNG_vE/edit