diff options
Diffstat (limited to 'doc/ci/yaml')
-rw-r--r-- | doc/ci/yaml/artifacts_reports.md | 31 | ||||
-rw-r--r-- | doc/ci/yaml/index.md | 43 |
2 files changed, 53 insertions, 21 deletions
diff --git a/doc/ci/yaml/artifacts_reports.md b/doc/ci/yaml/artifacts_reports.md index e010dd21b9e..b30b13e1ec0 100644 --- a/doc/ci/yaml/artifacts_reports.md +++ b/doc/ci/yaml/artifacts_reports.md @@ -80,9 +80,14 @@ GitLab can display the results of one or more reports in: - The [security dashboard](../../user/application_security/security_dashboard/index.md). - The [Project Vulnerability report](../../user/application_security/vulnerability_report/index.md). -## `artifacts:reports:cobertura` +## `artifacts:reports:cobertura` (DEPRECATED) -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3708) in GitLab 12.9. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3708) in GitLab 12.9. +> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/78132) in GitLab 14.9. + +WARNING: +This feature is in its end-of-life process. It is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/78132) in GitLab +14.9 and replaced with `artifacts:reports:coverage_report` in 14.10. The `cobertura` report collects [Cobertura coverage XML files](../../user/project/merge_requests/test_coverage_visualization.md). The collected Cobertura coverage reports upload to GitLab as an artifact. @@ -93,6 +98,28 @@ GitLab can display the results of one or more reports in the merge request Cobertura was originally developed for Java, but there are many third-party ports for other languages such as JavaScript, Python, and Ruby. +## `artifacts:reports:coverage_report` + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/344533) in GitLab 14.9. + +Use `coverage_report` to collect coverage report in Cobertura format, similar to `artifacts:reports:cobertura`. + +NOTE: +`artifacts:reports:coverage_report` cannot be used at the same time with `artifacts:reports:cobertura`. + +```yaml +artifacts: + reports: + coverage_report: + coverage_format: cobertura + path: coverage/cobertura-coverage.xml +``` + +The collected coverage report is uploaded to GitLab as an artifact. + +GitLab can display the results of coverage report in the merge request +[diff annotations](../../user/project/merge_requests/test_coverage_visualization.md). + ## `artifacts:reports:codequality` > [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/212499) to GitLab Free in 13.2. diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md index a3b91da8f08..b335e8e8545 100644 --- a/doc/ci/yaml/index.md +++ b/doc/ci/yaml/index.md @@ -395,13 +395,13 @@ When no rules evaluate to true, the pipeline does not run. ```yaml workflow: rules: - - if: $CI_COMMIT_MESSAGE =~ /-draft$/ + - if: $CI_COMMIT_TITLE =~ /-draft$/ when: never - if: $CI_PIPELINE_SOURCE == "merge_request_event" - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH ``` -In this example, pipelines run if the commit message does not have `-drafts` in it +In this example, pipelines run if the commit title (first line of the commit message) does not end with `-draft` and the pipeline is for either: - A merge request @@ -2484,8 +2484,10 @@ Use `changes` in pipelines with the following refs: - Paths to files. - Wildcard paths for single directories, for example `path/to/directory/*`, or a directory and all its subdirectories, for example `path/to/directory/**/*`. -- Wildcard ([glob](https://en.wikipedia.org/wiki/Glob_(programming))) paths for all +- Wildcard [glob](https://en.wikipedia.org/wiki/Glob_(programming)) paths for all files with the same extension or multiple extensions, for example `*.md` or `path/to/directory/*.{rb,py,sh}`. + See the [Ruby `fnmatch` documentation](https://docs.ruby-lang.org/en/master/File.html#method-c-fnmatch) + for the supported syntax list. - Wildcard paths to files in the root directory, or all directories, wrapped in double quotes. For example `"*.json"` or `"**/*.json"`. @@ -2620,9 +2622,11 @@ Multiple runners must exist, or a single runner must be configured to run multip **Keyword type**: Job keyword. You can use it only as part of a job. -**Possible inputs**: +**Possible inputs**: An array of hashes of variables: -- A numeric value from `2` to `50`. +- The variable names can use only numbers, letters, and underscores (`_`). +- The values must be either a string, or an array of strings. +- The number of permutations cannot exceed 50. **Example of `parallel:matrix`**: @@ -2692,18 +2696,19 @@ you can use this image from the GitLab Container Registry: `registry.gitlab.com/ **Example of `release` keyword**: - ```yaml - release_job: - stage: release - image: registry.gitlab.com/gitlab-org/release-cli:latest - rules: - - if: $CI_COMMIT_TAG # Run this job when a tag is created manually - script: - - echo "Running the release job." - release: - name: 'Release $CI_COMMIT_TAG' - description: 'Release created using the release-cli.' - ``` +```yaml +release_job: + stage: release + image: registry.gitlab.com/gitlab-org/release-cli:latest + rules: + - if: $CI_COMMIT_TAG # Run this job when a tag is created manually + script: + - echo "Running the release job." + release: + tag_name: $CI_COMMIT_TAG + name: 'Release $CI_COMMIT_TAG' + description: 'Release created using the release-cli.' +``` This example creates a release: @@ -3100,7 +3105,7 @@ to specific files. WARNING: You should use `rules: changes` only with **branch pipelines** or **merge request pipelines**. You can use `rules: changes` with other pipeline types, but `rules: changes` always -evaluates to true when there is no Git `push` event. Tag pipelines, scheduled pipelines, +evaluates to true when there is no Git `push` event. Tag pipelines, scheduled pipelines, manual pipelines, and so on do **not** have a Git `push` event associated with them. A `rules: changes` job is **always** added to those pipelines if there is no `if` that limits the job to branch or merge request pipelines. @@ -3709,7 +3714,7 @@ and [multi-project pipelines](../pipelines/multi_project_pipelines.md). - `yaml_variables`: `true` (default), or `false`. When `true`, variables defined in the trigger job are passed to downstream pipelines. -- `pipeline_variables`: `true` or `false` (default). When `true`, [manual pipeline variables](../variables/index.md#override-a-defined-cicd-variable) +- `pipeline_variables`: `true` or `false` (default). When `true`, [manual pipeline variables](../variables/index.md#override-a-defined-cicd-variable) and [scheduled pipeline variables](../pipelines/schedules.md#add-a-pipeline-schedule) are passed to downstream pipelines. **Example of `trigger:forward`**: |