2.2 KiB
| stage | group | info | type |
|---|---|---|---|
| Verify | Testing | 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 | reference |
Metrics Reports (PREMIUM)
Introduced in GitLab Premium 11.10. Requires GitLab Runner 11.10 and above.
GitLab provides a lot of great reporting tools for merge requests - Unit test reports, code quality, performance tests, etc. 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.
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.
Use cases
Consider the following examples of data that can use Metrics Reports:
- Memory usage
- Load testing results
- Code complexity
- Code coverage stats
How it works
Metrics are read from the metrics report (default: metrics.txt). They are parsed and displayed in the MR widget.
All values are considered strings and string compare is used to find differences between the latest available metrics artifact from:
master- The feature branch
How to set it up
Add a job that creates a metrics report (default filename: metrics.txt). The file should conform to the OpenMetrics format.
For example:
metrics:
script:
- echo 'metric_name metric_value' > metrics.txt
artifacts:
reports:
metrics: metrics.txt
Advanced Example
An advanced example of an OpenMetrics text file (from the Prometheus documentation) renders in the merge request widget as:
