68 lines
3.1 KiB
Markdown
68 lines
3.1 KiB
Markdown
|
---
|
||
|
|
type: reference
|
||
|
|
stage: Verify
|
||
|
|
group: Analytics
|
||
|
|
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
|
||
|
|
---
|
||
|
|
|
||
|
|
# Repositories Analytics **(PREMIUM)**
|
||
|
|
|
||
|
|
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/215104) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.4.
|
||
|
|
> - It's [deployed behind a feature flag](../../feature_flags.md), enabled by default.
|
||
|
|
> - It's enabled on GitLab.com.
|
||
|
|
> - It's recommended for production use.
|
||
|
|
> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-repositories-analytics). **(CORE ONLY)**
|
||
|
|
|
||
|
|
CAUTION: **Warning:**
|
||
|
|
This feature might not be available to you. Check the **version history** note above for details.
|
||
|
|
|
||
|
|
You can get a CSV of the code coverage data for all of the projects in your group. This report has a maximum of 1000 records. To get the report:
|
||
|
|
|
||
|
|
1. Go to your group's **Analytics > Repositories** page
|
||
|
|
1. Click **Download historic test coverage data (.csv)**,
|
||
|
|
1. In the popup, select the projects you want to include in the report.
|
||
|
|
1. Select the date range for the report from the preset options.
|
||
|
|
1. Click **Download test coverage data (.csv)**.
|
||
|
|
|
||
|
|
The projects dropdown shows up to 100 projects from your group. If the project you want to check is not in the dropdown list, you can select **All projects** to download the report for all projects in your group, including any projects that are not listed. There is a plan to improve this behavior in this [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/250684).
|
||
|
|
|
||
|
|
For each day that a coverage report was generated by a job in a project's pipeline, there will be a row in the CSV which includes:
|
||
|
|
|
||
|
|
- The date when the coverage job ran
|
||
|
|
- The name of the job that generated the coverage report
|
||
|
|
- The name of the project
|
||
|
|
- The coverage value
|
||
|
|
|
||
|
|
If the project's code coverage was calculated more than once in a day, we will take the last value from that day.
|
||
|
|
|
||
|
|
## Enable or disable Repositories Analytics **(CORE ONLY)**
|
||
|
|
|
||
|
|
Repositories Analytics is under development but ready for production use.
|
||
|
|
It is deployed behind a feature flag that is **enabled by default**.
|
||
|
|
[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
|
||
|
|
can opt to disable it.
|
||
|
|
|
||
|
|
To enable it:
|
||
|
|
|
||
|
|
```ruby
|
||
|
|
Feature.enable(:group_coverage_reports)
|
||
|
|
```
|
||
|
|
|
||
|
|
To disable it:
|
||
|
|
|
||
|
|
```ruby
|
||
|
|
Feature.disable(:group_coverage_reports)
|
||
|
|
```
|
||
|
|
|
||
|
|
<!-- ## Troubleshooting
|
||
|
|
|
||
|
|
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
|
||
|
|
one might have when setting this up, or when something is changed, or on upgrading, it's
|
||
|
|
important to describe those, too. Think of things that may go wrong and include them here.
|
||
|
|
This is important to minimize requests for support, and to avoid doc comments with
|
||
|
|
questions that you know someone might ask.
|
||
|
|
|
||
|
|
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
|
||
|
|
If you have none to add when creating a doc, leave this section in place
|
||
|
|
but commented out to help encourage others to add to it in the future. -->
|