diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-04-28 06:09:53 +0300 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-04-28 06:09:53 +0300 |
| commit | 2e4d8b3449e8c2c750a816b9566c61a0a96b934b (patch) | |
| tree | 831b4d55a3b283e519a4c911e444564d4c7c3344 /doc | |
| parent | 56df7f06f1e57d66efcff5d8ad0026252cc91192 (diff) | |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
25 files changed, 612 insertions, 563 deletions
diff --git a/doc/.vale/gitlab/spelling-exceptions.txt b/doc/.vale/gitlab/spelling-exceptions.txt index cd951c29e23..1612853042c 100644 --- a/doc/.vale/gitlab/spelling-exceptions.txt +++ b/doc/.vale/gitlab/spelling-exceptions.txt @@ -55,6 +55,7 @@ CentOS Chatops Citrix Cloudwatch +Cobertura Cognito colocated colocating @@ -85,6 +86,7 @@ discoverability Disqus Dockerfile Dockerfiles +dotenv downvoted downvotes Dpl diff --git a/doc/ci/environments.md b/doc/ci/environments.md index c3397494c6a..e8707589f0c 100644 --- a/doc/ci/environments.md +++ b/doc/ci/environments.md @@ -173,7 +173,7 @@ GitLab supports [dotenv](https://github.com/bkeepers/dotenv) file as the format, and expands the `environment:url` value with variables defined in the dotenv file. To use this feature, specify the -[`artifacts:reports:dotenv`](yaml/README.md#artifactsreportsdotenv) keyword in `.gitlab-ci.yml`. +[`artifacts:reports:dotenv`](pipelines/job_artifacts.md#artifactsreportsdotenv) keyword in `.gitlab-ci.yml`. <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> For an overview, see [Set dynamic URLs after a job finished](https://youtu.be/70jDXtOf4Ig). diff --git a/doc/ci/junit_test_reports.md b/doc/ci/junit_test_reports.md index 59a47d782fb..54d39c59248 100644 --- a/doc/ci/junit_test_reports.md +++ b/doc/ci/junit_test_reports.md @@ -68,7 +68,7 @@ For a list of supported languages on JUnit tests, check the [Wikipedia article](https://en.wikipedia.org/wiki/JUnit#Ports). To enable the JUnit reports in merge requests, you need to add -[`artifacts:reports:junit`](yaml/README.md#artifactsreportsjunit) +[`artifacts:reports:junit`](pipelines/job_artifacts.md#artifactsreportsjunit) in `.gitlab-ci.yml`, and specify the path(s) of the generated test reports. In the following examples, the job in the `test` stage runs and GitLab diff --git a/doc/ci/metrics_reports.md b/doc/ci/metrics_reports.md index d5c76c1f3f9..f353aa2670f 100644 --- a/doc/ci/metrics_reports.md +++ b/doc/ci/metrics_reports.md @@ -34,7 +34,7 @@ All values are considered strings and string compare is used to find differences ## How to set it up -Add a job that creates a [metrics report](yaml/README.md#artifactsreportsmetrics-premium) (default filename: `metrics.txt`). The file should conform to the [OpenMetrics](https://openmetrics.io/) format. +Add a job that creates a [metrics report](pipelines/job_artifacts.md#artifactsreportsmetrics-premium) (default filename: `metrics.txt`). The file should conform to the [OpenMetrics](https://openmetrics.io/) format. For example: diff --git a/doc/ci/pipelines/job_artifacts.md b/doc/ci/pipelines/job_artifacts.md index ed791ea9c4a..030643ba76b 100644 --- a/doc/ci/pipelines/job_artifacts.md +++ b/doc/ci/pipelines/job_artifacts.md @@ -6,9 +6,9 @@ type: reference, howto # Job artifacts > - Introduced in GitLab 8.2 and GitLab Runner 0.7.0. -> - Starting with GitLab 8.4 and GitLab Runner 1.0, the artifacts archive format changed to `ZIP`, and it is now possible to browse its contents, with the added ability of downloading the files separately. +> - Starting with GitLab 8.4 and GitLab Runner 1.0, the artifacts archive format changed to `ZIP`, and it's now possible to browse its contents, with the added ability of downloading the files separately. > - In GitLab 8.17, builds were renamed to jobs. -> - The artifacts browser will be available only for new artifacts that are sent to GitLab using GitLab Runner version 1.0 and up. It will not be possible to browse old artifacts already uploaded to GitLab. +> - The artifacts browser will be available only for new artifacts that are sent to GitLab using GitLab Runner version 1.0 and up. It won't be possible to browse old artifacts already uploaded to GitLab. Job artifacts are a list of files and directories created by a job once it finishes. This feature is [enabled by default](../../administration/job_artifacts.md) in all @@ -34,7 +34,7 @@ pdf: expire_in: 1 week ``` -A job named `pdf` calls the `xelatex` command in order to build a pdf file from +A job named `pdf` calls the `xelatex` command in order to build a PDF file from the latex source file `mycv.tex`. We then define the `artifacts` paths which in turn are defined with the `paths` keyword. All paths to files and directories are relative to the repository that was cloned during the build. @@ -42,28 +42,230 @@ are relative to the repository that was cloned during the build. The artifacts will be uploaded when the job succeeds by default, but can be set to upload when the job fails, or always, if the [`artifacts:when`](../yaml/README.md#artifactswhen) parameter is used. These uploaded artifacts will be kept in GitLab for 1 week as defined -by the `expire_in` definition. You have the option to keep the artifacts from expiring +by the `expire_in` definition. You can keep the artifacts from expiring via the [web interface](#browsing-artifacts). If the expiry time is not defined, it defaults to the [instance wide setting](../../user/admin_area/settings/continuous_integration.md#default-artifacts-expiration-core-only). For more examples on artifacts, follow the [artifacts reference in `.gitlab-ci.yml`](../yaml/README.md#artifacts). +### `artifacts:reports` + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20390) in GitLab 11.2. +> - Requires GitLab Runner 11.2 and above. + +The `artifacts:reports` keyword is used for collecting test reports, code quality +reports, and security reports from jobs. It also exposes these reports in GitLab's +UI (merge requests, pipeline views, and security dashboards). + +NOTE: **Note:** +The test reports are collected regardless of the job results (success or failure). +You can use [`artifacts:expire_in`](../yaml/README.md#artifactsexpire_in) to set up an expiration +date for their artifacts. + +NOTE: **Note:** +If you also want the ability to browse the report output files, include the +[`artifacts:paths`](../yaml/README.md#artifactspaths) keyword. + +#### `artifacts:reports:junit` + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20390) in GitLab 11.2. +> - Requires GitLab Runner 11.2 and above. + +The `junit` report collects [JUnit XML files](https://www.ibm.com/support/knowledgecenter/en/SSQ2R2_14.1.0/com.ibm.rsar.analysis.codereview.cobol.doc/topics/cac_useresults_junit.html) +as artifacts. Although JUnit was originally developed in Java, there are many +[third party ports](https://en.wikipedia.org/wiki/JUnit#Ports) for other +languages like JavaScript, Python, Ruby, and so on. + +See [JUnit test reports](../junit_test_reports.md) for more details and examples. +Below is an example of collecting a JUnit XML file from Ruby's RSpec test tool: + +```yaml +rspec: + stage: test + script: + - bundle install + - rspec --format RspecJunitFormatter --out rspec.xml + artifacts: + reports: + junit: rspec.xml +``` + +The collected JUnit reports will be uploaded to GitLab as an artifact and will +be automatically shown in merge requests. + +NOTE: **Note:** +In case the JUnit tool you use exports to multiple XML files, you can specify +multiple test report paths within a single job and they will be automatically +concatenated into a single file. Use a filename pattern (`junit: rspec-*.xml`), +an array of filenames (`junit: [rspec-1.xml, rspec-2.xml, rspec-3.xml]`), or a +combination thereof (`junit: [rspec.xml, test-results/TEST-*.xml]`). + +#### `artifacts:reports:dotenv` + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/17066) in GitLab 12.9. +> - Requires GitLab Runner 11.5 and later. + +The `dotenv` report collects a set of environment variables as artifacts. + +The collected variables are registered as runtime-created variables of the job, +which is useful to [set dynamic environment URLs after a job finishes](../environments.md#set-dynamic-environment-urls-after-a-job-finishes). +It's not available for download through the web interface. + +There are a couple of limitations on top of the [original dotenv rules](https://github.com/motdotla/dotenv#rules). + +- The variable key can contain only letters, digits and underscore ('_'). +- The size of the dotenv file must be smaller than 5 kilobytes. +- The number of variables must be less than 10. +- It does not support variable substitution in the dotenv file itself. +- It does not support empty lines and comments (`#`) in dotenv file. +- It does not support quote escape, spaces in a quote, a new line expansion in a quote, in dotenv file. + +#### `artifacts:reports:cobertura` + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/3708) in GitLab 12.9. +> - Requires [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 and above. + +The `cobertura` report collects [Cobertura coverage XML files](../../user/project/merge_requests/test_coverage_visualization.md). +The collected Cobertura coverage reports will be uploaded to GitLab as an artifact +and will be automatically shown in merge requests. + +Cobertura was originally developed for Java, but there are many +third party ports for other languages like JavaScript, Python, Ruby, and so on. + +#### `artifacts:reports:terraform` + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/207527) in GitLab 12.10. +> - Requires [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 and above. + +The `terraform` report collects Terraform `tfplan.json` files. The collected Terraform +plan reports will be uploaded to GitLab as artifacts and will be automatically shown +in merge requests. + +#### `artifacts:reports:codequality` **(STARTER)** + +> - Introduced in GitLab 11.5. +> - Requires GitLab Runner 11.5 and above. + +The `codequality` report collects [CodeQuality issues](../../user/project/merge_requests/code_quality.md) +as artifacts. + +The collected Code Quality report will be uploaded to GitLab as an artifact and will +be summarized in merge requests. It's not available for download through the web interface. + +#### `artifacts:reports:sast` **(ULTIMATE)** + +> - Introduced in GitLab 11.5. +> - Requires GitLab Runner 11.5 and above. + +The `sast` report collects [SAST vulnerabilities](../../user/application_security/sast/index.md) +as artifacts. + +The collected SAST report will be uploaded to GitLab as an artifact and will be summarized +in the merge requests and pipeline view. It's also used to provide data for security +dashboards. It's not available for download through the web interface. + +#### `artifacts:reports:dependency_scanning` **(ULTIMATE)** + +> - Introduced in GitLab 11.5. +> - Requires GitLab Runner 11.5 and above. + +The `dependency_scanning` report collects [Dependency Scanning vulnerabilities](../../user/application_security/dependency_scanning/index.md) +as artifacts. + +The collected Dependency Scanning report will be uploaded to GitLab as an artifact and will +be summarized in the merge requests and pipeline view. It's also used to provide data for security +dashboards. It's not available for download through the web interface. + +#### `artifacts:reports:container_scanning` **(ULTIMATE)** + +> - Introduced in GitLab 11.5. +> - Requires GitLab Runner 11.5 and above. + +The `container_scanning` report collects [Container Scanning vulnerabilities](../../user/application_security/container_scanning/index.md) +as artifacts. + +The collected Container Scanning report will be uploaded to GitLab as an artifact and will +be summarized in the merge requests and pipeline view. It's also used to provide data for security +dashboards. It's not available for download through the web interface. + +#### `artifacts:reports:dast` **(ULTIMATE)** + +> - Introduced in GitLab 11.5. +> - Requires GitLab Runner 11.5 and above. + +The `dast` report collects [DAST vulnerabilities](../../user/application_security/dast/index.md) +as artifacts. + +The collected DAST report will be uploaded to GitLab as an artifact and will +be summarized in the merge requests and pipeline view. It's also used to provide data for security +dashboards. It's not available for download through the web interface. + +#### `artifacts:reports:license_management` **(ULTIMATE)** + +> - Introduced in GitLab 11.5. +> - Requires GitLab Runner 11.5 and above. + +CAUTION: **Warning:** +This artifact is still valid but is **deprecated** in favor of the +[artifacts:reports:license_scanning](../pipelines/job_artifacts.md#artifactsreportslicense_scanning-ultimate) +introduced in GitLab 12.8. + +The `license_management` report collects [Licenses](../../user/compliance/license_compliance/index.md) +as artifacts. + +The collected License Compliance report will be uploaded to GitLab as an artifact and will +be summarized in the merge requests and pipeline view. It's also used to provide data for security +dashboards. It's not available for download through the web interface. + +#### `artifacts:reports:license_scanning` **(ULTIMATE)** + +> - Introduced in GitLab 12.8. +> - Requires GitLab Runner 11.5 and above. + +The `license_scanning` report collects [Licenses](../../user/compliance/license_compliance/index.md) +as artifacts. + +The License Compliance report will be uploaded to GitLab as an artifact and will +be automatically shown in merge requests, pipeline view and provide data for security +dashboards. + +#### `artifacts:reports:performance` **(PREMIUM)** + +> - Introduced in GitLab 11.5. +> - Requires GitLab Runner 11.5 and above. + +The `performance` report collects [Performance metrics](../../user/project/merge_requests/browser_performance_testing.md) +as artifacts. + +The collected Performance report will be uploaded to GitLab as an artifact and will +be automatically shown in merge requests. It's not available for download through the web interface. + +#### `artifacts:reports:metrics` **(PREMIUM)** + +> Introduced in GitLab 11.10. + +The `metrics` report collects [Metrics](../metrics_reports.md) +as artifacts. + +The collected Metrics report will be uploaded to GitLab as an artifact and will +be automatically shown in merge requests. It's not available for download through the web interface. + ## Browsing artifacts -> - From GitLab 9.2, PDFs, images, videos and other formats can be previewed directly in the job artifacts browser without the need to download them. +> - From GitLab 9.2, PDFs, images, videos, and other formats can be previewed directly in the job artifacts browser without the need to download them. > - Introduced in [GitLab 10.1](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14399), HTML files in a public project can be previewed directly in a new tab without the need to download them when [GitLab Pages](../../administration/pages/index.md) is enabled. The same applies for textual formats (currently supported extensions: `.txt`, `.json`, and `.log`). > - Introduced in [GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16675), artifacts in private projects can be previewed when [GitLab Pages access control](../../administration/pages/index.md#access-control) is enabled. After a job finishes, if you visit the job's specific page, there are three buttons. You can download the artifacts archive or browse its contents, whereas -the **Keep** button appears only if you have set an [expiry date](../yaml/README.md#artifactsexpire_in) to the +the **Keep** button appears only if you've set an [expiry date](../yaml/README.md#artifactsexpire_in) to the artifacts in case you changed your mind and want to keep them.  The archive browser shows the name and the actual file size of each file in the -archive. If your artifacts contained directories, then you are also able to +archive. If your artifacts contained directories, then you're also able to browse inside them. Below you can see what browsing looks like. In this case we have browsed inside @@ -88,7 +290,7 @@ in the GitLab UI to do this:  -1. While inside a specific job, you are presented with a download button +1. While inside a specific job, you're presented with a download button along with the one that browses the archive:  @@ -100,7 +302,7 @@ in the GitLab UI to do this: ## Downloading the latest artifacts -It is possible to download the latest artifacts of a job via a well known URL +It's possible to download the latest artifacts of a job via a well known URL so you can use it for scripting purposes. NOTE: **Note:** @@ -151,7 +353,7 @@ For example: https://gitlab.com/gitlab-org/gitlab/-/jobs/artifacts/master/browse?job=coverage ``` -There is also a URL to specific files, including html files that +There is also a URL to specific files, including HTML files that are shown in [GitLab Pages](../../administration/pages/index.md): ```plaintext diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 25544124f18..400729db790 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -327,8 +327,6 @@ otherwise the external file will not be included. | [`remote`](#includeremote) | Include a file from a remote URL. Must be publicly accessible. | | [`template`](#includetemplate) | Include templates which are provided by GitLab. | -See [usage examples](#include-examples). - NOTE: **Note:** `.gitlab-ci.yml` configuration included by all methods is evaluated at pipeline creation. The configuration is a snapshot in time and persisted in the database. Any changes to @@ -461,224 +459,15 @@ so it is possible to use project, remote or template includes. > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/56836) in GitLab 11.9. Nested includes allow you to compose a set of includes. -A total of 100 includes is allowed. -Duplicate includes are considered a configuration error. - -> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/28212) in GitLab 12.4. - -A hard limit of 30 seconds was set for resolving all files. - -#### `include` examples - -Here are a few more `include` examples. - -##### Single string or array of multiple values - -You can include your extra YAML file(s) either as a single string or -an array of multiple values. The following examples are all valid. - -Single string with the `include:local` method implied: - -```yaml -include: '/templates/.after-script-template.yml' -``` - -Array with `include` method implied: - -```yaml -include: - - 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml' - - '/templates/.after-script-template.yml' -``` - -Single string with `include` method specified explicitly: - -```yaml -include: - remote: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml' -``` - -Array with `include:remote` being the single item: - -```yaml -include: - - remote: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml' -``` - -Array with multiple `include` methods specified explicitly: - -```yaml -include: - - remote: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml' - - local: '/templates/.after-script-template.yml' - - template: Auto-DevOps.gitlab-ci.yml -``` - -Array mixed syntax: - -```yaml -include: - - 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml' - - '/templates/.after-script-template.yml' - - template: Auto-DevOps.gitlab-ci.yml - - project: 'my-group/my-project' - ref: master - file: '/templates/.gitlab-ci-template.yml' -``` - -##### Re-using a `before_script` template - -In the following example, the content of `.before-script-template.yml` will be -automatically fetched and evaluated along with the content of `.gitlab-ci.yml`. - -Content of `https://gitlab.com/awesome-project/raw/master/.before-script-template.yml`: - -```yaml -before_script: - - apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs - - gem install bundler --no-document - - bundle install --jobs $(nproc) "${FLAGS[@]}" -``` - -Content of `.gitlab-ci.yml`: -```yaml -include: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml' - -rspec: - script: - - bundle exec rspec -``` - -##### Overriding external template values - -The following example shows specific YAML-defined variables and details of the -`production` job from an include file being customized in `.gitlab-ci.yml`. - -Content of `https://company.com/autodevops-template.yml`: - -```yaml -variables: - POSTGRES_USER: user - POSTGRES_PASSWORD: testing_password - POSTGRES_DB: $CI_ENVIRONMENT_SLUG - -production: - stage: production - script: - - install_dependencies - - deploy - environment: - name: production - url: https://$CI_PROJECT_PATH_SLUG.$KUBE_INGRESS_BASE_DOMAIN - only: - - master -``` - -Content of `.gitlab-ci.yml`: - -```yaml -include: 'https://company.com/autodevops-template.yml' - -image: alpine:latest +A total of 100 includes is allowed, but duplicate includes are considered a configuration error. -variables: - POSTGRES_USER: root - POSTGRES_PASSWORD: secure_password - -stages: - - build - - test - - production - -production: - environment: - url: https://domain.com -``` - -In this case, the variables `POSTGRES_USER` and `POSTGRES_PASSWORD` along -with the environment url of the `production` job defined in -`autodevops-template.yml` have been overridden by new values defined in -`.gitlab-ci.yml`. - -The merging lets you extend and override dictionary mappings, but -you cannot add or modify items to an included array. For example, to add -an additional item to the production job script, you must repeat the -existing script items: - -Content of `https://company.com/autodevops-template.yml`: +Since [GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/issues/28212), the time limit +for resolving all files is 30 seconds. -```yaml -production: - stage: production - script: - - install_dependencies - - deploy -``` - -Content of `.gitlab-ci.yml`: - -```yaml -include: 'https://company.com/autodevops-template.yml' - -stages: - - production +#### Additional `includes` examples -production: - script: - - install_dependencies - - deploy - - notify_owner -``` - -In this case, if `install_dependencies` and `deploy` were not repeated in -`.gitlab-ci.yml`, they would not be part of the script for the `production` -job in the combined CI configuration. - -##### Using nested includes - -The examples below show how includes can be nested from different sources -using a combination of different methods. - -In this example, `.gitlab-ci.yml` includes local the file `/.gitlab-ci/another-config.yml`: - -```yaml -include: - - local: /.gitlab-ci/another-config.yml -``` - -The `/.gitlab-ci/another-config.yml` includes a template and the `/templates/docker-workflow.yml` file -from another project: - -```yaml -include: - - template: Bash.gitlab-ci.yml - - project: group/my-project - file: /templates/docker-workflow.yml -``` - -The `/templates/docker-workflow.yml` present in `group/my-project` includes two local files -of the `group/my-project`: - -```yaml -include: - - local: /templates/docker-build.yml - - local: /templates/docker-testing.yml -``` - -Our `/templates/docker-build.yml` present in `group/my-project` adds a `docker-build` job: - -```yaml -docker-build: - script: docker build -t my-image . -``` - -Our second `/templates/docker-test.yml` present in `group/my-project` adds a `docker-test` job: - -```yaml -docker-test: - script: docker run my-image /run/tests.sh -``` +There is a list of [additional `includes` examples](includes.md) available. ## Parameter details @@ -2945,191 +2734,27 @@ and later, the latest artifact for a ref is always kept, regardless of the expir #### `artifacts:reports` -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20390) in GitLab 11.2. Requires GitLab Runner 11.2 and above. - -The `reports` keyword is used for collecting test reports, code quality reports, and security reports from jobs. +The [`artifacts:reports` keyword](../pipelines/job_artifacts.md#artifactsreports) +is used for collecting test reports, code quality reports, and security reports from jobs. It also exposes these reports in GitLab's UI (merge requests, pipeline views, and security dashboards). -NOTE: **Note:** -The test reports are collected regardless of the job results (success or failure). -You can use [`artifacts:expire_in`](#artifactsexpire_in) to set up an expiration -date for their artifacts. - -NOTE: **Note:** -If you also want the ability to browse the report output files, include the -[`artifacts:paths`](#artifactspaths) keyword. - -##### `artifacts:reports:junit` - -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20390) in GitLab 11.2. Requires GitLab Runner 11.2 and above. - -The `junit` report collects [JUnit XML files](https://www.ibm.com/support/knowledgecenter/en/SSQ2R2_14.1.0/com.ibm.rsar.analysis.codereview.cobol.doc/topics/cac_useresults_junit.html) -as artifacts. Although JUnit was originally developed in Java, there are many -[third party ports](https://en.wikipedia.org/wiki/JUnit#Ports) for other -languages like JavaScript, Python, Ruby, etc. - -See [JUnit test reports](../junit_test_reports.md) for more details and examples. -Below is an example of collecting a JUnit XML file from Ruby's RSpec test tool: - -```yaml -rspec: - stage: test - script: - - bundle install - - rspec --format RspecJunitFormatter --out rspec.xml - artifacts: - reports: - junit: rspec.xml -``` - -The collected JUnit reports will be uploaded to GitLab as an artifact and will -be automatically shown in merge requests. - -NOTE: **Note:** -In case the JUnit tool you use exports to multiple XML files, you can specify -multiple test report paths within a single job and they will be automatically -concatenated into a single file. Use a filename pattern (`junit: rspec-*.xml`), -an array of filenames (`junit: [rspec-1.xml, rspec-2.xml, rspec-3.xml]`), or a -combination thereof (`junit: [rspec.xml, test-results/TEST-*.xml]`). - -##### `artifacts:reports:dotenv` - -> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/17066) in GitLab 12.9. Requires GitLab Runner 11.5 and later. - -The `dotenv` report collects a set of environment variables as artifacts. - -The collected variables are registered as runtime-created variables of the job, -which is useful to [set dynamic environment URLs after a job finishes](../environments.md#set-dynamic-environment-urls-after-a-job-finishes). -It is not available for download through the web interface. - -There are a couple of limitations on top of the [original dotenv rules](https://github.com/motdotla/dotenv#rules). - -- The variable key can contain only letters, digits and underscore ('_'). -- The size of dotenv file must be smaller than 5 kilobytes. -- The number of variables must be less than 10. -- It doesn't support variable substitution in the dotenv file itself. -- It doesn't support empty lines and comments (`#`) in dotenv file. -- It doesn't support quote escape, spaces in a quote, a new line expansion in a quote, in dotenv file. - -##### `artifacts:reports:cobertura` - -> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/3708) in GitLab 12.9. Requires [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 and above. - -The `cobertura` report collects [Cobertura coverage XML files](../../user/project/merge_requests/test_coverage_visualization.md). -The collected Cobertura coverage reports will be uploaded to GitLab as an artifact -and will be automatically shown in merge requests. - -Cobertura was originally developed for Java, but there are many -third party ports for other languages like JavaScript, Python, Ruby, etc. - -##### `artifacts:reports:terraform` - -> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/207527) in GitLab 12.10. Requires [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 and above. - -The `terraform` report collects Terraform `tfplan.json` files. The -collected Terraform plan reports will be uploaded to GitLab as -artifacts and will be automatically shown in merge requests. - -##### `artifacts:reports:codequality` **(STARTER)** - -> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above. - -The `codequality` report collects [CodeQuality issues](../../user/project/merge_requests/code_quality.md) -as artifacts. - -The collected Code Quality report will be uploaded to GitLab as an artifact and will -be summarized in merge requests. It is not available for download through the web interface. - -##### `artifacts:reports:sast` **(ULTIMATE)** - -> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above. - -The `sast` report collects [SAST vulnerabilities](../../user/application_security/sast/index.md) -as artifacts. - -The collected SAST report will be uploaded to GitLab as an artifact and will -be summarized in the merge requests and pipeline view. It is also used to provide data for security -dashboards. It is not available for download through the web interface. - -##### `artifacts:reports:dependency_scanning` **(ULTIMATE)** - -> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above. - -The `dependency_scanning` report collects [Dependency Scanning vulnerabilities](../../user/application_security/dependency_scanning/index.md) -as artifacts. - -The collected Dependency Scanning report will be uploaded to GitLab as an artifact and will -be summarized in the merge requests and pipeline view. It is also used to provide data for security -dashboards. It is not available for download through the web interface. - -##### `artifacts:reports:container_scanning` **(ULTIMATE)** - -> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above. - -The `container_scanning` report collects [Container Scanning vulnerabilities](../../user/application_security/container_scanning/index.md) -as artifacts. - -The collected Container Scanning report will be uploaded to GitLab as an artifact and will -be summarized in the merge requests and pipeline view. It is also used to provide data for security -dashboards. It is not available for download through the web interface. - -##### `artifacts:reports:dast` **(ULTIMATE)** - -> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above. - -The `dast` report collects [DAST vulnerabilities](../../user/application_security/dast/index.md) -as artifacts. - -The collected DAST report will be uploaded to GitLab as an artifact and will -be summarized in the merge requests and pipeline view. It is also used to provide data for security -dashboards. It is not available for download through the web interface. - -##### `artifacts:reports:license_management` **(ULTIMATE)** - -CAUTION: **Warning:** -This artifact is still valid but was **deprecated** in favor of the -[artifacts:reports:license_scanning](#artifactsreportslicense_scanning-ultimate) -introduced in GitLab 12.8. - -> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above. - -The `license_management` report collects [Licenses](../../user/compliance/license_compliance/index.md) -as artifacts. - -The collected License Compliance report will be uploaded to GitLab as an artifact and will -be summarized in the merge requests and pipeline view. It is also used to provide data for security -dashboards. It is not available for download through the web interface. - -##### `artifacts:reports:license_scanning` **(ULTIMATE)** - -> Introduced in GitLab 12.8. Requires GitLab Runner 11.5 and above. - -The `license_scanning` report collects [Licenses](../../user/compliance/license_compliance/index.md) -as artifacts. - -The License Compliance report will be uploaded to GitLab as an artifact and will -be automatically shown in merge requests, pipeline view and provide data for security -dashboards. - -##### `artifacts:reports:performance` **(PREMIUM)** - -> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above. - -The `performance` report collects [Performance metrics](../../user/project/merge_requests/browser_performance_testing.md) -as artifacts. - -The collected Performance report will be uploaded to GitLab as an artifact and will -be automatically shown in merge requests. It is not available for download through the web interface. - -##### `artifacts:reports:metrics` **(PREMIUM)** - -> Introduced in GitLab 11.10. - -The `metrics` report collects [Metrics](../../ci/metrics_reports.md) -as artifacts. - -The collected Metrics report will be uploaded to GitLab as an artifact and will -be automatically shown in merge requests. It is not available for download through the web interface. +These are the available report types: + +| Parameter | Description | +|--------------------------------------------------------------------------------------------------------------------------------------|-------------| +| [`artifacts:reports:junit`](../pipelines/job_artifacts.md#artifactsreportsjunit) | The `junit` report collects JUnit XML files. | +| [`artifacts:reports:dotenv`](../pipelines/job_artifacts.md#artifactsreportsdotenv) | The `dotenv` report collects a set of environment variables. | +| [`artifacts:reports:cobertura`](../pipelines/job_artifacts.md#artifactsreportscobertura) | The `cobertura` report collects Cobertura coverage XML files. | +| [`artifacts:reports:terraform`](../pipelines/job_artifacts.md#artifactsreportsterraform) | The `terraform` report collects Terraform `tfplan.json` files. | +| [`artifacts:reports:codequality`](../pipelines/job_artifacts.md#artifactsreportscodequality-starter) **(STARTER)** | The `codequality` report collects CodeQuality issues. | +| [`artifacts:reports:sast`](../pipelines/job_artifacts.md#artifactsreportssast-ultimate) **(ULTIMATE)** | The `sast` report collects Static Application Security Testing vulnerabilities. | +| [`artifacts:reports:dependency_scanning`](../pipelines/job_artifacts.md#artifactsreportsdependency_scanning-ultimate) **(ULTIMATE)** | The `dependency_scanning` report collects Dependency Scanning vulnerabilities. | +| [`artifacts:reports:container_scanning`](../pipelines/job_artifacts.md#artifactsreportscontainer_scanning-ultimate) **(ULTIMATE)** | The `container_scanning` report collects Container Scanning vulnerabilities. | +| [`artifacts:reports:dast`](../pipelines/job_artifacts.md#artifactsreportsdast-ultimate) **(ULTIMATE)** | The `dast` report collects Dynamic Application Security Testing vulnerabilities. | +| [`artifacts:reports:license_management`](../pipelines/job_artifacts.md#artifactsreportslicense_management-ultimate) **(ULTIMATE)** | The `license_management` report collects Licenses (*deprecated*). | +| [`artifacts:reports:license_scanning`](../pipelines/job_artifacts.md#artifactsreportslicense_scanning-ultimate) **(ULTIMATE)** | The `license_scanning` report collects Licenses. | +| [`artifacts:reports:performance`](../pipelines/job_artifacts.md#artifactsreportsperformance-premium) **(PREMIUM)** | The `performance` report collects Performance metrics. | +| [`artifacts:reports:metrics`](../pipelines/job_artifacts.md#artifactsreportsmetrics-premium) **(PREMIUM)** | The `metrics` report collects Metrics. | #### `dependencies` diff --git a/doc/ci/yaml/includes.md b/doc/ci/yaml/includes.md new file mode 100644 index 00000000000..a7b626bdd7c --- /dev/null +++ b/doc/ci/yaml/includes.md @@ -0,0 +1,213 @@ +# GitLab CI/CD YAML includes + +In addition to the [`includes` examples](README.md#include) listed in the +[GitLab CI YAML reference](README.md), this page lists more variations of `include` +usage. + +## Single string or array of multiple values + +You can include your extra YAML file(s) either as a single string or +an array of multiple values. The following examples are all valid. + +Single string with the `include:local` method implied: + +```yaml +include: '/templates/.after-script-template.yml' +``` + +Array with `include` method implied: + +```yaml +include: + - 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml' + - '/templates/.after-script-template.yml' +``` + +Single string with `include` method specified explicitly: + +```yaml +include: + remote: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml' +``` + +Array with `include:remote` being the single item: + +```yaml +include: + - remote: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml' +``` + +Array with multiple `include` methods specified explicitly: + +```yaml +include: + - remote: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml' + - local: '/templates/.after-script-template.yml' + - template: Auto-DevOps.gitlab-ci.yml +``` + +Array mixed syntax: + +```yaml +include: + - 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml' + - '/templates/.after-script-template.yml' + - template: Auto-DevOps.gitlab-ci.yml + - project: 'my-group/my-project' + ref: master + file: '/templates/.gitlab-ci-template.yml' +``` + +## Re-using a `before_script` template + +In the following example, the content of `.before-script-template.yml` will be +automatically fetched and evaluated along with the content of `.gitlab-ci.yml`. + +Content of `https://gitlab.com/awesome-project/raw/master/.before-script-template.yml`: + +```yaml +before_script: + - apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs + - gem install bundler --no-document + - bundle install --jobs $(nproc) "${FLAGS[@]}" +``` + +Content of `.gitlab-ci.yml`: + +```yaml +include: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml' + +rspec: + script: + - bundle exec rspec +``` + +## Overriding external template values + +The following example shows specific YAML-defined variables and details of the +`production` job from an include file being customized in `.gitlab-ci.yml`. + +Content of `https://company.com/autodevops-template.yml`: + +```yaml +variables: + POSTGRES_USER: user + POSTGRES_PASSWORD: testing_password + POSTGRES_DB: $CI_ENVIRONMENT_SLUG + +production: + stage: production + script: + - install_dependencies + - deploy + environment: + name: production + url: https://$CI_PROJECT_PATH_SLUG.$KUBE_INGRESS_BASE_DOMAIN + only: + - master +``` + +Content of `.gitlab-ci.yml`: + +```yaml +include: 'https://company.com/autodevops-template.yml' + +image: alpine:latest + +variables: + POSTGRES_USER: root + POSTGRES_PASSWORD: secure_password + +stages: + - build + - test + - production + +production: + environment: + url: https://domain.com +``` + +In this case, the variables `POSTGRES_USER` and `POSTGRES_PASSWORD` along +with the environment URL of the `production` job defined in +`autodevops-template.yml` have been overridden by new values defined in +`.gitlab-ci.yml`. + +The merging lets you extend and override dictionary mappings, but +you cannot add or modify items to an included array. For example, to add +an additional item to the production job script, you must repeat the +existing script items: + +Content of `https://company.com/autodevops-template.yml`: + +```yaml +production: + stage: production + script: + - install_dependencies + - deploy +``` + +Content of `.gitlab-ci.yml`: + +```yaml +include: 'https://company.com/autodevops-template.yml' + +stages: + - production + +production: + script: + - install_dependencies + - deploy + - notify_owner +``` + +In this case, if `install_dependencies` and `deploy` were not repeated in +`.gitlab-ci.yml`, they would not be part of the script for the `production` +job in the combined CI configuration. + +## Using nested includes + +The examples below show how includes can be nested from different sources +using a combination of different methods. + +In this example, `.gitlab-ci.yml` includes local the file `/.gitlab-ci/another-config.yml`: + +```yaml +include: + - local: /.gitlab-ci/another-config.yml +``` + +The `/.gitlab-ci/another-config.yml` includes a template and the `/templates/docker-workflow.yml` file +from another project: + +```yaml +include: + - template: Bash.gitlab-ci.yml + - project: group/my-project + file: /templates/docker-workflow.yml +``` + +The `/templates/docker-workflow.yml` present in `group/my-project` includes two local files +of the `group/my-project`: + +```yaml +include: + - local: /templates/docker-build.yml + - local: /templates/docker-testing.yml +``` + +Our `/templates/docker-build.yml` present in `group/my-project` adds a `docker-build` job: + +```yaml +docker-build: + script: docker build -t my-image . +``` + +Our second `/templates/docker-test.yml` present in `group/my-project` adds a `docker-test` job: + +```yaml +docker-test: + script: docker run my-image /run/tests.sh +``` diff --git a/doc/development/api_styleguide.md b/doc/development/api_styleguide.md index a9ce1bc066e..25c8cbd3fde 100644 --- a/doc/development/api_styleguide.md +++ b/doc/development/api_styleguide.md @@ -98,14 +98,6 @@ For instance: Model.create(foo: params[:foo]) ``` -## Array types - -With Grape v1.3+, Array types must be defined with a `coerce_with` -block, or parameters will fail to validate when passed a string from an -API request. See the [Grape upgrading -documentation](https://github.com/ruby-grape/grape/blob/master/UPGRADING.md#ensure-that-array-types-have-explicit-coercions) -for more details. - ## Using HTTP status helpers For non-200 HTTP responses, use the provided helpers in `lib/api/helpers.rb` to ensure correct behavior (`not_found!`, `no_content!` etc.). These will `throw` inside Grape and abort the execution of your endpoint. diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md index 1d03e93ab79..c9fd1b75606 100644 --- a/doc/development/ee_features.md +++ b/doc/development/ee_features.md @@ -513,12 +513,12 @@ do that, so we'll follow regular object-oriented practices that we define the interface first here. For example, suppose we have a few more optional parameters for EE. We can move the -parameters out of the `Grape::API::Instance` class to a helper module, so we can inject it +paramters out of the `Grape::API` class to a helper module, so we can inject it before it would be used in the class. ```ruby module API - class Projects < Grape::API::Instance + class Projects < Grape::API helpers Helpers::ProjectsHelpers end end @@ -579,7 +579,7 @@ class definition to make it easy and clear: ```ruby module API - class JobArtifacts < Grape::API::Instance + class JobArtifacts < Grape::API # EE::API::JobArtifacts would override the following helpers helpers do def authorize_download_artifacts! @@ -623,7 +623,7 @@ route. Something like this: ```ruby module API - class MergeRequests < Grape::API::Instance + class MergeRequests < Grape::API helpers do # EE::API::MergeRequests would override the following helpers def update_merge_request_ee(merge_request) @@ -692,7 +692,7 @@ least argument. We would approach this as follows: ```ruby # api/merge_requests/parameters.rb module API - class MergeRequests < Grape::API::Instance + class MergeRequests < Grape::API module Parameters def self.update_params_at_least_one_of %i[ @@ -708,7 +708,7 @@ API::MergeRequests::Parameters.prepend_if_ee('EE::API::MergeRequests::Parameters # api/merge_requests.rb module API - class MergeRequests < Grape::API::Instance + class MergeRequests < Grape::API params do at_least_one_of(*Parameters.update_params_at_least_one_of) end diff --git a/doc/development/integrations/secure.md b/doc/development/integrations/secure.md index 48e93b498c1..43ca212bdf5 100644 --- a/doc/development/integrations/secure.md +++ b/doc/development/integrations/secure.md @@ -53,7 +53,7 @@ so the [`allow_failure`](../../ci/yaml/README.md#allow_failure) parameter should ### Artifacts Scanning jobs must declare a report that corresponds to the type of scanning they perform, -using the [`artifacts:reports`](../../ci/yaml/README.md#artifactsreports) keyword. +using the [`artifacts:reports`](../../ci/pipelines/job_artifacts.md#artifactsreports) keyword. Valid reports are: `dependency_scanning`, `container_scanning`, `dast`, and `sast`. For example, here is the definition of a SAST job that generates a file named `gl-sast-report.json`, @@ -178,7 +178,7 @@ It is recommended to name the output file after the type of scanning, and to use Since all Secure reports are JSON files, it is recommended to use `.json` as a file extension. For instance, a suggested file name for a Dependency Scanning report is `gl-dependency-scanning.json`. -The [`artifacts:reports`](../../ci/yaml/README.md#artifactsreports) keyword +The [`artifacts:reports`](../../ci/pipelines/job_artifacts.md#artifactsreports) keyword of the job definition must be consistent with the file path where the Security report is written. For instance, if a Dependency Scanning analyzer writes its report to the CI project directory, and if this report file name is `depscan.json`, diff --git a/doc/development/integrations/secure_partner_integration.md b/doc/development/integrations/secure_partner_integration.md index d8badda4125..59336b0e6a1 100644 --- a/doc/development/integrations/secure_partner_integration.md +++ b/doc/development/integrations/secure_partner_integration.md @@ -68,7 +68,7 @@ and complete an intgration with the Secure stage. 1. Ensure your pipeline jobs create a report artifact that GitLab can process to successfully display your own product's results with the rest of GitLab. - See detailed [technical directions](secure.md) for this step. - - Read more about [job report artifacts](../../ci/yaml/README.md#artifactsreports). + - Read more about [job report artifacts](../../ci/pipelines/job_artifacts.md#artifactsreports). - Read about [job artifacts](../../user/project/pipelines/job_artifacts.md). - Your report artifact must be in one of our currently supported formats. For more information, see the [documentation on reports](secure.md#report). diff --git a/doc/development/logging.md b/doc/development/logging.md index ba2e879a04e..9c4d2ec0640 100644 --- a/doc/development/logging.md +++ b/doc/development/logging.md @@ -167,7 +167,8 @@ Resources: #### Logging durations Similar to timezones, choosing the right time unit to log can impose avoidable overhead. So, whenever -challenged to choose between seconds, milliseconds or any other unit, lean towards _seconds_ as float. +challenged to choose between seconds, milliseconds or any other unit, lean towards _seconds_ as float +(with microseconds precision, i.e. `Gitlab::InstrumentationHelper::DURATION_PRECISION`). In order to make it easier to track timings in the logs, make sure the log key has `_s` as suffix and `duration` within its name (e.g., `view_duration_s`). diff --git a/doc/subscriptions/index.md b/doc/subscriptions/index.md index 74985df41d0..3978506cbf9 100644 --- a/doc/subscriptions/index.md +++ b/doc/subscriptions/index.md @@ -182,6 +182,8 @@ Subscription charges are calculated based on the total number of users in a grou ## View your subscription +### View your GitLab.com subscription + To see the status of your GitLab.com subscription, log into GitLab.com and go to the **Billing** section of the relevant namespace: - For individuals: @@ -201,6 +203,13 @@ The following table describes details of your subscription for groups: | Subscription start date | Date your subscription started. If this is for a Free plan, is the date you transitioned off your group's paid plan. | | Subscription end date | Date your current subscription will end. Does not apply to Free plans. | +### View your self-managed subscription + +To view the status of your self-managed subscription, log into the self-managed instance and go to the **License** page. + + 1. Go to **{admin}** **Admin Area**. + 1. From the left-hand menu, select **License**. + ## Renew your subscription To renew your subscription, [prepare for renewal by reviewing your account](#prepare-for-renewal-by-reviewing-your-account), then do one of the following: diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index 735934fcaff..38423a230ab 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -43,18 +43,18 @@ it will continue to be used, whether or not Auto DevOps is enabled. ## Quick start -If you are using GitLab.com, see the [quick start guide](quick_start_guide.md) +If you're using GitLab.com, see the [quick start guide](quick_start_guide.md) for how to use Auto DevOps with GitLab.com and a Kubernetes cluster on Google Kubernetes Engine (GKE). -If you are using a self-managed instance of GitLab, you will need to configure the +If you're using a self-managed instance of GitLab, you will need to configure the [Google OAuth2 OmniAuth Provider](../../integration/google.md) before you can configure a cluster on GKE. Once this is set up, you can follow the steps on the [quick start guide](quick_start_guide.md) to get started. ## Comparison to application platforms and PaaS -Auto DevOps provides functionality that is often included in an application +Auto DevOps provides functionality that's often included in an application platform or a Platform as a Service (PaaS). It takes inspiration from the innovative work done by [Heroku](https://www.heroku.com/) and goes beyond it in multiple ways: @@ -120,15 +120,15 @@ To make full use of Auto DevOps, you will need: For Kubernetes 1.16+ clusters, there is some additional configuration for [Auto Deploy for Kubernetes 1.16+](stages.md#kubernetes-116). 1. NGINX Ingress. You can deploy it to your Kubernetes cluster by installing the [GitLab-managed app for Ingress](../../user/clusters/applications.md#ingress), - once you have configured GitLab's Kubernetes integration in the previous step. + once you've configured GitLab's Kubernetes integration in the previous step. Alternatively, you can use the [`nginx-ingress`](https://github.com/helm/charts/tree/master/stable/nginx-ingress) Helm chart to install Ingress manually. NOTE: **Note:** - If you are using your own Ingress instead of the one provided by GitLab's managed - apps, ensure you are running at least version 0.9.0 of NGINX Ingress and + If you're using your own Ingress instead of the one provided by GitLab's managed + apps, ensure you're running at least version 0.9.0 of NGINX Ingress and [enable Prometheus metrics](https://github.com/helm/charts/tree/master/stable/nginx-ingress#prometheus-metrics) in order for the response metrics to appear. You will also have to [annotate](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) @@ -150,25 +150,25 @@ To make full use of Auto DevOps, you will need: means using either the [Docker](https://docs.gitlab.com/runner/executors/docker.html) or [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes.html) executors, with [privileged mode enabled](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode). - The Runners do not need to be installed in the Kubernetes cluster, but the + The Runners don't need to be installed in the Kubernetes cluster, but the Kubernetes executor is easy to use and is automatically autoscaling. Docker-based Runners can be configured to autoscale as well, using [Docker Machine](https://docs.gitlab.com/runner/install/autoscaling.html). - If you have configured GitLab's Kubernetes integration in the first step, you + If you've configured GitLab's Kubernetes integration in the first step, you can deploy it to your cluster by installing the [GitLab-managed app for GitLab Runner](../../user/clusters/applications.md#gitlab-runner). Runners should be registered as [shared Runners](../../ci/runners/README.md#registering-a-shared-runner) for the entire GitLab instance, or [specific Runners](../../ci/runners/README.md#registering-a-specific-runner) - that are assigned to specific projects (the default if you have installed the + that are assigned to specific projects (the default if you've installed the GitLab Runner managed application). - **Prometheus** (for Auto Monitoring) To enable Auto Monitoring, you will need Prometheus installed somewhere (inside or outside your cluster) and configured to scrape your Kubernetes cluster. - If you have configured GitLab's Kubernetes integration, you can deploy it to + If you've configured GitLab's Kubernetes integration, you can deploy it to your cluster by installing the [GitLab-managed app for Prometheus](../../user/clusters/applications.md#prometheus). @@ -186,11 +186,11 @@ To make full use of Auto DevOps, you will need: a native Kubernetes certificate management controller that helps with issuing certificates. Installing cert-manager on your cluster will issue a certificate by [Let’s Encrypt](https://letsencrypt.org/) and ensure that certificates are valid and up-to-date. - If you have configured GitLab's Kubernetes integration, you can deploy it to + If you've configured GitLab's Kubernetes integration, you can deploy it to your cluster by installing the [GitLab-managed app for cert-manager](../../user/clusters/applications.md#cert-manager). -If you do not have Kubernetes or Prometheus installed, then Auto Review Apps, +If you don't have Kubernetes or Prometheus installed, then Auto Review Apps, Auto Deploy, and Auto Monitoring will be silently skipped. One all requirements are met, you can go ahead and [enable Auto DevOps](#enablingdisabling-auto-devops). @@ -212,54 +212,57 @@ as other environment [variables](../../ci/variables/README.md#priority-of-enviro TIP: **Tip:** If you're using the [GitLab managed app for Ingress](../../user/clusters/applications.md#ingress), -the URL endpoint should be automatically configured for you. All you have to do -is use its value for the `KUBE_INGRESS_BASE_DOMAIN` variable. +the URL endpoint should be automatically configured for you. +Use its value for the `KUBE_INGRESS_BASE_DOMAIN` variable. NOTE: **Note:** `AUTO_DEVOPS_DOMAIN` was [deprecated in GitLab 11.8](https://gitlab.com/gitlab-org/gitlab-foss/issues/52363) -and replaced with `KUBE_INGRESS_BASE_DOMAIN`. It was removed in +and replaced with `KUBE_INGRESS_BASE_DOMAIN`, and removed in [GitLab 12.0](https://gitlab.com/gitlab-org/gitlab-foss/issues/56959). -A wildcard DNS A record matching the base domain(s) is required, for example, -given a base domain of `example.com`, you'd need a DNS entry like: +Auto DevOps requires a wildcard DNS A record matching the base domain(s). For +a base domain of `example.com`, you'd need a DNS entry like: ```text *.example.com 3600 A 1.2.3.4 ``` -In this case, `example.com` is the domain name under which the deployed apps will be served, -and `1.2.3.4` is the IP address of your load balancer; generally NGINX -([see requirements](#requirements)). How to set up the DNS record is beyond -the scope of this document; you should check with your DNS provider. +In this case, the deployed applications are served from `example.com`, and `1.2.3.4` +is the IP address of your load balancer; generally NGINX ([see requirements](#requirements)). +Setting up the DNS record is beyond the scope of this document; check with your +DNS provider for information. -Alternatively you can use free public services like [nip.io](https://nip.io) -which provide automatic wildcard DNS without any configuration. Just set the -Auto DevOps base domain to `1.2.3.4.nip.io`. +Alternatively, you can use free public services like [nip.io](https://nip.io) +which provide automatic wildcard DNS without any configuration. For [nip.io](https://nip.io), +set the Auto DevOps base domain to `1.2.3.4.nip.io`. -Once set up, all requests will hit the load balancer, which in turn will route -them to the Kubernetes pods that run your application(s). +After completing setup, all requests hit the load balancer, which routes requests +to the Kubernetes pods running your application. ## Enabling/Disabling Auto DevOps -When first using Auto DevOps, review the [requirements](#requirements) to ensure all necessary components to make -full use of Auto DevOps are available. If this is your fist time, we recommend you follow the -[quick start guide](quick_start_guide.md). +When first using Auto DevOps, review the [requirements](#requirements) to ensure +all the necessary components to make full use of Auto DevOps are available. First-time +users should follow the [quick start guide](quick_start_guide.md). -GitLab.com users can enable/disable Auto DevOps at the project-level only. Self-managed users -can enable/disable Auto DevOps at the project-level, group-level or instance-level. +GitLab.com users can enable or disable Auto DevOps only at the project level. +Self-managed users can enable or disable Auto DevOps at the project, group, or +instance level. ### At the project level -If enabling, check that your project doesn't have a `.gitlab-ci.yml`, or if one exists, remove it. +If enabling, confirm your project does not have a `.gitlab-ci.yml`. If one +exists, remove it. -1. Go to your project's **Settings > CI/CD > Auto DevOps**. -1. Toggle the **Default to Auto DevOps pipeline** checkbox (checked to enable, unchecked to disable) -1. When enabling, it's optional but recommended to add in the [base domain](#auto-devops-base-domain) - that will be used by Auto DevOps to [deploy your application](stages.md#auto-deploy) +1. Go to your project's **{settings}** **Settings > CI/CD > Auto DevOps**. +1. Select the **Default to Auto DevOps pipeline** checkbox to enable it. +1. (Optional, but recommended) When enabling, you can add in the + [base domain](#auto-devops-base-domain) Auto DevOps uses to + [deploy your application](stages.md#auto-deploy), and choose the [deployment strategy](#deployment-strategy). 1. Click **Save changes** for the changes to take effect. -When the feature has been enabled, an Auto DevOps pipeline is triggered on the default branch. +After enabling the feature, an Auto DevOps pipeline is triggered on the default branch. ### At the group level @@ -267,48 +270,50 @@ When the feature has been enabled, an Auto DevOps pipeline is triggered on the d Only administrators and group owners can enable or disable Auto DevOps at the group level. -To enable or disable Auto DevOps at the group-level: +When enabling or disabling Auto DevOps at group level, group configuration is +implicitly used for the subgroups and projects inside that group, unless Auto DevOps +is specifically enabled or disabled on the subgroup or project. -1. Go to group's **Settings > CI/CD > Auto DevOps** page. -1. Toggle the **Default to Auto DevOps pipeline** checkbox (checked to enable, unchecked to disable). -1. Click **Save changes** button for the changes to take effect. +To enable or disable Auto DevOps at the group level: -When enabling or disabling Auto DevOps at group-level, group configuration will be implicitly used for -the subgroups and projects inside that group, unless Auto DevOps is specifically enabled or disabled on -the subgroup or project. +1. Go to your group's **{settings}** **Settings > CI/CD > Auto DevOps** page. +1. Select the **Default to Auto DevOps pipeline** checkbox to enable it. +1. Click **Save changes** for the changes to take effect. ### At the instance level (Administrators only) Even when disabled at the instance level, group owners and project maintainers can still enable Auto DevOps at the group and project level, respectively. -1. Go to **Admin Area > Settings > Continuous Integration and Deployment**. -1. Toggle the checkbox labeled **Default to Auto DevOps pipeline for all projects**. -1. If enabling, optionally set up the Auto DevOps [base domain](#auto-devops-base-domain) which will be used for Auto Deploy and Auto Review Apps. +1. Go to **{admin}** **Admin Area > Settings > Continuous Integration and Deployment**. +1. Select **Default to Auto DevOps pipeline for all projects** to enable it. +1. (Optional) You can set up the Auto DevOps [base domain](#auto-devops-base-domain), + for Auto Deploy and Auto Review Apps to use. 1. Click **Save changes** for the changes to take effect. ### Enable for a percentage of projects -There is also a feature flag to enable Auto DevOps by default to your chosen percentage of projects. - -This can be enabled from the console with the following, which uses the example of 10%: +You can use a feature flag to enable Auto DevOps by default to your desired percentage +of projects. From the console, enter the following command, replacing `10` with +your desired percentage: -`Feature.get(:force_autodevops_on_by_default).enable_percentage_of_actors(10)` +```ruby +Feature.get(:force_autodevops_on_by_default).enable_percentage_of_actors(10) +``` ### Deployment strategy > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/38542) in GitLab 11.0. You can change the deployment strategy used by Auto DevOps by going to your -project's **Settings > CI/CD > Auto DevOps**. - -The available options are: +project's **{settings}** **Settings > CI/CD > Auto DevOps**. The following options +are available: - **Continuous deployment to production**: Enables [Auto Deploy](stages.md#auto-deploy) with `master` branch directly deployed to production. - **Continuous deployment to production using timed incremental rollout**: Sets the [`INCREMENTAL_ROLLOUT_MODE`](customize.md#timed-incremental-rollout-to-production-premium) variable - to `timed`, and production deployment will be executed with a 5 minute delay between + to `timed`. Production deployments execute with a 5 minute delay between each increment in rollout. - **Automatic deployment to staging, manual deployment to production**: Sets the [`STAGING_ENABLED`](customize.md#deploy-policy-for-staging-and-production-environments) and @@ -320,63 +325,60 @@ The available options are: ## Using multiple Kubernetes clusters **(PREMIUM)** -When using Auto DevOps, you may want to deploy different environments to -different Kubernetes clusters. This is possible due to the 1:1 connection that -[exists between them](../../user/project/clusters/index.md#multiple-kubernetes-clusters-premium). +When using Auto DevOps, you can deploy different environments to +different Kubernetes clusters, due to the 1:1 connection +[existing between them](../../user/project/clusters/index.md#multiple-kubernetes-clusters-premium). -In the [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) (used behind the scenes by Auto DevOps), there -are currently 3 defined environment names that you need to know: +The [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) currently defines 3 environment names: - `review/` (every environment starting with `review/`) - `staging` - `production` -Those environments are tied to jobs that use [Auto Deploy](stages.md#auto-deploy), so -except for the environment scope, they would also need to have a different -domain they would be deployed to. This is why you need to define a separate -`KUBE_INGRESS_BASE_DOMAIN` variable for all the above +Those environments are tied to jobs using [Auto Deploy](stages.md#auto-deploy), so +except for the environment scope, they must have a different deployment domain. +You must define a separate `KUBE_INGRESS_BASE_DOMAIN` variable for each of the above [based on the environment](../../ci/variables/README.md#limiting-environment-scopes-of-environment-variables). -The following table is an example of how the three different clusters would -be configured. +The following table is an example of how to configure the three different clusters: | Cluster name | Cluster environment scope | `KUBE_INGRESS_BASE_DOMAIN` variable value | Variable environment scope | Notes | |--------------|---------------------------|-------------------------------------------|----------------------------|---| -| review | `review/*` | `review.example.com` | `review/*` | The review cluster which will run all [Review Apps](../../ci/review_apps/index.md). `*` is a wildcard, which means it will be used by every environment name starting with `review/`. | -| staging | `staging` | `staging.example.com` | `staging` | (Optional) The staging cluster which will run the deployments of the staging environments. You need to [enable it first](customize.md#deploy-policy-for-staging-and-production-environments). | -| production | `production` | `example.com` | `production` | The production cluster which will run the deployments of the production environment. You can use [incremental rollouts](customize.md#incremental-rollout-to-production-premium). | +| review | `review/*` | `review.example.com` | `review/*` | The review cluster which runs all [Review Apps](../../ci/review_apps/index.md). `*` is a wildcard, used by every environment name starting with `review/`. | +| staging | `staging` | `staging.example.com` | `staging` | (Optional) The staging cluster which runs the deployments of the staging environments. You must [enable it first](customize.md#deploy-policy-for-staging-and-production-environments). | +| production | `production` | `example.com` | `production` | The production cluster which runs the production environment deployments. You can use [incremental rollouts](customize.md#incremental-rollout-to-production-premium). | To add a different cluster for each environment: -1. Navigate to your project's **Operations > Kubernetes** and create the Kubernetes clusters - with their respective environment scope as described from the table above. +1. Navigate to your project's **{cloud-gear}** **Operations > Kubernetes**. +1. Create the Kubernetes clusters with their respective environment scope, as + described from the table above.  -1. After the clusters are created, navigate to each one and install Helm Tiller +1. After creating the clusters, navigate to each cluster and install Helm Tiller and Ingress. Wait for the Ingress IP address to be assigned. -1. Make sure you have [configured your DNS](#auto-devops-base-domain) with the +1. Make sure your [DNS is configured](#auto-devops-base-domain) with the specified Auto DevOps domains. -1. Navigate to each cluster's page, through **Operations > Kubernetes**, +1. Navigate to each cluster's page, through **{cloud-gear}** **Operations > Kubernetes**, and add the domain based on its Ingress IP address. -Now that all is configured, you can test your setup by creating a merge request -and verifying that your app is deployed as a review app in the Kubernetes +After completing configuration, you can test your setup by creating a merge request +and verifying your app is deployed as a review app in the Kubernetes cluster with the `review/*` environment scope. Similarly, you can check the other environments. ## Currently supported languages -Note that not all buildpacks support Auto Test yet, as it's a relatively new -enhancement. All of Heroku's [officially supported -languages](https://devcenter.heroku.com/articles/heroku-ci#currently-supported-languages) -support it, and some third-party buildpacks as well e.g., Go, Node, Java, PHP, -Python, Ruby, Gradle, Scala, and Elixir all support Auto Test, but notably the -multi-buildpack does not. +Note that not all buildpacks support Auto Test yet, as it's a relatively new enhancement. +All of Heroku's [officially supported languages](https://devcenter.heroku.com/articles/heroku-ci#currently-supported-languages) +support Auto Test. While some third-party buildpacks, such as Go, Node, Java, PHP, +Python, Ruby, Gradle, Scala, and Elixir all support Auto Test, the +multi-buildpack notably does not. As of GitLab 10.0, the supported buildpacks are: -```text +```plaintext - heroku-buildpack-multi v1.0.0 - heroku-buildpack-ruby v168 - heroku-buildpack-nodejs v99 @@ -398,18 +400,18 @@ The following restrictions apply. ### Private registry support -There is no documented way of using private container registry with Auto DevOps. -We strongly advise using GitLab Container Registry with Auto DevOps in order to +No documented way of using private container registry with Auto DevOps exists. +We strongly advise using GitLab Container Registry with Auto DevOps to simplify configuration and prevent any unforeseen issues. ### Installing Helm behind a proxy -GitLab does not yet support installing [Helm as a GitLab-managed App](../../user/clusters/applications.md#helm) when -behind a proxy. Users who wish to do so must inject their proxy settings -into the installation pods at runtime, for example by using a +GitLab does not support installing [Helm as a GitLab-managed App](../../user/clusters/applications.md#helm) when +behind a proxy. Users who want to do so must inject their proxy settings +into the installation pods at runtime, such as by using a [`PodPreset`](https://kubernetes.io/docs/concepts/workloads/pods/podpreset/): -```yml +```yaml apiVersion: settings.k8s.io/v1alpha1 kind: PodPreset metadata: @@ -439,12 +441,12 @@ spec: - Your application may be missing the key files the buildpack is looking for. For example, for Ruby applications you must have a `Gemfile` to be properly detected, - even though it is possible to write a Ruby app without a `Gemfile`. + even though it's possible to write a Ruby app without a `Gemfile`. - There may be no buildpack for your application. Try specifying a [custom buildpack](customize.md#custom-buildpacks). - Auto Test may fail because of a mismatch between testing frameworks. In this case, you may need to customize your `.gitlab-ci.yml` with your test commands. -- Auto Deploy will fail if GitLab can not create a Kubernetes namespace and +- Auto Deploy will fail if GitLab can't create a Kubernetes namespace and service account for your project. For help debugging this issue, see [Troubleshooting failed deployment jobs](../../user/project/clusters/index.md#troubleshooting). diff --git a/doc/topics/autodevops/stages.md b/doc/topics/autodevops/stages.md index d3bc937ea4a..90b977c52e9 100644 --- a/doc/topics/autodevops/stages.md +++ b/doc/topics/autodevops/stages.md @@ -152,10 +152,9 @@ documentation. > Introduced in GitLab 10.4. -Vulnerability Static Analysis for containers runs static analysis on a Docker -images with [Clair](https://github.com/quay/clair) to check for potential security -issues. The Auto Container Scanning stage is skipped on licenses other than -[Ultimate](https://about.gitlab.com/pricing/). +Vulnerability Static Analysis for containers uses [Clair](https://github.com/quay/clair) +to check for potential security issues on Docker images. The Auto Container Scanning +stage is skipped on licenses other than [Ultimate](https://about.gitlab.com/pricing/). After creating the report, it's uploaded as an artifact which you can later download and check out. The merge request displays any detected security issues. @@ -175,7 +174,7 @@ branch's code so developers, designers, QA, product managers, and other reviewers can actually see and interact with code changes as part of the review process. Auto Review Apps create a Review App for each branch. -Auto Review Apps deploy your app to your Kubernetes cluster only. If no cluster +Auto Review Apps deploy your application to your Kubernetes cluster only. If no cluster is available, no deployment occurs. The Review App has a unique URL based on a combination of the project ID, the branch @@ -186,7 +185,7 @@ such as after merging a merge request, the Review App is also deleted. Review apps are deployed using the [auto-deploy-app](https://gitlab.com/gitlab-org/charts/auto-deploy-app) chart with -Helm, which you can [customize](customize.md#custom-helm-chart). The app deploys +Helm, which you can [customize](customize.md#custom-helm-chart). The application deploys into the [Kubernetes namespace](../../user/project/clusters/index.md#deployment-variables) for the environment. @@ -210,7 +209,7 @@ Dynamic Application Security Testing (DAST) uses the popular open source tool and check for potential security issues. The Auto DAST stage is skipped on licenses other than [Ultimate](https://about.gitlab.com/pricing/). -- On your default branch, DAST scans an app deployed specifically for that purpose +- On your default branch, DAST scans an application deployed specifically for that purpose unless you [override the target branch](#overriding-the-dast-target). The app is deleted after DAST has run. - On feature branches, DAST scans the [review app](#auto-review-apps). @@ -252,7 +251,7 @@ Auto Browser Performance Testing measures the performance of a web page with the creates a JSON report including the overall performance score for each page, and uploads the report as an artifact. By default, it tests the root page of your Review and Production environments. If you want to test additional URLs, add the paths to a -file named `.gitlab-urls.txt` in the root directory, one file per line: +file named `.gitlab-urls.txt` in the root directory, one file per line. For example: ```plaintext / @@ -283,8 +282,8 @@ scale your pod replicas, and to apply custom arguments to the Auto DevOps `helm commands. This is an easy way to [customize the Auto Deploy Helm chart](customize.md#custom-helm-chart). -The [auto-deploy-app](https://gitlab.com/gitlab-org/charts/auto-deploy-app) chart with -Helm deploys the application into the +Helm uses the [auto-deploy-app](https://gitlab.com/gitlab-org/charts/auto-deploy-app) +chart to deploy the application into the [Kubernetes namespace](../../user/project/clusters/index.md#deployment-variables) for the environment. @@ -411,7 +410,7 @@ After configuring your worker to respond to health checks, run a Sidekiq worker for your Rails application. You can enable workers by setting the following in the [`.gitlab/auto-deploy-values.yaml` file](customize.md#customize-values-for-helm-chart): -```yml +```yaml workers: sidekiq: replicaCount: 1 @@ -435,7 +434,7 @@ workers: By default, all Kubernetes pods are [non-isolated](https://kubernetes.io/docs/concepts/services-networking/network-policies/#isolated-and-non-isolated-pods), -meaning that they will accept traffic to and from any source. You can use +and accept traffic to and from any source. You can use [NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/) to restrict connections to and from selected pods, namespaces, and the Internet. @@ -455,13 +454,13 @@ networkPolicy: enabled: true ``` -The default policy deployed by the auto deploy pipeline will allow -traffic within a local namespace and from the `gitlab-managed-apps` -namespace. All other inbound connection will be blocked. Outbound +The default policy deployed by the Auto Deploy pipeline allows +traffic within a local namespace, and from the `gitlab-managed-apps` +namespace. All other inbound connections are blocked. Outbound traffic (for example, to the Internet) is not affected by the default policy. You can also provide a custom [policy specification](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#networkpolicyspec-v1-networking-k8s-io) -via the `.gitlab/auto-deploy-values.yaml` file, for example: +in the `.gitlab/auto-deploy-values.yaml` file, for example: ```yaml networkPolicy: @@ -479,16 +478,19 @@ networkPolicy: app.gitlab.com/managed_by: gitlab ``` -For more information on how to install Network Policies, see +For more information on installing Network Policies, see [Install Cilium using GitLab CI/CD](../../user/clusters/applications.md#install-cilium-using-gitlab-cicd). ### Web Application Firewall (ModSecurity) customization > [Introduced](https://gitlab.com/gitlab-org/charts/auto-deploy-app/-/merge_requests/44) in GitLab 12.8. -Customization on an [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) or on a deployment base is available for clusters with [ModSecurity installed](../../user/clusters/applications.md#web-application-firewall-modsecurity). +Customization on an [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) +or on a deployment base is available for clusters with +[ModSecurity installed](../../user/clusters/applications.md#web-application-firewall-modsecurity). -To enable ModSecurity with Auto Deploy, you need to create a `.gitlab/auto-deploy-values.yaml` file in your project with the following attributes. +To enable ModSecurity with Auto Deploy, you must create a `.gitlab/auto-deploy-values.yaml` +file in your project with the following attributes. |Attribute | Description | Default | -----------|-------------|---------| @@ -499,7 +501,7 @@ To enable ModSecurity with Auto Deploy, you need to create a `.gitlab/auto-deplo In the following `auto-deploy-values.yaml` example, some custom settings are enabled for ModSecurity. Those include setting its engine to process rules instead of only logging them, while adding two specific -rules which are header-based: +header-based rules: ```yaml ingress: @@ -525,7 +527,7 @@ may require commands to be wrapped as follows: /bin/herokuish procfile exec $COMMAND ``` -This might be necessary, for example, when: +Some of the reasons you may need to wrap commands: - Attaching using `kubectl exec`. - Using GitLab's [Web Terminal](../../ci/environments.md#web-terminals). @@ -538,12 +540,12 @@ For example, to start a Rails console from the application root directory, run: ## Auto Monitoring -Once your application is deployed, Auto Monitoring makes it possible to monitor +After your application deploys, Auto Monitoring helps you monitor your application's server and response metrics right out of the box. Auto Monitoring uses [Prometheus](../../user/project/integrations/prometheus.md) to -get system metrics such as CPU and memory usage directly from +retrieve system metrics, such as CPU and memory usage, directly from [Kubernetes](../../user/project/integrations/prometheus_library/kubernetes.md), -and response metrics such as HTTP error rates, latency, and throughput from the +and response metrics, such as HTTP error rates, latency, and throughput, from the [NGINX server](../../user/project/integrations/prometheus_library/nginx_ingress.md). The metrics include: @@ -556,14 +558,14 @@ GitLab provides some initial alerts for you after you install Prometheus: - Ingress status code `500` > 0.1% - NGINX status code `500` > 0.1% -To make use of Auto Monitoring: +To use Auto Monitoring: 1. [Install and configure the requirements](index.md#requirements). -1. [Enable Auto DevOps](index.md#enablingdisabling-auto-devops) if you haven't done already. -1. Finally, go to your project's **CI/CD > Pipelines** and run a pipeline. -1. Once the pipeline finishes successfully, open the +1. [Enable Auto DevOps](index.md#enablingdisabling-auto-devops), if you haven't done already. +1. Navigate to your project's **{rocket}** **CI/CD > Pipelines** and click **Run pipeline**. +1. After the pipeline finishes successfully, open the [monitoring dashboard for a deployed environment](../../ci/environments.md#monitoring-environments) to view the metrics of your deployed application. To view the metrics of the - whole Kubernetes cluster, navigate to **Operations > Metrics**. + whole Kubernetes cluster, navigate to **{cloud-gear}** **Operations > Metrics**.  diff --git a/doc/user/admin_area/settings/usage_statistics.md b/doc/user/admin_area/settings/usage_statistics.md index 4bd49335177..1f01a364514 100644 --- a/doc/user/admin_area/settings/usage_statistics.md +++ b/doc/user/admin_area/settings/usage_statistics.md @@ -185,6 +185,7 @@ but commented out to help encourage others to add to it in the future. --> |auto_devops_disabled|counts|| |deploy_keys|counts|| |deployments|counts|| +|dast_jobs|counts|| |successful_deployments|counts|| |failed_deployments|counts|| |environments|counts|| diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md index c4959248f94..3eb7467b410 100644 --- a/doc/user/application_security/container_scanning/index.md +++ b/doc/user/application_security/container_scanning/index.md @@ -103,7 +103,7 @@ The included template will: and scan it for possible vulnerabilities. The results will be saved as a -[Container Scanning report artifact](../../../ci/yaml/README.md#artifactsreportscontainer_scanning-ultimate) +[Container Scanning report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportscontainer_scanning-ultimate) that you can later download and analyze. Due to implementation limitations, we always take the latest Container Scanning artifact available. Behind the scenes, the diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md index 804e1b9d1b8..739613134f9 100644 --- a/doc/user/application_security/dast/index.md +++ b/doc/user/application_security/dast/index.md @@ -101,7 +101,7 @@ The included template will create a `dast` job in your CI/CD pipeline and scan your project's source code for possible vulnerabilities. The results will be saved as a -[DAST report artifact](../../../ci/yaml/README.md#artifactsreportsdast-ultimate) +[DAST report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsdast-ultimate) that you can later download and analyze. Due to implementation limitations we always take the latest DAST artifact available. Behind the scenes, the [GitLab DAST Docker image](https://gitlab.com/gitlab-org/security-products/dast) @@ -147,7 +147,7 @@ variables: ``` The results will be saved as a -[DAST report artifact](../../../ci/yaml/README.md#artifactsreportsdast-ultimate) +[DAST report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsdast-ultimate) that you can later download and analyze. Due to implementation limitations, we always take the latest DAST artifact available. diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md index ad13fe0c6b4..0bd444f55c6 100644 --- a/doc/user/application_security/dependency_scanning/index.md +++ b/doc/user/application_security/dependency_scanning/index.md @@ -91,7 +91,7 @@ The included template will create a `dependency_scanning` job in your CI/CD pipeline and scan your project's source code for possible vulnerabilities. The results will be saved as a -[Dependency Scanning report artifact](../../../ci/yaml/README.md#artifactsreportsdependency_scanning-ultimate) +[Dependency Scanning report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsdependency_scanning-ultimate) that you can later download and analyze. Due to implementation limitations, we always take the latest Dependency Scanning artifact available. diff --git a/doc/user/application_security/sast/index.md b/doc/user/application_security/sast/index.md index 31acfbd5dba..270b1cc5eeb 100644 --- a/doc/user/application_security/sast/index.md +++ b/doc/user/application_security/sast/index.md @@ -118,7 +118,7 @@ The included template will create a `sast` job in your CI/CD pipeline and scan your project's source code for possible vulnerabilities. The results will be saved as a -[SAST report artifact](../../../ci/yaml/README.md#artifactsreportssast-ultimate) +[SAST report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportssast-ultimate) that you can later download and analyze. Due to implementation limitations, we always take the latest SAST artifact available. Behind the scenes, the [GitLab SAST Docker image](https://gitlab.com/gitlab-org/security-products/sast) diff --git a/doc/user/application_security/security_dashboard/index.md b/doc/user/application_security/security_dashboard/index.md index 55701bb8476..59aeba9d655 100644 --- a/doc/user/application_security/security_dashboard/index.md +++ b/doc/user/application_security/security_dashboard/index.md @@ -30,7 +30,7 @@ To use the instance, group, project, or pipeline security dashboard: 1. At least one project inside a group must be configured with at least one of the [supported reports](#supported-reports). -1. The configured jobs must use the [new `reports` syntax](../../../ci/yaml/README.md#artifactsreports). +1. The configured jobs must use the [new `reports` syntax](../../../ci/pipelines/job_artifacts.md#artifactsreports). 1. [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 or newer must be used. If you're using the shared Runners on GitLab.com, this is already the case. diff --git a/doc/user/compliance/license_compliance/index.md b/doc/user/compliance/license_compliance/index.md index 22b0dfb2293..9002fdf8229 100644 --- a/doc/user/compliance/license_compliance/index.md +++ b/doc/user/compliance/license_compliance/index.md @@ -112,7 +112,7 @@ so you're advised to migrate to the `license_scanning` job and used the new `License-Scanning.gitlab-ci.yml` template. The results will be saved as a -[License Compliance report artifact](../../../ci/yaml/README.md#artifactsreportslicense_scanning-ultimate) +[License Compliance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportslicense_scanning-ultimate) that you can later download and analyze. Due to implementation limitations, we always take the latest License Compliance artifact available. Behind the scenes, the [GitLab License Compliance Docker image](https://gitlab.com/gitlab-org/security-products/license-management) diff --git a/doc/user/project/merge_requests/browser_performance_testing.md b/doc/user/project/merge_requests/browser_performance_testing.md index 1bca5d2a212..3dd87fcc8f5 100644 --- a/doc/user/project/merge_requests/browser_performance_testing.md +++ b/doc/user/project/merge_requests/browser_performance_testing.md @@ -42,7 +42,7 @@ For instance, consider the following workflow: ## How it works First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the -[Performance report artifact](../../../ci/yaml/README.md#artifactsreportsperformance-premium). +[Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsperformance-premium). For more information on how the Performance job should look like, check the example on [Configuring Browser Performance Testing](#configuring-browser-performance-testing). @@ -100,7 +100,7 @@ It also requires GitLab Runner 11.5 or later. For earlier versions, use the The above example will create a `performance` job in your CI/CD pipeline and will run sitespeed.io against the webpage you defined in `URL` to gather key metrics. The [GitLab plugin for sitespeed.io](https://gitlab.com/gitlab-org/gl-performance) -is downloaded in order to save the report as a [Performance report artifact](../../../ci/yaml/README.md#artifactsreportsperformance-premium) +is downloaded in order to save the report as a [Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsperformance-premium) that you can later download and analyze. Due to implementation limitations we always take the latest Performance artifact available. diff --git a/doc/user/project/merge_requests/code_quality.md b/doc/user/project/merge_requests/code_quality.md index 40e137459c1..4b3bfac6e76 100644 --- a/doc/user/project/merge_requests/code_quality.md +++ b/doc/user/project/merge_requests/code_quality.md @@ -79,7 +79,7 @@ include: The above example will create a `code_quality` job in your CI/CD pipeline which will scan your source code for code quality issues. The report will be saved as a -[Code Quality report artifact](../../../ci/yaml/README.md#artifactsreportscodequality-starter) +[Code Quality report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportscodequality-starter) that you can later download and analyze. Due to implementation limitations we always take the latest Code Quality artifact available. @@ -239,7 +239,7 @@ do this: 1. Define a job in your `.gitlab-ci.yml` file that generates the [Code Quality report - artifact](../../../ci/yaml/README.md#artifactsreportscodequality-starter). + artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportscodequality-starter). 1. Configure your tool to generate the Code Quality report artifact as a JSON file that implements subset of the [Code Climate spec](https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md#data-types). diff --git a/doc/user/project/merge_requests/test_coverage_visualization.md b/doc/user/project/merge_requests/test_coverage_visualization.md index 71fbdaf112f..84d60fca72d 100644 --- a/doc/user/project/merge_requests/test_coverage_visualization.md +++ b/doc/user/project/merge_requests/test_coverage_visualization.md @@ -17,14 +17,14 @@ MR is merged. ## How test coverage visualization works Collecting the coverage information is done via GitLab CI/CD's -[artifacts reports feature](../../../ci/yaml/README.md#artifactsreports). +[artifacts reports feature](../../../ci/pipelines/job_artifacts.md#artifactsreports). You can specify one or more coverage reports to collect, including wildcard paths. GitLab will then take the coverage information in all the files and combine it together. For the coverage analysis to work, you have to provide a properly formatted [Cobertura XML](https://cobertura.github.io/cobertura/) report to -[`artifacts:reports:cobertura`](../../../ci/yaml/README.md#artifactsreportscobertura). +[`artifacts:reports:cobertura`](../../../ci/pipelines/job_artifacts.md#artifactsreportscobertura). This format was originally developed for Java, but most coverage analysis frameworks for other languages have plugins to add support for it, like: |