debian-mirror-gitlab/doc/ci/metrics_reports.md

58 lines
2.4 KiB
Markdown
Raw Normal View History

2019-09-04 21:01:54 +05:30
---
2020-06-23 00:09:42 +05:30
stage: Verify
2022-04-04 11:22:00 +05:30
group: Pipeline Insights
2021-02-22 17:27:13 +05:30
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/#assignments
2019-09-04 21:01:54 +05:30
---
2019-09-30 21:07:59 +05:30
# Metrics Reports **(PREMIUM)**
2019-07-31 22:56:46 +05:30
2021-11-18 22:05:49 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9788) in GitLab 11.10. Requires GitLab Runner 11.10 and above.
2019-07-31 22:56:46 +05:30
2021-10-27 15:23:28 +05:30
GitLab provides a lot of great reporting tools for things like [merge requests](../user/project/merge_requests/index.md) - [Unit test reports](unit_test_reports.md), [code quality](../user/project/merge_requests/code_quality.md), and performance tests. While JUnit is a great open framework for tests that "pass" or "fail", it is also important to see other types of metrics from a given change.
2019-07-31 22:56:46 +05:30
2021-02-22 17:27:13 +05:30
You can configure your job to use custom Metrics Reports, and GitLab displays a report on the merge request so that it's easier and faster to identify changes without having to check the entire log.
2019-07-31 22:56:46 +05:30
2020-05-24 23:13:21 +05:30
![Metrics Reports](img/metrics_reports_v13_0.png)
2019-07-31 22:56:46 +05:30
## Use cases
2021-01-29 00:20:46 +05:30
Consider the following examples of data that can use Metrics Reports:
2019-07-31 22:56:46 +05:30
1. Memory usage
1. Load testing results
1. Code complexity
1. Code coverage stats
## How it works
2021-04-17 20:07:23 +05:30
Metrics for a branch are read from the latest metrics report artifact (default filename: `metrics.txt`) as string values.
2019-07-31 22:56:46 +05:30
2021-04-17 20:07:23 +05:30
For an MR, the values of these metrics from the feature branch are compared to the values from the target branch. Then they are displayed in the MR widget in this order:
2019-09-04 21:01:54 +05:30
2021-04-17 20:07:23 +05:30
- Existing metrics with changed values.
- Metrics that have been added by the MR. Marked with a **New** badge.
- Metrics that have been removed by the MR. Marked with a **Removed** badge.
- Existing metrics with unchanged values.
2019-09-04 21:01:54 +05:30
2019-07-31 22:56:46 +05:30
## How to set it up
2022-01-26 12:08:38 +05:30
Add a job that creates a [metrics report](yaml/artifacts_reports.md#artifactsreportsmetrics) (default filename: `metrics.txt`). The file should conform to the [OpenMetrics](https://openmetrics.io/) format.
2019-07-31 22:56:46 +05:30
For example:
```yaml
metrics:
script:
- echo 'metric_name metric_value' > metrics.txt
artifacts:
reports:
metrics: metrics.txt
```
2020-07-28 23:09:34 +05:30
## Advanced Example
An advanced example of an OpenMetrics text file (from the [Prometheus documentation](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-format-example))
renders in the merge request widget as:
![Metrics Reports Advanced](img/metrics_reports_advanced_v13_0.png)