diff options
Diffstat (limited to 'doc/ci/pipelines/settings.md')
| -rw-r--r-- | doc/ci/pipelines/settings.md | 106 |
1 files changed, 53 insertions, 53 deletions
diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md index 32221b78039..e607bae53bd 100644 --- a/doc/ci/pipelines/settings.md +++ b/doc/ci/pipelines/settings.md @@ -6,7 +6,7 @@ disqus_identifier: 'https://docs.gitlab.com/ee/user/project/pipelines/settings.h type: reference, howto --- -# Pipeline settings +# Pipeline settings **(FREE)** To reach the pipelines settings navigate to your project's **Settings > CI/CD**. @@ -17,6 +17,11 @@ The following settings can be configured per project. For an overview, watch the video [GitLab CI Pipeline, Artifacts, and Environments](https://www.youtube.com/watch?v=PCKDICEe10s). Watch also [GitLab CI pipeline tutorial for beginners](https://www.youtube.com/watch?v=Jav4vbUrqII). +You can use the pipeline status to determine if a merge request can be merged: + +- [Merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md). +- [Only allow merge requests to be merged if the pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds). + ## Git strategy With Git strategy, you can choose the default way your repository is fetched @@ -24,7 +29,7 @@ from GitLab in a job. There are two options. Using: -- `git clone`, which is slower since it clones the repository from scratch +- `git clone`, which is slower because it clones the repository from scratch for every job, ensuring that the local working copy is always pristine. - `git fetch`, which is default in GitLab and faster as it re-uses the local working copy (falling back to clone if it doesn't exist). @@ -70,20 +75,19 @@ For information about setting a maximum artifact size for a project, see ## Custom CI/CD configuration path -> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12509) in GitLab 9.4. -> - [Support for external `.gitlab-ci.yml` locations](https://gitlab.com/gitlab-org/gitlab/-/issues/14376) introduced in GitLab 12.6. +> [Support for external `.gitlab-ci.yml` locations](https://gitlab.com/gitlab-org/gitlab/-/issues/14376) introduced in GitLab 12.6. By default we look for the `.gitlab-ci.yml` file in the project's root directory. If needed, you can specify an alternate path and filename, including locations outside the project. To customize the path: -1. Go to the project's **Settings > CI / CD**. +1. Go to the project's **Settings > CI/CD**. 1. Expand the **General pipelines** section. 1. Provide a value in the **CI/CD configuration file** field. 1. Click **Save changes**. -If the CI configuration is stored within the repository in a non-default +If the CI configuration is stored in the repository in a non-default location, the path must be relative to the root directory. Examples of valid paths and file names include: @@ -96,7 +100,7 @@ If hosting the CI configuration on an external site, the URL link must end with - `http://example.com/generate/ci/config.yml` -If hosting the CI configuration in a different project within GitLab, the path must be relative +If hosting the CI configuration in a different project in GitLab, the path must be relative to the root directory in the other project. Include the group and project name at the end: - `.gitlab-ci.yml@mygroup/another-project` @@ -114,10 +118,10 @@ able to edit it. ## Test coverage parsing If you use test coverage in your code, GitLab can capture its output in the -job log using a regular expression. In the pipelines settings, search for the -"Test coverage parsing" section. +job log using a regular expression. - +In your project, go to **Settings > CI/CD** and expand the **General pipelines** +section. Enter the regular expression in the **Test coverage parsing** field. Leave blank if you want to disable it or enter a Ruby regular expression. You can use <https://rubular.com> to test your regex. The regex returns the **last** @@ -133,19 +137,21 @@ averaged. <!-- vale gitlab.Spelling = NO --> -| Coverage Tool | Sample regular expression | -|------------------------------------------------|---------------------------| -| Simplecov (Ruby) | `\(\d+.\d+\%\) covered` | -| pytest-cov (Python) | `^TOTAL.+?(\d+\%)$` | +| Coverage Tool | Sample regular expression | +|------------------------------------------------|-----------------------------------------------| +| Simplecov (Ruby) | `\(\d+.\d+\%\) covered` | +| pytest-cov (Python) | `^TOTAL.+?(\d+\%)$` | | Scoverage (Scala) | `Statement coverage[A-Za-z\.*]\s*:\s*([^%]+)` | -| `phpunit --coverage-text --colors=never` (PHP) | `^\s*Lines:\s*\d+.\d+\%` | -| gcovr (C/C++) | `^TOTAL.*\s+(\d+\%)$` | -| `tap --coverage-report=text-summary` (NodeJS) | `^Statements\s*:\s*([^%]+)` | -| `nyc npm test` (NodeJS) | `All files[^|]*\|[^|]*\s+([\d\.]+)` | -| excoveralls (Elixir) | `\[TOTAL\]\s+(\d+\.\d+)%` | -| `mix test --cover` (Elixir) | `\d+.\d+\%\s+\|\s+Total` | -| JaCoCo (Java/Kotlin) | `Total.*?([0-9]{1,3})%` | -| `go test -cover` (Go) | `coverage: \d+.\d+% of statements` | +| `phpunit --coverage-text --colors=never` (PHP) | `^\s*Lines:\s*\d+.\d+\%` | +| gcovr (C/C++) | `^TOTAL.*\s+(\d+\%)$` | +| `tap --coverage-report=text-summary` (NodeJS) | `^Statements\s*:\s*([^%]+)` | +| `nyc npm test` (NodeJS) | `All files[^|]*\|[^|]*\s+([\d\.]+)` | +| excoveralls (Elixir) | `\[TOTAL\]\s+(\d+\.\d+)%` | +| `mix test --cover` (Elixir) | `\d+.\d+\%\s+\|\s+Total` | +| JaCoCo (Java/Kotlin) | `Total.*?([0-9]{1,3})%` | +| `go test -cover` (Go) | `coverage: \d+.\d+% of statements` | +| .Net (OpenCover) | `(Visited Points).*\((.*)\)` | +| .Net (`dotnet test` line coverage) | `Total\s*\|\s*(\d+\.?\d+)` | <!-- vale gitlab.Spelling = YES --> @@ -157,11 +163,13 @@ averaged. To see the evolution of your project code coverage over time, you can view a graph or download a CSV file with this data. From your project: -1. Go to **{chart}** **Project Analytics > Repository** to see the historic data for each job listed in the dropdown above the graph. +1. Go to **Project Analytics > Repository** to see the historic data for each job listed in the dropdown above the graph. 1. If you want a CSV file of that data, click **Download raw data (`.csv`)**  +Code coverage data is also [available at the group level](../../user/group/repositories_analytics/index.md). + ### Removing color codes Some test coverage tools output with ANSI color codes that aren't @@ -215,11 +223,9 @@ If **Public pipelines** is disabled: ## Auto-cancel redundant pipelines -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/9362) in GitLab 9.1. - You can set pending or running pipelines to cancel automatically when a new pipeline runs on the same branch. You can enable this in the project settings: -1. Go to **Settings > CI / CD**. +1. Go to **Settings > CI/CD**. 1. Expand **General Pipelines**. 1. Check the **Auto-cancel redundant pipelines** checkbox. 1. Click **Save changes**. @@ -232,14 +238,14 @@ running job can be cancelled before it completes. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25276) in GitLab 12.9. Your project may have multiple concurrent deployment jobs that are -scheduled to run within the same time frame. +scheduled to run in the same time frame. This can lead to a situation where an older deployment job runs after a newer one, which may not be what you want. To avoid this scenario: -1. Go to **Settings > CI / CD**. +1. Go to **Settings > CI/CD**. 1. Expand **General pipelines**. 1. Check the **Skip outdated deployment jobs** checkbox. 1. Click **Save changes**. @@ -272,15 +278,15 @@ pages. ### Pipeline status badge -Depending on the status of your job, a badge can have the following values: +Depending on the status of your pipeline, a badge can have the following values: -- pending -- running -- passed -- failed -- skipped -- canceled -- unknown +- `pending` +- `running` +- `passed` +- `failed` +- `skipped` +- `canceled` +- `unknown` You can access a pipeline status badge image using the following link: @@ -321,29 +327,27 @@ into your `README.md`: Pipeline badges can be rendered in different styles by adding the `style=style_name` parameter to the URL. Two styles are available: -#### Flat (default) +- Flat (default): -```plaintext -https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat -``` + ```plaintext + https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat + ``` - +  -#### Flat square +- Flat square ([Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/30120) in GitLab 11.8): -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/30120) in GitLab 11.8. + ```plaintext + https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat-square + ``` -```plaintext -https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat-square -``` - - +  ### Custom badge text > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/17555) in GitLab 13.1. -The text for a badge can be customized. This can be useful to differentiate between multiple coverage jobs that run in the same pipeline. Customize the badge text and width by adding the `key_text=custom_text` and `key_width=custom_key_width` parameters to the URL: +The text for a badge can be customized to differentiate between multiple coverage jobs that run in the same pipeline. Customize the badge text and width by adding the `key_text=custom_text` and `key_width=custom_key_width` parameters to the URL: ```plaintext https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=karma&key_text=Frontend+Coverage&key_width=130 @@ -351,10 +355,6 @@ https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=karma&key_te  -## CI/CD Variables - -[CI/CD variables](../variables/README.md) can be set to be available to a runner. - <!-- ## Troubleshooting Include any troubleshooting steps that you can foresee. If you know beforehand what issues |