Commit 94eb2f47 authored by Leandro Camargo's avatar Leandro Camargo

Add changelog entry and extend the documentation accordingly

parent 9f97cc65
---
title: Add ability to define a coverage regex in the .gitlab-ci.yml
merge_request: 7447
author: Leandro Camargo
...@@ -76,6 +76,7 @@ There are a few reserved `keywords` that **cannot** be used as job names: ...@@ -76,6 +76,7 @@ There are a few reserved `keywords` that **cannot** be used as job names:
| after_script | no | Define commands that run after each job's script | | after_script | no | Define commands that run after each job's script |
| variables | no | Define build variables | | variables | no | Define build variables |
| cache | no | Define list of files that should be cached between subsequent runs | | cache | no | Define list of files that should be cached between subsequent runs |
| coverage | no | Define coverage settings for all jobs |
### image and services ### image and services
...@@ -278,6 +279,33 @@ cache: ...@@ -278,6 +279,33 @@ cache:
untracked: true untracked: true
``` ```
### coverage
`coverage` allows you to configure how coverage will be filtered out from the
build outputs. Setting this up globally will make all the jobs to use this
setting for output filtering and extracting the coverage information from your
builds.
#### coverage:output_filter
For now, there is only the `output_filter` directive expected to be inside the
`coverage` entry. And it is expected to be a regular expression.
So, in the end, you're going to have something like the following:
```yaml
coverage:
output_filter: /\(\d+\.\d+\) covered\./
```
It's worth to keep in mind that the surrounding `/` is optional. So, the above
example is the same as the following:
```yaml
coverage:
output_filter: \(\d+\.\d+\) covered\.
```
## Jobs ## Jobs
`.gitlab-ci.yml` allows you to specify an unlimited number of jobs. Each job `.gitlab-ci.yml` allows you to specify an unlimited number of jobs. Each job
...@@ -319,6 +347,8 @@ job_name: ...@@ -319,6 +347,8 @@ job_name:
| before_script | no | Override a set of commands that are executed before build | | before_script | no | Override a set of commands that are executed before build |
| after_script | no | Override a set of commands that are executed after build | | after_script | no | Override a set of commands that are executed after build |
| environment | no | Defines a name of environment to which deployment is done by this build | | environment | no | Defines a name of environment to which deployment is done by this build |
| environment | no | Defines a name of environment to which deployment is done by this build |
| coverage | no | Define coverage settings for a given job |
### script ### script
...@@ -993,6 +1023,27 @@ job: ...@@ -993,6 +1023,27 @@ job:
- execute this after my script - execute this after my script
``` ```
### job coverage
This entry is pretty much the same as described in the global context in
[`coverage`](#coverage). The only difference is that, by setting it inside
the job level, whatever is set in there will take precedence over what has
been defined in the global level. A quick example of one overwritting the
other would be:
```yaml
coverage:
output_filter: /\(\d+\.\d+\) covered\./
job1:
coverage:
output_filter: /Code coverage: \d+\.\d+/
```
In the example above, considering the context of the job `job1`, the coverage
regex that would be used is `/Code coverage: \d+\.\d+/` instead of
`/\(\d+\.\d+\) covered\./`.
## Git Strategy ## Git Strategy
> Introduced in GitLab 8.9 as an experimental feature. May change or be removed > Introduced in GitLab 8.9 as an experimental feature. May change or be removed
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment