Skip to content

G
gitlab-ce
Commit 0d978174 authored by Marcel Amirault's avatar Marcel Amirault Committed by Achilleas Pipinellis
Browse files
Options

Rename ci yaml readme to index

parent 9b6b7c28
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 5230 additions and 5222 deletions
app/views/projects/pipelines/_with_tabs.html.haml
View file @ 0d978174
...@@ -78,7 +78,7 @@ ...@@ -78,7 +78,7 @@
= build_summary(build) = build_summary(build)
#js-tab-dag.tab-pane #js-tab-dag.tab-pane
#js-pipeline-dag-vue{ data: { pipeline_project_path: @project.full_path, pipeline_iid: @pipeline.iid, empty_svg_path: image_path('illustrations/empty-state/empty-dag-md.svg'), about_dag_doc_path: help_page_path('ci/directed_acyclic_graph/index.md'), dag_doc_path: help_page_path('ci/yaml/README.md', anchor: 'needs')} } #js-pipeline-dag-vue{ data: { pipeline_project_path: @project.full_path, pipeline_iid: @pipeline.iid, empty_svg_path: image_path('illustrations/empty-state/empty-dag-md.svg'), about_dag_doc_path: help_page_path('ci/directed_acyclic_graph/index.md'), dag_doc_path: help_page_path('ci/yaml/index.md', anchor: 'needs')} }
#js-tab-tests.tab-pane #js-tab-tests.tab-pane
#js-pipeline-tests-detail{ data: { summary_endpoint: summary_project_pipeline_tests_path(@project, @pipeline, format: :json), #js-pipeline-tests-detail{ data: { summary_endpoint: summary_project_pipeline_tests_path(@project, @pipeline, format: :json),
......
doc/administration/instance_limits.md
View file @ 0d978174
...@@ -192,7 +192,7 @@ The number of pipelines that can be created in a single push is 4. ...@@ -192,7 +192,7 @@ The number of pipelines that can be created in a single push is 4.
This is to prevent the accidental creation of pipelines when `git push --all` This is to prevent the accidental creation of pipelines when `git push --all`
or `git push --mirror` is used. or `git push --mirror` is used.
Read more in the [CI documentation](../ci/yaml/README.md#processing-git-pushes). Read more in the [CI documentation](../ci/yaml/index.md#processing-git-pushes).
## Retention of activity history ## Retention of activity history
...@@ -407,7 +407,7 @@ Plan.default.actual_limits.update!(ci_instance_level_variables: 30) ...@@ -407,7 +407,7 @@ Plan.default.actual_limits.update!(ci_instance_level_variables: 30)
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37226) in GitLab 13.3. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37226) in GitLab 13.3.
Job artifacts defined with [`artifacts:reports`](../ci/yaml/README.md#artifactsreports) Job artifacts defined with [`artifacts:reports`](../ci/yaml/index.md#artifactsreports)
that are uploaded by the runner are rejected if the file size exceeds the maximum that are uploaded by the runner are rejected if the file size exceeds the maximum
file size limit. The limit is determined by comparing the project's file size limit. The limit is determined by comparing the project's
[maximum artifact size setting](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size) [maximum artifact size setting](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size)
...@@ -576,7 +576,7 @@ prevent any more changes from rendering. For more information about these limits ...@@ -576,7 +576,7 @@ prevent any more changes from rendering. For more information about these limits
Reports that go over the 20 MB limit won't be loaded. Affected reports: Reports that go over the 20 MB limit won't be loaded. Affected reports:
- [Merge request security reports](../user/project/merge_requests/testing_and_reports_in_merge_requests.md#security-reports) - [Merge request security reports](../user/project/merge_requests/testing_and_reports_in_merge_requests.md#security-reports)
- [CI/CD parameter `artifacts:expose_as`](../ci/yaml/README.md#artifactsexpose_as) - [CI/CD parameter `artifacts:expose_as`](../ci/yaml/index.md#artifactsexpose_as)
- [Unit test reports](../ci/unit_test_reports.md) - [Unit test reports](../ci/unit_test_reports.md)
## Advanced Search limits ## Advanced Search limits
......
doc/administration/job_artifacts.md
View file @ 0d978174
...@@ -42,10 +42,10 @@ To disable artifacts site-wide, follow the steps below. ...@@ -42,10 +42,10 @@ To disable artifacts site-wide, follow the steps below.
GitLab Runner can upload an archive containing the job artifacts to GitLab. By default, GitLab Runner can upload an archive containing the job artifacts to GitLab. By default,
this is done when the job succeeds, but can also be done on failure, or always, via the this is done when the job succeeds, but can also be done on failure, or always, via the
[`artifacts:when`](../ci/yaml/README.md#artifactswhen) parameter. [`artifacts:when`](../ci/yaml/index.md#artifactswhen) parameter.
Most artifacts are compressed by GitLab Runner before being sent to the coordinator. The exception to this is Most artifacts are compressed by GitLab Runner before being sent to the coordinator. The exception to this is
[reports artifacts](../ci/yaml/README.md#artifactsreports), which are compressed after uploading. [reports artifacts](../ci/yaml/index.md#artifactsreports), which are compressed after uploading.
### Using local storage ### Using local storage
...@@ -326,7 +326,7 @@ To migrate back to local storage: ...@@ -326,7 +326,7 @@ To migrate back to local storage:
## Expiring artifacts ## Expiring artifacts
If [`artifacts:expire_in`](../ci/yaml/README.md#artifactsexpire_in) is used to set If [`artifacts:expire_in`](../ci/yaml/index.md#artifactsexpire_in) is used to set
an expiry for the artifacts, they are marked for deletion right after that date passes. an expiry for the artifacts, they are marked for deletion right after that date passes.
Otherwise, they expire per the [default artifacts expiration setting](../user/admin_area/settings/continuous_integration.md). Otherwise, they expire per the [default artifacts expiration setting](../user/admin_area/settings/continuous_integration.md).
......
doc/api/commits.md
View file @ 0d978174
...@@ -638,8 +638,8 @@ GET /projects/:id/repository/commits/:sha/statuses ...@@ -638,8 +638,8 @@ GET /projects/:id/repository/commits/:sha/statuses
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](index.md#namespaced-path-encoding) owned by the authenticated user | `id` | integer/string | yes | The ID or [URL-encoded path of the project](index.md#namespaced-path-encoding) owned by the authenticated user
| `sha` | string | yes | The commit SHA | `sha` | string | yes | The commit SHA
| `ref` | string | no | The name of a repository branch or tag or, if not given, the default branch | `ref` | string | no | The name of a repository branch or tag or, if not given, the default branch
| `stage` | string | no | Filter by [build stage](../ci/yaml/README.md#stages), e.g., `test` | `stage` | string | no | Filter by [build stage](../ci/yaml/index.md#stages), e.g., `test`
| `name` | string | no | Filter by [job name](../ci/yaml/README.md#job-keywords), e.g., `bundler:audit` | `name` | string | no | Filter by [job name](../ci/yaml/index.md#job-keywords), e.g., `bundler:audit`
| `all` | boolean | no | Return all statuses, not only the latest ones | `all` | boolean | no | Return all statuses, not only the latest ones
```shell ```shell
......
doc/api/job_artifacts.md
View file @ 0d978174
...@@ -28,7 +28,7 @@ Example request using the `PRIVATE-TOKEN` header: ...@@ -28,7 +28,7 @@ Example request using the `PRIVATE-TOKEN` header:
curl --output artifacts.zip --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/42/artifacts" curl --output artifacts.zip --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/42/artifacts"
``` ```
To use this in a [`script` definition](../ci/yaml/README.md#script) inside To use this in a [`script` definition](../ci/yaml/index.md#script) inside
`.gitlab-ci.yml` **(PREMIUM)**, you can use either: `.gitlab-ci.yml` **(PREMIUM)**, you can use either:
- The `JOB-TOKEN` header with the GitLab-provided `CI_JOB_TOKEN` variable. - The `JOB-TOKEN` header with the GitLab-provided `CI_JOB_TOKEN` variable.
...@@ -93,7 +93,7 @@ Example request using the `PRIVATE-TOKEN` header: ...@@ -93,7 +93,7 @@ Example request using the `PRIVATE-TOKEN` header:
curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/main/download?job=test" curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/main/download?job=test"
``` ```
To use this in a [`script` definition](../ci/yaml/README.md#script) inside To use this in a [`script` definition](../ci/yaml/index.md#script) inside
`.gitlab-ci.yml` **(PREMIUM)**, you can use either: `.gitlab-ci.yml` **(PREMIUM)**, you can use either:
- The `JOB-TOKEN` header with the GitLab-provided `CI_JOB_TOKEN` variable. - The `JOB-TOKEN` header with the GitLab-provided `CI_JOB_TOKEN` variable.
......
doc/api/lint.md
View file @ 0d978174
...@@ -87,8 +87,8 @@ Example responses: ...@@ -87,8 +87,8 @@ Example responses:
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29568) in GitLab 13.5. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29568) in GitLab 13.5.
The CI lint returns an expanded version of the configuration. The expansion does not The CI lint returns an expanded version of the configuration. The expansion does not
work for CI configuration added with [`include: local`](../ci/yaml/README.md#includelocal), work for CI configuration added with [`include: local`](../ci/yaml/index.md#includelocal),
or with [`extends:`](../ci/yaml/README.md#extends). or with [`extends:`](../ci/yaml/index.md#extends).
Example contents of a `.gitlab-ci.yml` passed to the CI Lint API with Example contents of a `.gitlab-ci.yml` passed to the CI Lint API with
`include_merged_yaml` set as true: `include_merged_yaml` set as true:
......
doc/api/templates/gitlab_ci_ymls.md
View file @ 0d978174
...@@ -9,7 +9,7 @@ type: reference ...@@ -9,7 +9,7 @@ type: reference
In GitLab, there is an API endpoint available to work with GitLab CI/CD YMLs. For more In GitLab, there is an API endpoint available to work with GitLab CI/CD YMLs. For more
information on CI/CD pipeline configuration in GitLab, see the information on CI/CD pipeline configuration in GitLab, see the
[configuration reference documentation](../../ci/yaml/README.md). [configuration reference documentation](../../ci/yaml/index.md).
## List GitLab CI YAML templates ## List GitLab CI YAML templates
......
doc/ci/caching/index.md
View file @ 0d978174
...@@ -11,7 +11,7 @@ A cache is one or more files that a job downloads and saves. Subsequent jobs tha ...@@ -11,7 +11,7 @@ A cache is one or more files that a job downloads and saves. Subsequent jobs tha
the same cache don't have to download the files again, so they execute more quickly. the same cache don't have to download the files again, so they execute more quickly.
To learn how to define the cache in your `.gitlab-ci.yml` file, To learn how to define the cache in your `.gitlab-ci.yml` file,
see the [`cache` reference](../yaml/README.md#cache). see the [`cache` reference](../yaml/index.md#cache).
## How cache is different from artifacts ## How cache is different from artifacts
...@@ -38,8 +38,8 @@ can't link to files outside it. ...@@ -38,8 +38,8 @@ can't link to files outside it.
- Subsequent jobs in later stages of the same pipeline can use artifacts. - Subsequent jobs in later stages of the same pipeline can use artifacts.
- Different projects cannot share artifacts. - Different projects cannot share artifacts.
Artifacts expire after 30 days unless you define an [expiration time](../yaml/README.md#artifactsexpire_in). Artifacts expire after 30 days unless you define an [expiration time](../yaml/index.md#artifactsexpire_in).
Use [dependencies](../yaml/README.md#dependencies) to control which jobs fetch the artifacts. Use [dependencies](../yaml/index.md#dependencies) to control which jobs fetch the artifacts.
## Good caching practices ## Good caching practices
...@@ -48,7 +48,7 @@ To ensure maximum availability of the cache, do one or more of the following: ...@@ -48,7 +48,7 @@ To ensure maximum availability of the cache, do one or more of the following:
- [Tag your runners](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) and use the tag on jobs - [Tag your runners](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) and use the tag on jobs
that share the cache. that share the cache.
- [Use runners that are only available to a particular project](../runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects). - [Use runners that are only available to a particular project](../runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects).
- [Use a `key`](../yaml/README.md#cachekey) that fits your workflow. For example, - [Use a `key`](../yaml/index.md#cachekey) that fits your workflow. For example,
you can configure a different cache for each branch. you can configure a different cache for each branch.
For runners to work with caches efficiently, you must do one of the following: For runners to work with caches efficiently, you must do one of the following:
...@@ -97,7 +97,7 @@ the fallback cache is fetched every time a cache is not found. ...@@ -97,7 +97,7 @@ the fallback cache is fetched every time a cache is not found.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1534) in GitLab Runner 13.4. > [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1534) in GitLab Runner 13.4.
You can use the `$CI_COMMIT_REF_SLUG` [predefined variable](../variables/predefined_variables.md) You can use the `$CI_COMMIT_REF_SLUG` [predefined variable](../variables/predefined_variables.md)
to specify your [`cache:key`](../yaml/README.md#cachekey). For example, if your to specify your [`cache:key`](../yaml/index.md#cachekey). For example, if your
`$CI_COMMIT_REF_SLUG` is `test`, you can set a job to download cache that's tagged with `test`. `$CI_COMMIT_REF_SLUG` is `test`, you can set a job to download cache that's tagged with `test`.
If a cache with this tag is not found, you can use `CACHE_FALLBACK_KEY` to If a cache with this tag is not found, you can use `CACHE_FALLBACK_KEY` to
...@@ -134,7 +134,7 @@ job: ...@@ -134,7 +134,7 @@ job:
## Inherit global configuration, but override specific settings per job ## Inherit global configuration, but override specific settings per job
You can override cache settings without overwriting the global cache by using You can override cache settings without overwriting the global cache by using
[anchors](../yaml/README.md#anchors). For example, if you want to override the [anchors](../yaml/index.md#anchors). For example, if you want to override the
`policy` for one job: `policy` for one job:
```yaml ```yaml
...@@ -154,7 +154,7 @@ job: ...@@ -154,7 +154,7 @@ job:
policy: pull policy: pull
``` ```
For more information, see [`cache: policy`](../yaml/README.md#cachepolicy). For more information, see [`cache: policy`](../yaml/index.md#cachepolicy).
## Common use cases for caches ## Common use cases for caches
...@@ -212,7 +212,7 @@ cache: ...@@ -212,7 +212,7 @@ cache:
If your project uses [npm](https://www.npmjs.com/) to install Node.js If your project uses [npm](https://www.npmjs.com/) to install Node.js
dependencies, the following example defines `cache` globally so that all jobs inherit it. dependencies, the following example defines `cache` globally so that all jobs inherit it.
By default, npm stores cache data in the home folder (`~/.npm`). However, you By default, npm stores cache data in the home folder (`~/.npm`). However, you
[can't cache things outside of the project directory](../yaml/README.md#cachepaths). [can't cache things outside of the project directory](../yaml/index.md#cachepaths).
Instead, tell npm to use `./.npm`, and cache it per-branch: Instead, tell npm to use `./.npm`, and cache it per-branch:
```yaml ```yaml
...@@ -392,7 +392,7 @@ test: ...@@ -392,7 +392,7 @@ test:
Caching is an optimization, but it isn't guaranteed to always work. You might need Caching is an optimization, but it isn't guaranteed to always work. You might need
to regenerate cached files in each job that needs them. to regenerate cached files in each job that needs them.
After you define a [cache in `.gitlab-ci.yml`](../yaml/README.md#cache), After you define a [cache in `.gitlab-ci.yml`](../yaml/index.md#cache),
the availability of the cache depends on: the availability of the cache depends on:
- The runner's executor type. - The runner's executor type.
...@@ -489,7 +489,7 @@ machines, it is a safe default. ...@@ -489,7 +489,7 @@ machines, it is a safe default.
## Clearing the cache ## Clearing the cache
Runners use [cache](../yaml/README.md#cache) to speed up the execution Runners use [cache](../yaml/index.md#cache) to speed up the execution
of your jobs by reusing existing data. This can sometimes lead to of your jobs by reusing existing data. This can sometimes lead to
inconsistent behavior. inconsistent behavior.
......
doc/ci/chatops/index.md
View file @ 0d978174
...@@ -32,7 +32,7 @@ to the job: ...@@ -32,7 +32,7 @@ to the job:
- `CHAT_CHANNEL` is set to the name of channel the action was triggered in. - `CHAT_CHANNEL` is set to the name of channel the action was triggered in.
When executed, ChatOps looks up the specified job name and attempts to match it When executed, ChatOps looks up the specified job name and attempts to match it
to a corresponding job in [`.gitlab-ci.yml`](../yaml/README.md). If a matching job to a corresponding job in [`.gitlab-ci.yml`](../yaml/index.md). If a matching job
is found on the default branch, a pipeline containing only that job is scheduled. After the is found on the default branch, a pipeline containing only that job is scheduled. After the
job completes: job completes:
......
doc/ci/cloud_deployment/index.md
View file @ 0d978174
...@@ -91,7 +91,7 @@ path to point to your ECR image. ...@@ -91,7 +91,7 @@ path to point to your ECR image.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207962) in GitLab 12.9. > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207962) in GitLab 12.9.
> - The `Deploy-ECS.gitlab-ci.yml` template was [moved](https://gitlab.com/gitlab-org/gitlab/-/issues/220821) to `AWS/Deploy-ECS.gitlab-ci.yml` in GitLab 13.2. > - The `Deploy-ECS.gitlab-ci.yml` template was [moved](https://gitlab.com/gitlab-org/gitlab/-/issues/220821) to `AWS/Deploy-ECS.gitlab-ci.yml` in GitLab 13.2.
GitLab provides a series of [CI templates that you can include in your project](../yaml/README.md#include). GitLab provides a series of [CI templates that you can include in your project](../yaml/index.md#include).
To automate deployments of your application to your [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (AWS ECS) To automate deployments of your application to your [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (AWS ECS)
cluster, you can `include` the `AWS/Deploy-ECS.gitlab-ci.yml` template in your `.gitlab-ci.yml` file. cluster, you can `include` the `AWS/Deploy-ECS.gitlab-ci.yml` template in your `.gitlab-ci.yml` file.
...@@ -231,7 +231,7 @@ pass three JSON input objects, based on existing templates: ...@@ -231,7 +231,7 @@ pass three JSON input objects, based on existing templates:
- [Template for the _Create stack_ step on AWS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-anatomy.html). - [Template for the _Create stack_ step on AWS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-anatomy.html).
- Template for the _Push to S3_ step. Note that `source` is where a preceding `build` job built - Template for the _Push to S3_ step. Note that `source` is where a preceding `build` job built
your application, exporting the build through [`artifacts:paths`](../yaml/README.md#artifactspaths): your application, exporting the build through [`artifacts:paths`](../yaml/index.md#artifactspaths):
```json ```json
{ {
......
doc/ci/directed_acyclic_graph/index.md
View file @ 0d978174
...@@ -66,9 +66,9 @@ as quickly as possible. ...@@ -66,9 +66,9 @@ as quickly as possible.
## Usage ## Usage
Relationships are defined between jobs using the [`needs:` keyword](../yaml/README.md#needs). Relationships are defined between jobs using the [`needs:` keyword](../yaml/index.md#needs).
Note that `needs:` also works with the [parallel](../yaml/README.md#parallel) keyword, Note that `needs:` also works with the [parallel](../yaml/index.md#parallel) keyword,
giving you powerful options for parallelization within your pipeline. giving you powerful options for parallelization within your pipeline.
## Limitations ## Limitations
...@@ -76,7 +76,7 @@ giving you powerful options for parallelization within your pipeline. ...@@ -76,7 +76,7 @@ giving you powerful options for parallelization within your pipeline.
A directed acyclic graph is a complicated feature, and as of the initial MVC there A directed acyclic graph is a complicated feature, and as of the initial MVC there
are certain use cases that you may need to work around. For more information: are certain use cases that you may need to work around. For more information:
- [`needs` requirements and limitations](../yaml/README.md#requirements-and-limitations). - [`needs` requirements and limitations](../yaml/index.md#requirements-and-limitations).
- Related epic [tracking planned improvements](https://gitlab.com/groups/gitlab-org/-/epics/1716). - Related epic [tracking planned improvements](https://gitlab.com/groups/gitlab-org/-/epics/1716).
## Needs Visualization ## Needs Visualization
......
doc/ci/docker/using_docker_build.md
View file @ 0d978174
...@@ -577,7 +577,7 @@ don't work because a fresh Docker daemon is started with the service. ...@@ -577,7 +577,7 @@ don't work because a fresh Docker daemon is started with the service.
### Option 1: Run `docker login` ### Option 1: Run `docker login`
In [`before_script`](../yaml/README.md#before_script), run `docker In [`before_script`](../yaml/index.md#before_script), run `docker
login`: login`:
```yaml ```yaml
...@@ -682,10 +682,10 @@ There are multiple ways to define this authentication: ...@@ -682,10 +682,10 @@ There are multiple ways to define this authentication:
- In [`pre_build_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section) - In [`pre_build_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section)
in the runner configuration file. in the runner configuration file.
- In [`before_script`](../yaml/README.md#before_script). - In [`before_script`](../yaml/index.md#before_script).
- In [`script`](../yaml/README.md#script). - In [`script`](../yaml/index.md#script).
The following example shows [`before_script`](../yaml/README.md#before_script). The following example shows [`before_script`](../yaml/index.md#before_script).
The same commands apply for any solution you implement. The same commands apply for any solution you implement.
```yaml ```yaml
...@@ -798,7 +798,7 @@ which can be avoided if a different driver is used, for example `overlay2`. ...@@ -798,7 +798,7 @@ which can be avoided if a different driver is used, for example `overlay2`.
### Use the OverlayFS driver per project ### Use the OverlayFS driver per project
You can enable the driver for each project individually by using the `DOCKER_DRIVER` You can enable the driver for each project individually by using the `DOCKER_DRIVER`
[CI/CD variable](../yaml/README.md#variables) in `.gitlab-ci.yml`: [CI/CD variable](../yaml/index.md#variables) in `.gitlab-ci.yml`:
```yaml ```yaml
variables: variables:
......
doc/ci/docker/using_docker_images.md
View file @ 0d978174
...@@ -153,9 +153,9 @@ CI/CD jobs: ...@@ -153,9 +153,9 @@ CI/CD jobs:
from `Dockerfile` that may be overridden in the `.gitlab-ci.yml` file. from `Dockerfile` that may be overridden in the `.gitlab-ci.yml` file.
1. The runner attaches itself to a running container. 1. The runner attaches itself to a running container.
1. The runner prepares a script (the combination of 1. The runner prepares a script (the combination of
[`before_script`](../yaml/README.md#before_script), [`before_script`](../yaml/index.md#before_script),
[`script`](../yaml/README.md#script), [`script`](../yaml/index.md#script),
and [`after_script`](../yaml/README.md#after_script)). and [`after_script`](../yaml/index.md#after_script)).
1. The runner sends the script to the container's shell `stdin` and receives the 1. The runner sends the script to the container's shell `stdin` and receives the
output. output.
......
doc/ci/enable_or_disable_ci.md
View file @ 0d978174
...@@ -9,7 +9,7 @@ type: howto ...@@ -9,7 +9,7 @@ type: howto
To effectively use GitLab CI/CD, you need: To effectively use GitLab CI/CD, you need:
- A valid [`.gitlab-ci.yml`](yaml/README.md) file present at the root directory - A valid [`.gitlab-ci.yml`](yaml/index.md) file present at the root directory
of your project. of your project.
- A [runner](runners/index.md) properly set up. - A [runner](runners/index.md) properly set up.
......
doc/ci/environments/deployment_safety.md
View file @ 0d978174
...@@ -35,7 +35,7 @@ Pipeline jobs in GitLab CI/CD run in parallel, so it's possible that two deploym ...@@ -35,7 +35,7 @@ Pipeline jobs in GitLab CI/CD run in parallel, so it's possible that two deploym
jobs in two different pipelines attempt to deploy to the same environment at the same jobs in two different pipelines attempt to deploy to the same environment at the same
time. This is not desired behavior as deployments should happen sequentially. time. This is not desired behavior as deployments should happen sequentially.
You can ensure only one deployment job runs at a time with the [`resource_group` keyword](../yaml/README.md#resource_group) in your `.gitlab-ci.yml`. You can ensure only one deployment job runs at a time with the [`resource_group` keyword](../yaml/index.md#resource_group) in your `.gitlab-ci.yml`.
For example: For example:
...@@ -59,7 +59,7 @@ The improved pipeline flow **after** using the resource group: ...@@ -59,7 +59,7 @@ The improved pipeline flow **after** using the resource group:
1. `deploy` job in Pipeline-A finishes. 1. `deploy` job in Pipeline-A finishes.
1. `deploy` job in Pipeline-B starts running. 1. `deploy` job in Pipeline-B starts running.
For more information, see [`resource_group` keyword in `.gitlab-ci.yml`](../yaml/README.md#resource_group). For more information, see [`resource_group` keyword in `.gitlab-ci.yml`](../yaml/index.md#resource_group).
## Skip outdated deployment jobs ## Skip outdated deployment jobs
......
doc/ci/environments/index.md
View file @ 0d978174
...@@ -10,7 +10,7 @@ disqus_identifier: 'https://docs.gitlab.com/ee/ci/environments.html' ...@@ -10,7 +10,7 @@ disqus_identifier: 'https://docs.gitlab.com/ee/ci/environments.html'
Environments describe where code is deployed. Environments describe where code is deployed.
Each time [GitLab CI/CD](../yaml/README.md) deploys a version of code to an environment, Each time [GitLab CI/CD](../yaml/index.md) deploys a version of code to an environment,
a deployment is created. a deployment is created.
GitLab: GitLab:
...@@ -84,7 +84,7 @@ When the job runs, the environment and deployment are created. ...@@ -84,7 +84,7 @@ When the job runs, the environment and deployment are created.
NOTE: NOTE:
Some characters cannot be used in environment names. Some characters cannot be used in environment names.
For more information about the `environment` keywords, see For more information about the `environment` keywords, see
[the `.gitlab-ci.yml` keyword reference](../yaml/README.md#environment). [the `.gitlab-ci.yml` keyword reference](../yaml/index.md#environment).
### Create a dynamic environment ### Create a dynamic environment
...@@ -107,7 +107,7 @@ deploy_review: ...@@ -107,7 +107,7 @@ deploy_review:
In this example: In this example:
- The `name` is `review/$CI_COMMIT_REF_NAME`. Because the [environment name](../yaml/README.md#environmentname) - The `name` is `review/$CI_COMMIT_REF_NAME`. Because the [environment name](../yaml/index.md#environmentname)
can contain slashes (`/`), you can use this pattern to distinguish between dynamic and static environments. can contain slashes (`/`), you can use this pattern to distinguish between dynamic and static environments.
- For the `url`, you could use `$CI_COMMIT_REF_NAME`, but because this value - For the `url`, you could use `$CI_COMMIT_REF_NAME`, but because this value
may contain a `/` or other characters that would not be valid in a domain name or URL, may contain a `/` or other characters that would not be valid in a domain name or URL,
...@@ -119,7 +119,7 @@ However, when you use this format, you can [group similar environments](#group-s ...@@ -119,7 +119,7 @@ However, when you use this format, you can [group similar environments](#group-s
NOTE: NOTE:
Some variables cannot be used as environment names or URLs. Some variables cannot be used as environment names or URLs.
For more information about the `environment` keywords, see For more information about the `environment` keywords, see
[the `.gitlab-ci.yml` keyword reference](../yaml/README.md#environment). [the `.gitlab-ci.yml` keyword reference](../yaml/index.md#environment).
## Deployment tier of environments ## Deployment tier of environments
...@@ -141,8 +141,8 @@ you can use tiers: ...@@ -141,8 +141,8 @@ you can use tiers:
| `development` | Dev, [Review apps](../review_apps/index.md), Trunk | | `development` | Dev, [Review apps](../review_apps/index.md), Trunk |
| `other` | | | `other` | |
By default, GitLab assumes a tier based on [the environment name](../yaml/README.md#environmentname). By default, GitLab assumes a tier based on [the environment name](../yaml/index.md#environmentname).
Instead, you can use the [`deployment_tier` keyword](../yaml/README.md#environmentdeployment_tier) to specify a tier. Instead, you can use the [`deployment_tier` keyword](../yaml/index.md#environmentdeployment_tier) to specify a tier.
## Configure manual deployments ## Configure manual deployments
...@@ -250,7 +250,7 @@ GitLab supports the [dotenv (`.env`)](https://github.com/bkeepers/dotenv) file f ...@@ -250,7 +250,7 @@ GitLab supports the [dotenv (`.env`)](https://github.com/bkeepers/dotenv) file f
and expands the `environment:url` value with variables defined in the `.env` file. and expands the `environment:url` value with variables defined in the `.env` file.
To use this feature, specify the To use this feature, specify the
[`artifacts:reports:dotenv`](../yaml/README.md#artifactsreportsdotenv) keyword in `.gitlab-ci.yml`. [`artifacts:reports:dotenv`](../yaml/index.md#artifactsreportsdotenv) keyword in `.gitlab-ci.yml`.
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i> <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). For an overview, see [Set dynamic URLs after a job finished](https://youtu.be/70jDXtOf4Ig).
...@@ -334,7 +334,7 @@ To retry or rollback a deployment: ...@@ -334,7 +334,7 @@ To retry or rollback a deployment:
### Environment URL ### Environment URL
The [environment URL](../yaml/README.md#environmenturl) is displayed in a few The [environment URL](../yaml/index.md#environmenturl) is displayed in a few
places in GitLab: places in GitLab:
- In a merge request as a link: - In a merge request as a link:
...@@ -364,7 +364,7 @@ When you stop an environment: ...@@ -364,7 +364,7 @@ When you stop an environment:
- On the **Environments** page, it moves from the list of **Available** environments - On the **Environments** page, it moves from the list of **Available** environments
to the list of **Stopped** environments. to the list of **Stopped** environments.
- An [`on_stop` action](../yaml/README.md#environmenton_stop), if defined, is executed. - An [`on_stop` action](../yaml/index.md#environmenton_stop), if defined, is executed.
Dynamic environments stop automatically when their associated branch is Dynamic environments stop automatically when their associated branch is
deleted. deleted.
...@@ -400,8 +400,8 @@ stop_review: ...@@ -400,8 +400,8 @@ stop_review:
when: manual when: manual
``` ```
Both jobs must have the same [`rules`](../yaml/README.md#only--except) Both jobs must have the same [`rules`](../yaml/index.md#only--except)
or [`only/except`](../yaml/README.md#only--except) configuration. Otherwise, or [`only/except`](../yaml/index.md#only--except) configuration. Otherwise,
the `stop_review` job might not be included in all pipelines that include the the `stop_review` job might not be included in all pipelines that include the
`deploy_review` job, and you cannot trigger `action: stop` to stop the environment automatically. `deploy_review` job, and you cannot trigger `action: stop` to stop the environment automatically.
...@@ -413,7 +413,7 @@ set the [`GIT_STRATEGY`](../runners/configure_runners.md#git-strategy) to `none` ...@@ -413,7 +413,7 @@ set the [`GIT_STRATEGY`](../runners/configure_runners.md#git-strategy) to `none`
`stop_review` job. Then the [runner](https://docs.gitlab.com/runner/) doesn't `stop_review` job. Then the [runner](https://docs.gitlab.com/runner/) doesn't
try to check out the code after the branch is deleted. try to check out the code after the branch is deleted.
Read more in the [`.gitlab-ci.yml` reference](../yaml/README.md#environmenton_stop). Read more in the [`.gitlab-ci.yml` reference](../yaml/index.md#environmenton_stop).
#### Stop an environment after a certain time period #### Stop an environment after a certain time period
...@@ -421,7 +421,7 @@ Read more in the [`.gitlab-ci.yml` reference](../yaml/README.md#environmenton_st ...@@ -421,7 +421,7 @@ Read more in the [`.gitlab-ci.yml` reference](../yaml/README.md#environmenton_st
You can set environments to stop automatically after a certain time period. You can set environments to stop automatically after a certain time period.
In your `.gitlab-ci.yml` file, specify the [`environment:auto_stop_in`](../yaml/README.md#environmentauto_stop_in) In your `.gitlab-ci.yml` file, specify the [`environment:auto_stop_in`](../yaml/index.md#environmentauto_stop_in)
keyword. You can specify a human-friendly date as the value, such as `1 hour and 30 minutes` or `1 day`. keyword. You can specify a human-friendly date as the value, such as `1 hour and 30 minutes` or `1 day`.
After the time period passes, GitLab automatically triggers a job to stop the environment. After the time period passes, GitLab automatically triggers a job to stop the environment.
...@@ -767,7 +767,7 @@ To ensure the `action: stop` can always run when needed, you can: ...@@ -767,7 +767,7 @@ To ensure the `action: stop` can always run when needed, you can:
when: manual when: manual
``` ```
- Add a [`needs`](../yaml/README.md#needs) entry to the `action: stop` job so the - Add a [`needs`](../yaml/index.md#needs) entry to the `action: stop` job so the
job can start out of stage order: job can start out of stage order:
```yaml ```yaml
......
doc/ci/examples/end_to_end_testing_webdriverio/index.md
View file @ 0d978174
...@@ -146,10 +146,10 @@ new browser window interacting with your app as you specified. ...@@ -146,10 +146,10 @@ new browser window interacting with your app as you specified.
Which brings us to the exciting part: how do we run this in GitLab CI/CD? There are two things we Which brings us to the exciting part: how do we run this in GitLab CI/CD? There are two things we
need to do for this: need to do for this:
1. Set up [CI/CD jobs](../../yaml/README.md) that actually have a browser available. 1. Set up [CI/CD jobs](../../yaml/index.md) that actually have a browser available.
1. Update our WebdriverIO configuration to use those browsers to visit the review apps. 1. Update our WebdriverIO configuration to use those browsers to visit the review apps.
For the scope of this article, we've defined an additional [CI/CD stage](../../yaml/README.md#stages) For the scope of this article, we've defined an additional [CI/CD stage](../../yaml/index.md#stages)
`confidence-check` that is executed _after_ the stage that deploys the review app. It uses the `node:latest` [Docker `confidence-check` that is executed _after_ the stage that deploys the review app. It uses the `node:latest` [Docker
image](../../docker/using_docker_images.md). However, WebdriverIO fires up actual browsers image](../../docker/using_docker_images.md). However, WebdriverIO fires up actual browsers
to interact with your application, so we need to install and run them. to interact with your application, so we need to install and run them.
...@@ -255,5 +255,5 @@ production project, see: ...@@ -255,5 +255,5 @@ production project, see:
There's plenty more that WebdriverIO can do. For example, you can configure a [`screenshotPath`](http://v4.webdriver.io/guide/getstarted/configuration.html#screenshotPath) to tell WebdriverIO to take There's plenty more that WebdriverIO can do. For example, you can configure a [`screenshotPath`](http://v4.webdriver.io/guide/getstarted/configuration.html#screenshotPath) to tell WebdriverIO to take
a screenshot when tests are failing. Then tell GitLab CI/CD to store those a screenshot when tests are failing. Then tell GitLab CI/CD to store those
[artifacts](../../yaml/README.md#artifacts), and you'll be able to see what went [artifacts](../../yaml/index.md#artifacts), and you'll be able to see what went
wrong within GitLab. wrong within GitLab.
doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
View file @ 0d978174
...@@ -548,7 +548,7 @@ If you wish to test your app with different PHP versions and [database managemen ...@@ -548,7 +548,7 @@ If you wish to test your app with different PHP versions and [database managemen
#### CI/CD variables #### CI/CD variables
GitLab CI/CD allows us to use [CI/CD variables](../../yaml/README.md#variables) in our jobs. GitLab CI/CD allows us to use [CI/CD variables](../../yaml/index.md#variables) in our jobs.
We defined MySQL as our database management system, which comes with a superuser root created by default. We defined MySQL as our database management system, which comes with a superuser root created by default.
So we should adjust the configuration of MySQL instance by defining `MYSQL_DATABASE` variable as our database name and `MYSQL_ROOT_PASSWORD` variable as the password of `root`. So we should adjust the configuration of MySQL instance by defining `MYSQL_DATABASE` variable as our database name and `MYSQL_ROOT_PASSWORD` variable as the password of `root`.
...@@ -567,7 +567,7 @@ variables: ...@@ -567,7 +567,7 @@ variables:
#### Unit Test as the first job #### Unit Test as the first job
We defined the required shell scripts as an array of the [script](../../yaml/README.md#script) keyword to be executed when running `unit_test` job. We defined the required shell scripts as an array of the [script](../../yaml/index.md#script) keyword to be executed when running `unit_test` job.
These scripts are some Artisan commands to prepare the Laravel, and, at the end of the script, we'll run the tests by `PHPUnit`. These scripts are some Artisan commands to prepare the Laravel, and, at the end of the script, we'll run the tests by `PHPUnit`.
...@@ -593,7 +593,7 @@ To deploy our app with Envoy, we had to set up the `$SSH_PRIVATE_KEY` variable a ...@@ -593,7 +593,7 @@ To deploy our app with Envoy, we had to set up the `$SSH_PRIVATE_KEY` variable a
If the SSH keys have added successfully, we can run Envoy. If the SSH keys have added successfully, we can run Envoy.
As mentioned before, GitLab supports [Continuous Delivery](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#continuous-delivery) methods as well. As mentioned before, GitLab supports [Continuous Delivery](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#continuous-delivery) methods as well.
The [environment](../../yaml/README.md#environment) keyword tells GitLab that this job deploys to the `production` environment. The [environment](../../yaml/index.md#environment) keyword tells GitLab that this job deploys to the `production` environment.
The `url` keyword is used to generate a link to our application on the GitLab Environments page. The `url` keyword is used to generate a link to our application on the GitLab Environments page.
The `only` keyword tells GitLab CI/CD that the job should be executed only when the pipeline is building the `main` branch. The `only` keyword tells GitLab CI/CD that the job should be executed only when the pipeline is building the `main` branch.
Lastly, `when: manual` is used to turn the job from running automatically to a manual action. Lastly, `when: manual` is used to turn the job from running automatically to a manual action.
......
doc/ci/index.md
View file @ 0d978174
...@@ -77,7 +77,7 @@ GitLab CI/CD supports numerous configuration options: ...@@ -77,7 +77,7 @@ GitLab CI/CD supports numerous configuration options:
| [Pipelines for Merge Requests](merge_request_pipelines/index.md) | Design a pipeline structure for running a pipeline in merge requests. | | [Pipelines for Merge Requests](merge_request_pipelines/index.md) | Design a pipeline structure for running a pipeline in merge requests. |
| [Integrate with Kubernetes clusters](../user/project/clusters/index.md) | Connect your project to Google Kubernetes Engine (GKE) or an existing Kubernetes cluster. | | [Integrate with Kubernetes clusters](../user/project/clusters/index.md) | Connect your project to Google Kubernetes Engine (GKE) or an existing Kubernetes cluster. |
| [Optimize GitLab and GitLab Runner for large repositories](large_repositories/index.md) | Recommended strategies for handling large repositories. | | [Optimize GitLab and GitLab Runner for large repositories](large_repositories/index.md) | Recommended strategies for handling large repositories. |
| [`.gitlab-ci.yml` full reference](yaml/README.md) | All the attributes you can use with GitLab CI/CD. | | [`.gitlab-ci.yml` full reference](yaml/index.md) | All the attributes you can use with GitLab CI/CD. |
Note that certain operations can only be performed according to the Note that certain operations can only be performed according to the
[user](../user/permissions.md#gitlab-cicd-permissions) and [job](../user/permissions.md#job-permissions) permissions. [user](../user/permissions.md#gitlab-cicd-permissions) and [job](../user/permissions.md#job-permissions) permissions.
......
doc/ci/jobs/index.md
View file @ 0d978174
...@@ -11,7 +11,7 @@ Pipeline configuration begins with jobs. Jobs are the most fundamental element o ...@@ -11,7 +11,7 @@ Pipeline configuration begins with jobs. Jobs are the most fundamental element o
Jobs are: Jobs are:
- Defined with constraints stating under what conditions they should be executed. - Defined with constraints stating under what conditions they should be executed.
- Top-level elements with an arbitrary name and must contain at least the [`script`](../yaml/README.md#script) clause. - Top-level elements with an arbitrary name and must contain at least the [`script`](../yaml/index.md#script) clause.
- Not limited in how many can be defined. - Not limited in how many can be defined.
For example: For example:
...@@ -101,7 +101,7 @@ jobs. Click to expand them. ...@@ -101,7 +101,7 @@ jobs. Click to expand them.
![Grouped pipelines](img/pipelines_grouped.png) ![Grouped pipelines](img/pipelines_grouped.png)
To create a group of jobs, in the [CI/CD pipeline configuration file](../yaml/README.md), To create a group of jobs, in the [CI/CD pipeline configuration file](../yaml/index.md),
separate each job name with a number and one of the following: separate each job name with a number and one of the following:
- A slash (`/`), for example, `test 1/3`, `test 2/3`, `test 3/3`. - A slash (`/`), for example, `test 1/3`, `test 2/3`, `test 3/3`.
...@@ -168,7 +168,7 @@ for a single run of the manual job. ...@@ -168,7 +168,7 @@ for a single run of the manual job.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21767) in GitLab 11.4. > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21767) in GitLab 11.4.
When you do not want to run a job immediately, you can use the [`when:delayed`](../yaml/README.md#whendelayed) keyword to When you do not want to run a job immediately, you can use the [`when:delayed`](../yaml/index.md#whendelayed) keyword to
delay a job's execution for a certain period. delay a job's execution for a certain period.
This is especially useful for timed incremental rollout where new code is rolled out gradually. This is especially useful for timed incremental rollout where new code is rolled out gradually.
......
doc/ci/jobs/job_control.md
View file @ 0d978174
...@@ -12,22 +12,22 @@ the status of variables, the pipeline type, and so on. ...@@ -12,22 +12,22 @@ the status of variables, the pipeline type, and so on.
To configure a job to be included or excluded from certain pipelines, you can use: To configure a job to be included or excluded from certain pipelines, you can use:
- [`rules`](../yaml/README.md#rules) - [`rules`](../yaml/index.md#rules)
- [`only`](../yaml/README.md#only--except) - [`only`](../yaml/index.md#only--except)
- [`except`](../yaml/README.md#only--except) - [`except`](../yaml/index.md#only--except)
Use [`needs`](../yaml/README.md#needs) to configure a job to run as soon as the Use [`needs`](../yaml/index.md#needs) to configure a job to run as soon as the
earlier jobs it depends on finish running. earlier jobs it depends on finish running.
## Specify when jobs run with `rules` ## Specify when jobs run with `rules`
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27863) in GitLab 12.3. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27863) in GitLab 12.3.
Use [`rules`](../yaml/README.md#rules) to include or exclude jobs in pipelines. Use [`rules`](../yaml/index.md#rules) to include or exclude jobs in pipelines.
Rules are evaluated in order until the first match. When a match is found, the job Rules are evaluated in order until the first match. When a match is found, the job
is either included or excluded from the pipeline, depending on the configuration. is either included or excluded from the pipeline, depending on the configuration.
See the [`rules`](../yaml/README.md#rules) reference for more details. See the [`rules`](../yaml/index.md#rules) reference for more details.
Future keyword improvements are being discussed in our [epic for improving `rules`](https://gitlab.com/groups/gitlab-org/-/epics/2783), Future keyword improvements are being discussed in our [epic for improving `rules`](https://gitlab.com/groups/gitlab-org/-/epics/2783),
where anyone can add suggestions or requests. where anyone can add suggestions or requests.
...@@ -150,7 +150,7 @@ causes duplicated pipelines. ...@@ -150,7 +150,7 @@ causes duplicated pipelines.
To avoid duplicate pipelines, you can: To avoid duplicate pipelines, you can:
- Use [`workflow`](../yaml/README.md#workflow) to specify which types of pipelines - Use [`workflow`](../yaml/index.md#workflow) to specify which types of pipelines
can run. can run.
- Rewrite the rules to run the job only in very specific cases, - Rewrite the rules to run the job only in very specific cases,
and avoid a final `when:` rule: and avoid a final `when:` rule:
...@@ -179,7 +179,7 @@ job: ...@@ -179,7 +179,7 @@ job:
``` ```
You should not include both push and merge request pipelines in the same job without You should not include both push and merge request pipelines in the same job without
[`workflow:rules` that prevent duplicate pipelines](../yaml/README.md#switch-between-branch-pipelines-and-merge-request-pipelines): [`workflow:rules` that prevent duplicate pipelines](../yaml/index.md#switch-between-branch-pipelines-and-merge-request-pipelines):
```yaml ```yaml
job: job:
...@@ -206,12 +206,12 @@ job-with-rules: ...@@ -206,12 +206,12 @@ job-with-rules:
For every change pushed to the branch, duplicate pipelines run. One For every change pushed to the branch, duplicate pipelines run. One
branch pipeline runs a single job (`job-with-no-rules`), and one merge request pipeline branch pipeline runs a single job (`job-with-no-rules`), and one merge request pipeline
runs the other job (`job-with-rules`). Jobs with no rules default runs the other job (`job-with-rules`). Jobs with no rules default
to [`except: merge_requests`](../yaml/README.md#only--except), so `job-with-no-rules` to [`except: merge_requests`](../yaml/index.md#only--except), so `job-with-no-rules`
runs in all cases except merge requests. runs in all cases except merge requests.
### Common `if` clauses for `rules` ### Common `if` clauses for `rules`
For behavior similar to the [`only`/`except` keywords](../yaml/README.md#only--except), you can For behavior similar to the [`only`/`except` keywords](../yaml/index.md#only--except), you can
check the value of the `$CI_PIPELINE_SOURCE` variable: check the value of the `$CI_PIPELINE_SOURCE` variable:
| Value | Description | | Value | Description |
...@@ -222,7 +222,7 @@ check the value of the `$CI_PIPELINE_SOURCE` variable: ...@@ -222,7 +222,7 @@ check the value of the `$CI_PIPELINE_SOURCE` variable:
| `external_pull_request_event` | When an external pull request on GitHub is created or updated. See [Pipelines for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). | | `external_pull_request_event` | When an external pull request on GitHub is created or updated. See [Pipelines for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). |
| `merge_request_event` | For pipelines created when a merge request is created or updated. Required to enable [merge request pipelines](../merge_request_pipelines/index.md), [merged results pipelines](../merge_request_pipelines/pipelines_for_merged_results/index.md), and [merge trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md). | | `merge_request_event` | For pipelines created when a merge request is created or updated. Required to enable [merge request pipelines](../merge_request_pipelines/index.md), [merged results pipelines](../merge_request_pipelines/pipelines_for_merged_results/index.md), and [merge trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md). |
| `parent_pipeline` | For pipelines triggered by a [parent/child pipeline](../parent_child_pipelines.md) with `rules`. Use this pipeline source in the child pipeline configuration so that it can be triggered by the parent pipeline. | | `parent_pipeline` | For pipelines triggered by a [parent/child pipeline](../parent_child_pipelines.md) with `rules`. Use this pipeline source in the child pipeline configuration so that it can be triggered by the parent pipeline. |
| `pipeline` | For [multi-project pipelines](../multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api), or the [`trigger`](../yaml/README.md#trigger) keyword. | | `pipeline` | For [multi-project pipelines](../multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api), or the [`trigger`](../yaml/index.md#trigger) keyword. |
| `push` | For pipelines triggered by a `git push` event, including for branches and tags. | | `push` | For pipelines triggered by a `git push` event, including for branches and tags. |
| `schedule` | For [scheduled pipelines](../pipelines/schedules.md). | | `schedule` | For [scheduled pipelines](../pipelines/schedules.md). |
| `trigger` | For pipelines created by using a [trigger token](../triggers/index.md#trigger-token). | | `trigger` | For pipelines created by using a [trigger token](../triggers/index.md#trigger-token). |
...@@ -292,7 +292,7 @@ You can use the `$` character for both variables and paths. For example, if the ...@@ -292,7 +292,7 @@ You can use the `$` character for both variables and paths. For example, if the
## Specify when jobs run with `only` and `except` ## Specify when jobs run with `only` and `except`
You can use [`only`](../yaml/README.md#only--except) and [`except`](../yaml/README.md#only--except) You can use [`only`](../yaml/index.md#only--except) and [`except`](../yaml/index.md#only--except)
to control when to add jobs to pipelines. to control when to add jobs to pipelines.
- Use `only` to define when a job runs. - Use `only` to define when a job runs.
...@@ -301,7 +301,7 @@ to control when to add jobs to pipelines. ...@@ -301,7 +301,7 @@ to control when to add jobs to pipelines.
### `only:refs` / `except:refs` examples ### `only:refs` / `except:refs` examples
`only` or `except` used without `refs` is the same as `only` or `except` used without `refs` is the same as
[`only:refs` / `except/refs`](../yaml/README.md#onlyrefs--exceptrefs) [`only:refs` / `except/refs`](../yaml/index.md#onlyrefs--exceptrefs)
In the following example, `job` runs only for: In the following example, `job` runs only for:
...@@ -334,7 +334,7 @@ except `main` and branches that start with `release/`. ...@@ -334,7 +334,7 @@ except `main` and branches that start with `release/`.
### `only: variables` / `except: variables` examples ### `only: variables` / `except: variables` examples
You can use [`except:variables`](../yaml/README.md#onlyvariables--exceptvariables) to exclude jobs based on a commit message: You can use [`except:variables`](../yaml/index.md#onlyvariables--exceptvariables) to exclude jobs based on a commit message:
```yaml ```yaml
end-to-end: end-to-end:
...@@ -502,9 +502,9 @@ test: ...@@ -502,9 +502,9 @@ test:
You can use [predefined CI/CD variables](../variables/predefined_variables.md) to choose You can use [predefined CI/CD variables](../variables/predefined_variables.md) to choose
which pipeline types jobs run in, with: which pipeline types jobs run in, with:
- [`rules`](../yaml/README.md#rules) - [`rules`](../yaml/index.md#rules)
- [`only:variables`](../yaml/README.md#onlyvariables--exceptvariables) - [`only:variables`](../yaml/index.md#onlyvariables--exceptvariables)
- [`except:variables`](../yaml/README.md#onlyvariables--exceptvariables) - [`except:variables`](../yaml/index.md#onlyvariables--exceptvariables)
The following table lists some of the variables that you can use, and the pipeline The following table lists some of the variables that you can use, and the pipeline
types the variables can control for: types the variables can control for:
...@@ -592,14 +592,14 @@ Feature.enable(:allow_unsafe_ruby_regexp) ...@@ -592,14 +592,14 @@ Feature.enable(:allow_unsafe_ruby_regexp)
## CI/CD variable expressions ## CI/CD variable expressions
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37397) in GitLab 10.7 for [the `only` and `except` CI keywords](../yaml/README.md#onlyvariables--exceptvariables) > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37397) in GitLab 10.7 for [the `only` and `except` CI keywords](../yaml/index.md#onlyvariables--exceptvariables)
> - [Expanded](https://gitlab.com/gitlab-org/gitlab/-/issues/27863) in GitLab 12.3 with [the `rules` keyword](../yaml/README.md#rules) > - [Expanded](https://gitlab.com/gitlab-org/gitlab/-/issues/27863) in GitLab 12.3 with [the `rules` keyword](../yaml/index.md#rules)
Use variable expressions to control which jobs are created in a pipeline after changes Use variable expressions to control which jobs are created in a pipeline after changes
are pushed to GitLab. You can use variable expressions with: are pushed to GitLab. You can use variable expressions with:
- [`rules:if`](../yaml/README.md#rules). - [`rules:if`](../yaml/index.md#rules).
- [`only:variables` and `except:variables`](../yaml/README.md#onlyvariables--exceptvariables). - [`only:variables` and `except:variables`](../yaml/index.md#onlyvariables--exceptvariables).
For example, with `rules:if`: For example, with `rules:if`:
......
doc/ci/lint.md
View file @ 0d978174
...@@ -20,7 +20,7 @@ in your project and click **CI lint**. ...@@ -20,7 +20,7 @@ in your project and click **CI lint**.
## Validate basic logic and syntax ## Validate basic logic and syntax
By default, the CI lint checks the syntax of your CI YAML configuration and also runs By default, the CI lint checks the syntax of your CI YAML configuration and also runs
some basic logical validations. Configuration added with the [`includes` keyword](yaml/README.md#include), some basic logical validations. Configuration added with the [`includes` keyword](yaml/index.md#include),
is also validated. is also validated.
To use the CI lint, paste a complete CI configuration (`.gitlab-ci.yml` for example) To use the CI lint, paste a complete CI configuration (`.gitlab-ci.yml` for example)
......
doc/ci/merge_request_pipelines/index.md
View file @ 0d978174
...@@ -39,13 +39,13 @@ To enable pipelines for merge requests: ...@@ -39,13 +39,13 @@ To enable pipelines for merge requests:
## Configure pipelines for merge requests ## Configure pipelines for merge requests
To configure pipelines for merge requests, you must configure your [CI/CD configuration file](../yaml/README.md). To configure pipelines for merge requests, you must configure your [CI/CD configuration file](../yaml/index.md).
To do this, you can use [`rules`](#use-rules-to-run-pipelines-for-merge-requests) or [`only/except`](#use-only-or-except-to-run-pipelines-for-merge-requests). To do this, you can use [`rules`](#use-rules-to-run-pipelines-for-merge-requests) or [`only/except`](#use-only-or-except-to-run-pipelines-for-merge-requests).
### Use `rules` to run pipelines for merge requests ### Use `rules` to run pipelines for merge requests
GitLab recommends that you use the `rules` keyword, which is available in GitLab recommends that you use the `rules` keyword, which is available in
[`workflow:rules` templates](../yaml/README.md#workflowrules-templates). [`workflow:rules` templates](../yaml/index.md#workflowrules-templates).
### Use `only` or `except` to run pipelines for merge requests ### Use `only` or `except` to run pipelines for merge requests
...@@ -138,7 +138,7 @@ Instead, use the ...@@ -138,7 +138,7 @@ Instead, use the
[`$CI_COMMIT_REF_NAME` predefined environment [`$CI_COMMIT_REF_NAME` predefined environment
variable](../variables/predefined_variables.md) in variable](../variables/predefined_variables.md) in
combination with combination with
[`only:variables`](../yaml/README.md#onlyvariables--exceptvariables) to [`only:variables`](../yaml/index.md#onlyvariables--exceptvariables) to
accomplish this behavior: accomplish this behavior:
```yaml ```yaml
...@@ -199,7 +199,7 @@ If you are seeing two pipelines when using `only/except`, please see the caveats ...@@ -199,7 +199,7 @@ If you are seeing two pipelines when using `only/except`, please see the caveats
related to using `only/except` above (or, consider moving to `rules`). related to using `only/except` above (or, consider moving to `rules`).
In [GitLab 13.7](https://gitlab.com/gitlab-org/gitlab/-/issues/201845) and later, In [GitLab 13.7](https://gitlab.com/gitlab-org/gitlab/-/issues/201845) and later,
you can add `workflow:rules` to [switch from branch pipelines to merge request pipelines](../yaml/README.md#switch-between-branch-pipelines-and-merge-request-pipelines). you can add `workflow:rules` to [switch from branch pipelines to merge request pipelines](../yaml/index.md#switch-between-branch-pipelines-and-merge-request-pipelines).
After a merge request is open on the branch, the pipeline switches to a merge request pipeline. After a merge request is open on the branch, the pipeline switches to a merge request pipeline.
### Two pipelines created when pushing an invalid CI configuration file ### Two pipelines created when pushing an invalid CI configuration file
......
doc/ci/metrics_reports.md
View file @ 0d978174
...@@ -37,7 +37,7 @@ For an MR, the values of these metrics from the feature branch are compared to t ...@@ -37,7 +37,7 @@ For an MR, the values of these metrics from the feature branch are compared to t
## How to set it up ## How to set it up
Add a job that creates a [metrics report](yaml/README.md#artifactsreportsmetrics) (default filename: `metrics.txt`). The file should conform to the [OpenMetrics](https://openmetrics.io/) format. Add a job that creates a [metrics report](yaml/index.md#artifactsreportsmetrics) (default filename: `metrics.txt`). The file should conform to the [OpenMetrics](https://openmetrics.io/) format.
For example: For example:
......
doc/ci/migration/circleci.md
View file @ 0d978174
...@@ -68,7 +68,7 @@ job1: ...@@ -68,7 +68,7 @@ job1:
### Workflows ### Workflows
CircleCI determines the run order for jobs with `workflows`. This is also used to determine concurrent, sequential, scheduled, or manual runs. The equivalent function in GitLab CI/CD is called [stages](../yaml/README.md#stages). Jobs on the same stage run in parallel, and only run after previous stages complete. Execution of the next stage is skipped when a job fails by default, but this can be allowed to continue even [after a failed job](../yaml/README.md#allow_failure). CircleCI determines the run order for jobs with `workflows`. This is also used to determine concurrent, sequential, scheduled, or manual runs. The equivalent function in GitLab CI/CD is called [stages](../yaml/index.md#stages). Jobs on the same stage run in parallel, and only run after previous stages complete. Execution of the next stage is skipped when a job fails by default, but this can be allowed to continue even [after a failed job](../yaml/index.md#allow_failure).
See [the Pipeline Architecture Overview](../pipelines/pipeline_architectures.md) for guidance on different types of pipelines that you can use. Pipelines can be tailored to meet your needs, such as for a large complex project or a monorepo with independent defined components. See [the Pipeline Architecture Overview](../pipelines/pipeline_architectures.md) for guidance on different types of pipelines that you can use. Pipelines can be tailored to meet your needs, such as for a large complex project or a monorepo with independent defined components.
...@@ -140,7 +140,7 @@ job4: ...@@ -140,7 +140,7 @@ job4:
#### Scheduled run #### Scheduled run
GitLab CI/CD has an easy to use UI to [schedule pipelines](../pipelines/schedules.md). Also, [rules](../yaml/README.md#rules) can be used to determine if jobs should be included or excluded from a scheduled pipeline. GitLab CI/CD has an easy to use UI to [schedule pipelines](../pipelines/schedules.md). Also, [rules](../yaml/index.md#rules) can be used to determine if jobs should be included or excluded from a scheduled pipeline.
CircleCI example of a scheduled workflow: CircleCI example of a scheduled workflow:
...@@ -159,7 +159,7 @@ scheduled-workflow: ...@@ -159,7 +159,7 @@ scheduled-workflow:
- build - build
``` ```
Example of the same scheduled pipeline using [`rules`](../yaml/README.md#rules) in GitLab CI/CD: Example of the same scheduled pipeline using [`rules`](../yaml/index.md#rules) in GitLab CI/CD:
```yaml ```yaml
job1: job1:
...@@ -188,7 +188,7 @@ release-branch-workflow: ...@@ -188,7 +188,7 @@ release-branch-workflow:
- testing - testing
``` ```
Example of the same workflow using [`when: manual`](../yaml/README.md#whenmanual) in GitLab CI/CD: Example of the same workflow using [`when: manual`](../yaml/index.md#whenmanual) in GitLab CI/CD:
```yaml ```yaml
deploy_prod: deploy_prod:
...@@ -200,7 +200,7 @@ deploy_prod: ...@@ -200,7 +200,7 @@ deploy_prod:
### Filter job by branch ### Filter job by branch
[Rules](../yaml/README.md#rules) are a mechanism to determine if the job runs for a specific branch. [Rules](../yaml/index.md#rules) are a mechanism to determine if the job runs for a specific branch.
CircleCI example of a job filtered by branch: CircleCI example of a job filtered by branch:
...@@ -294,7 +294,7 @@ GitLab.com shared runners: ...@@ -294,7 +294,7 @@ GitLab.com shared runners:
### Machine and specific build environments ### Machine and specific build environments
[Tags](../yaml/README.md#tags) can be used to run jobs on different platforms, by telling GitLab which runners should run the jobs. [Tags](../yaml/index.md#tags) can be used to run jobs on different platforms, by telling GitLab which runners should run the jobs.
CircleCI example of a job running on a specific environment: CircleCI example of a job running on a specific environment:
......
doc/ci/migration/jenkins.md
View file @ 0d978174
...@@ -19,7 +19,7 @@ that were able to quickly complete this migration: ...@@ -19,7 +19,7 @@ that were able to quickly complete this migration:
1. Learn the importance of [managing the organizational transition](#managing-the-organizational-transition). 1. Learn the importance of [managing the organizational transition](#managing-the-organizational-transition).
1. [Add runners](../runners/index.md) to your GitLab instance. 1. [Add runners](../runners/index.md) to your GitLab instance.
1. Educate and enable your developers to independently perform the following steps in their projects: 1. Educate and enable your developers to independently perform the following steps in their projects:
1. Review the [Quick Start Guide](../quick_start/index.md) and [Pipeline Configuration Reference](../yaml/README.md). 1. Review the [Quick Start Guide](../quick_start/index.md) and [Pipeline Configuration Reference](../yaml/index.md).
1. Use the [Jenkins Wrapper](#jenkinsfile-wrapper) to temporarily maintain fragile Jenkins jobs. 1. Use the [Jenkins Wrapper](#jenkinsfile-wrapper) to temporarily maintain fragile Jenkins jobs.
1. Migrate the build and CI jobs and configure them to show results directly in your merge requests. They can use [Auto DevOps](../../topics/autodevops/index.md) as a starting point, and [customize](../../topics/autodevops/customize.md) or [decompose](../../topics/autodevops/customize.md#using-components-of-auto-devops) the configuration as needed. 1. Migrate the build and CI jobs and configure them to show results directly in your merge requests. They can use [Auto DevOps](../../topics/autodevops/index.md) as a starting point, and [customize](../../topics/autodevops/customize.md) or [decompose](../../topics/autodevops/customize.md#using-components-of-auto-devops) the configuration as needed.
1. Add [Review Apps](../review_apps/index.md). 1. Add [Review Apps](../review_apps/index.md).
...@@ -71,7 +71,7 @@ If you are interested in helping GitLab test the wrapper, join our [public testi ...@@ -71,7 +71,7 @@ If you are interested in helping GitLab test the wrapper, join our [public testi
There are some high level differences between the products worth mentioning: There are some high level differences between the products worth mentioning:
- With GitLab you don't need a root `pipeline` keyword to wrap everything. - With GitLab you don't need a root `pipeline` keyword to wrap everything.
- The way pipelines are triggered and [trigger other pipelines](../yaml/README.md#trigger) - The way pipelines are triggered and [trigger other pipelines](../yaml/index.md#trigger)
is different than Jenkins. GitLab pipelines can be triggered: is different than Jenkins. GitLab pipelines can be triggered:
- on push - on push
...@@ -82,34 +82,34 @@ There are some high level differences between the products worth mentioning: ...@@ -82,34 +82,34 @@ There are some high level differences between the products worth mentioning:
- by [ChatOps](../chatops/index.md) - by [ChatOps](../chatops/index.md)
- You can control which jobs run in which cases, depending on how they are triggered, - You can control which jobs run in which cases, depending on how they are triggered,
with the [`rules` syntax](../yaml/README.md#rules). with the [`rules` syntax](../yaml/index.md#rules).
- GitLab [pipeline scheduling concepts](../pipelines/schedules.md) are also different from Jenkins. - GitLab [pipeline scheduling concepts](../pipelines/schedules.md) are also different from Jenkins.
- You can reuse pipeline configurations using the [`include` keyword](../yaml/README.md#include) - You can reuse pipeline configurations using the [`include` keyword](../yaml/index.md#include)
and [templates](#templates). Your templates can be kept in a central repository (with different and [templates](#templates). Your templates can be kept in a central repository (with different
permissions), and then any project can use them. This central project could also permissions), and then any project can use them. This central project could also
contain scripts or other reusable code. contain scripts or other reusable code.
- You can also use the [`extends` keyword](../yaml/README.md#extends) to reuse configuration - You can also use the [`extends` keyword](../yaml/index.md#extends) to reuse configuration
within a single pipeline configuration. within a single pipeline configuration.
- All jobs within a single stage always run in parallel, and all stages run in sequence. We are planning - All jobs within a single stage always run in parallel, and all stages run in sequence. We are planning
to allow certain jobs to break this sequencing as needed with our [directed acyclic graph](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47063) to allow certain jobs to break this sequencing as needed with our [directed acyclic graph](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47063)
feature. feature.
- The [`parallel`](../yaml/README.md#parallel) keyword can automatically parallelize tasks, - The [`parallel`](../yaml/index.md#parallel) keyword can automatically parallelize tasks,
like tests that support parallelization. like tests that support parallelization.
- Normally all jobs within a single stage run in parallel, and all stages run in sequence. - Normally all jobs within a single stage run in parallel, and all stages run in sequence.
There are different [pipeline architectures](../pipelines/pipeline_architectures.md) There are different [pipeline architectures](../pipelines/pipeline_architectures.md)
that allow you to change this behavior. that allow you to change this behavior.
- The new [`rules` syntax](../yaml/README.md#rules) is the recommended method of - The new [`rules` syntax](../yaml/index.md#rules) is the recommended method of
controlling when different jobs run. It is more powerful than the `only/except` syntax. controlling when different jobs run. It is more powerful than the `only/except` syntax.
- One important difference is that jobs run independently of each other and have a - One important difference is that jobs run independently of each other and have a
fresh environment in each job. Passing artifacts between jobs is controlled using the fresh environment in each job. Passing artifacts between jobs is controlled using the
[`artifacts`](../yaml/README.md#artifacts) and [`dependencies`](../yaml/README.md#dependencies) [`artifacts`](../yaml/index.md#artifacts) and [`dependencies`](../yaml/index.md#dependencies)
keywords. When finished, use the planned [Workspaces](https://gitlab.com/gitlab-org/gitlab/-/issues/29265) keywords. When finished, use the planned [Workspaces](https://gitlab.com/gitlab-org/gitlab/-/issues/29265)
feature to more easily persist a common workspace between serial jobs. feature to more easily persist a common workspace between serial jobs.
- The `.gitlab-ci.yml` file is checked in to the root of your repository, much like a Jenkinsfile, but - The `.gitlab-ci.yml` file is checked in to the root of your repository, much like a Jenkinsfile, but
is in the YAML format (see [complete reference](../yaml/README.md)) instead of a Groovy DSL. It's most is in the YAML format (see [complete reference](../yaml/index.md)) instead of a Groovy DSL. It's most
analogous to the declarative Jenkinsfile format. analogous to the declarative Jenkinsfile format.
- Manual approvals or gates can be set up as [`when:manual` jobs](../yaml/README.md#whenmanual). These can - Manual approvals or gates can be set up as [`when:manual` jobs](../yaml/index.md#whenmanual). These can
also leverage [`protected environments`](../yaml/README.md#protecting-manual-jobs) also leverage [`protected environments`](../yaml/index.md#protecting-manual-jobs)
to control who is able to approve them. to control who is able to approve them.
- GitLab comes with a [container registry](../../user/packages/container_registry/index.md), and we recommend using - GitLab comes with a [container registry](../../user/packages/container_registry/index.md), and we recommend using
container images to set up your build environment. For example, set up one pipeline that builds your build environment container images to set up your build environment. For example, set up one pipeline that builds your build environment
...@@ -154,8 +154,8 @@ and manage. ...@@ -154,8 +154,8 @@ and manage.
That said, we do of course still value DRY (don't repeat yourself) principles and want to ensure that That said, we do of course still value DRY (don't repeat yourself) principles and want to ensure that
behaviors of your jobs can be codified once and applied as needed. You can use the `extends:` syntax to behaviors of your jobs can be codified once and applied as needed. You can use the `extends:` syntax to
[reuse configuration in your jobs](../yaml/README.md#extends), and `include:` can [reuse configuration in your jobs](../yaml/index.md#extends), and `include:` can
be used to [reuse pipeline configurations](../yaml/README.md#include) in pipelines be used to [reuse pipeline configurations](../yaml/index.md#include) in pipelines
in different projects: in different projects:
```yaml ```yaml
...@@ -234,7 +234,7 @@ We also support using [tags](../runners/configure_runners.md#use-tags-to-limit-t ...@@ -234,7 +234,7 @@ We also support using [tags](../runners/configure_runners.md#use-tags-to-limit-t
to different runners (execution agents). to different runners (execution agents).
The `agent` section also allows you to define which Docker images should be used for execution, for which we use The `agent` section also allows you to define which Docker images should be used for execution, for which we use
the [`image`](../yaml/README.md#image) keyword. The `image` can be set on a single job or at the top level, in which the [`image`](../yaml/index.md#image) keyword. The `image` can be set on a single job or at the top level, in which
case it applies to all jobs in the pipeline: case it applies to all jobs in the pipeline:
```yaml ```yaml
...@@ -258,7 +258,7 @@ stages: ...@@ -258,7 +258,7 @@ stages:
``` ```
Setting a step to be performed before and after any job can be done via the Setting a step to be performed before and after any job can be done via the
[`before_script`](../yaml/README.md#before_script) and [`after_script`](../yaml/README.md#after_script) keywords: [`before_script`](../yaml/index.md#before_script) and [`after_script`](../yaml/index.md#after_script) keywords:
```yaml ```yaml
default: default:
...@@ -268,10 +268,10 @@ default: ...@@ -268,10 +268,10 @@ default:
#### `stages` #### `stages`
GitLab CI/CD also lets you define stages, but is a little bit more free-form to configure. The GitLab [`stages` keyword](../yaml/README.md#stages) GitLab CI/CD also lets you define stages, but is a little bit more free-form to configure. The GitLab [`stages` keyword](../yaml/index.md#stages)
is a top level setting that enumerates the list of stages, but you are not required to nest individual jobs underneath is a top level setting that enumerates the list of stages, but you are not required to nest individual jobs underneath
the `stages` section. Any job defined in the `.gitlab-ci.yml` can be made a part of any stage through use of the the `stages` section. Any job defined in the `.gitlab-ci.yml` can be made a part of any stage through use of the
[`stage:` keyword](../yaml/README.md#stage). [`stage:` keyword](../yaml/index.md#stage).
Note that, unless otherwise specified, every pipeline is instantiated with a `build`, `test`, and `deploy` stage Note that, unless otherwise specified, every pipeline is instantiated with a `build`, `test`, and `deploy` stage
which are run in that order. Jobs that have no `stage` defined are placed by default in the `test` stage. which are run in that order. Jobs that have no `stage` defined are placed by default in the `test` stage.
...@@ -289,7 +289,7 @@ my_job: ...@@ -289,7 +289,7 @@ my_job:
#### `steps` #### `steps`
The `steps` section is equivalent to the [`script` section](../yaml/README.md#script) of an individual job. This is The `steps` section is equivalent to the [`script` section](../yaml/index.md#script) of an individual job. This is
a simple YAML array with each line representing an individual command to be run: a simple YAML array with each line representing an individual command to be run:
```yaml ```yaml
...@@ -303,7 +303,7 @@ my_job: ...@@ -303,7 +303,7 @@ my_job:
#### `environment` #### `environment`
In GitLab, we use the [`variables` keyword](../yaml/README.md#variables) to define different variables at runtime. In GitLab, we use the [`variables` keyword](../yaml/index.md#variables) to define different variables at runtime.
These can also be set up through the GitLab UI, under CI/CD settings. See also our [general documentation on variables](../variables/index.md), These can also be set up through the GitLab UI, under CI/CD settings. See also our [general documentation on variables](../variables/index.md),
including the section on [protected variables](../variables/index.md#protect-a-cicd-variable) which can be used including the section on [protected variables](../variables/index.md#protect-a-cicd-variable) which can be used
to limit access to certain variables to certain environments or runners: to limit access to certain variables to certain environments or runners:
...@@ -318,7 +318,7 @@ variables: ...@@ -318,7 +318,7 @@ variables:
Here, options for different things exist associated with the object in question itself. For example, options related Here, options for different things exist associated with the object in question itself. For example, options related
to jobs are defined in relation to the job itself. If you're looking for a certain option, you should be able to find to jobs are defined in relation to the job itself. If you're looking for a certain option, you should be able to find
where it's located by searching our [complete configuration reference](../yaml/README.md) page. where it's located by searching our [complete configuration reference](../yaml/index.md) page.
#### `parameters` #### `parameters`
...@@ -347,9 +347,9 @@ variable entry. ...@@ -347,9 +347,9 @@ variable entry.
#### `when` #### `when`
GitLab does support a [`when` keyword](../yaml/README.md#when) which is used to indicate when a job should be GitLab does support a [`when` keyword](../yaml/index.md#when) which is used to indicate when a job should be
run in case of (or despite) failure, but most of the logic for controlling pipelines can be found in run in case of (or despite) failure, but most of the logic for controlling pipelines can be found in
our very powerful [`rules` system](../yaml/README.md#rules): our very powerful [`rules` system](../yaml/index.md#rules):
```yaml ```yaml
my_job: my_job:
......
doc/ci/multi_project_pipelines.md
View file @ 0d978174
...@@ -78,17 +78,17 @@ the `staging` job is marked as _failed_. ...@@ -78,17 +78,17 @@ the `staging` job is marked as _failed_.
#### Trigger job configuration keywords #### Trigger job configuration keywords
Trigger jobs can use only a limited set of the GitLab CI/CD [configuration keywords](yaml/README.md). Trigger jobs can use only a limited set of the GitLab CI/CD [configuration keywords](yaml/index.md).
The keywords available for use in trigger jobs are: The keywords available for use in trigger jobs are:
- [`trigger`](yaml/README.md#trigger) - [`trigger`](yaml/index.md#trigger)
- [`stage`](yaml/README.md#stage) - [`stage`](yaml/index.md#stage)
- [`allow_failure`](yaml/README.md#allow_failure) - [`allow_failure`](yaml/index.md#allow_failure)
- [`rules`](yaml/README.md#rules) - [`rules`](yaml/index.md#rules)
- [`only` and `except`](yaml/README.md#only--except) - [`only` and `except`](yaml/index.md#only--except)
- [`when`](yaml/README.md#when) (only with a value of `on_success`, `on_failure`, or `always`) - [`when`](yaml/index.md#when) (only with a value of `on_success`, `on_failure`, or `always`)
- [`extends`](yaml/README.md#extends) - [`extends`](yaml/index.md#extends)
- [`needs`](yaml/README.md#needs) - [`needs`](yaml/index.md#needs)
#### Specify a downstream pipeline branch #### Specify a downstream pipeline branch
...@@ -175,7 +175,7 @@ the ones defined in the upstream project take precedence. ...@@ -175,7 +175,7 @@ the ones defined in the upstream project take precedence.
#### Pass CI/CD variables to a downstream pipeline by using variable inheritance #### Pass CI/CD variables to a downstream pipeline by using variable inheritance
You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](variables/index.md#pass-an-environment-variable-to-another-job) and [cross project artifact downloads](yaml/README.md#cross-project-artifact-downloads-with-needs). You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](variables/index.md#pass-an-environment-variable-to-another-job) and [cross project artifact downloads](yaml/index.md#cross-project-artifact-downloads-with-needs).
In the upstream pipeline: In the upstream pipeline:
...@@ -215,14 +215,14 @@ In the upstream pipeline: ...@@ -215,14 +215,14 @@ In the upstream pipeline:
#### Use `rules` or `only`/`except` with multi-project pipelines #### Use `rules` or `only`/`except` with multi-project pipelines
You can use CI/CD variables or the [`rules`](yaml/README.md#rulesif) keyword to You can use CI/CD variables or the [`rules`](yaml/index.md#rulesif) keyword to
[control job behavior](jobs/job_control.md) for multi-project pipelines. When a [control job behavior](jobs/job_control.md) for multi-project pipelines. When a
downstream pipeline is triggered with the [`trigger`](yaml/README.md#trigger) keyword, downstream pipeline is triggered with the [`trigger`](yaml/index.md#trigger) keyword,
the value of the [`$CI_PIPELINE_SOURCE` predefined variable](variables/predefined_variables.md) the value of the [`$CI_PIPELINE_SOURCE` predefined variable](variables/predefined_variables.md)
is `pipeline` for all its jobs. is `pipeline` for all its jobs.
If you use [`only/except`](yaml/README.md#only--except) to control job behavior, use the If you use [`only/except`](yaml/index.md#only--except) to control job behavior, use the
[`pipelines`](yaml/README.md#onlyrefs--exceptrefs) keyword. [`pipelines`](yaml/index.md#onlyrefs--exceptrefs) keyword.
#### Mirror status of a triggered pipeline in the trigger job #### Mirror status of a triggered pipeline in the trigger job
...@@ -267,10 +267,10 @@ outbound connections for upstream and downstream pipeline dependencies. ...@@ -267,10 +267,10 @@ outbound connections for upstream and downstream pipeline dependencies.
When using: When using:
- CI/CD variables or [`rules`](yaml/README.md#rulesif) to control job behavior, the value of - CI/CD variables or [`rules`](yaml/index.md#rulesif) to control job behavior, the value of
the [`$CI_PIPELINE_SOURCE` predefined variable](variables/predefined_variables.md) is the [`$CI_PIPELINE_SOURCE` predefined variable](variables/predefined_variables.md) is
`pipeline` for multi-project pipeline triggered through the API with `CI_JOB_TOKEN`. `pipeline` for multi-project pipeline triggered through the API with `CI_JOB_TOKEN`.
- [`only/except`](yaml/README.md#only--except) to control job behavior, use the - [`only/except`](yaml/index.md#only--except) to control job behavior, use the
`pipelines` keyword. `pipelines` keyword.
## Trigger a pipeline when an upstream project is rebuilt **(PREMIUM)** ## Trigger a pipeline when an upstream project is rebuilt **(PREMIUM)**
......
doc/ci/parent_child_pipelines.md
View file @ 0d978174
...@@ -15,7 +15,7 @@ As pipelines grow more complex, a few related problems start to emerge: ...@@ -15,7 +15,7 @@ As pipelines grow more complex, a few related problems start to emerge:
job in next stage begins, causes arbitrary waits, slowing things down. job in next stage begins, causes arbitrary waits, slowing things down.
- Configuration for the single global pipeline becomes very long and complicated, - Configuration for the single global pipeline becomes very long and complicated,
making it hard to manage. making it hard to manage.
- Imports with [`include`](yaml/README.md#include) increase the complexity of the configuration, and create the potential - Imports with [`include`](yaml/index.md#include) increase the complexity of the configuration, and create the potential
for namespace collisions where jobs are unintentionally duplicated. for namespace collisions where jobs are unintentionally duplicated.
- Pipeline UX can become unwieldy with so many jobs and stages to work with. - Pipeline UX can become unwieldy with so many jobs and stages to work with.
...@@ -38,12 +38,12 @@ set of concurrently running child pipelines, but within the same project: ...@@ -38,12 +38,12 @@ set of concurrently running child pipelines, but within the same project:
Child pipelines work well with other GitLab CI/CD features: Child pipelines work well with other GitLab CI/CD features:
- Use [`rules: changes`](yaml/README.md#ruleschanges) to trigger pipelines only when - Use [`rules: changes`](yaml/index.md#ruleschanges) to trigger pipelines only when
certain files change. This is useful for monorepos, for example. certain files change. This is useful for monorepos, for example.
- Since the parent pipeline in `.gitlab-ci.yml` and the child pipeline run as normal - Since the parent pipeline in `.gitlab-ci.yml` and the child pipeline run as normal
pipelines, they can have their own behaviors and sequencing in relation to triggers. pipelines, they can have their own behaviors and sequencing in relation to triggers.
See the [`trigger:`](yaml/README.md#trigger) keyword documentation for full details on how to See the [`trigger:`](yaml/index.md#trigger) keyword documentation for full details on how to
include the child pipeline configuration. include the child pipeline configuration.
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i> <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
...@@ -51,7 +51,7 @@ For an overview, see [Parent-Child Pipelines feature demo](https://youtu.be/n8Kp ...@@ -51,7 +51,7 @@ For an overview, see [Parent-Child Pipelines feature demo](https://youtu.be/n8Kp
## Examples ## Examples
The simplest case is [triggering a child pipeline](yaml/README.md#trigger) using a The simplest case is [triggering a child pipeline](yaml/index.md#trigger) using a
local YAML file to define the pipeline configuration. In this case, the parent pipeline local YAML file to define the pipeline configuration. In this case, the parent pipeline
triggers the child pipeline, and continues without waiting: triggers the child pipeline, and continues without waiting:
...@@ -72,7 +72,7 @@ microservice_a: ...@@ -72,7 +72,7 @@ microservice_a:
``` ```
In [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/205157) and later, In [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/205157) and later,
you can use [`include:file`](yaml/README.md#includefile) to trigger child pipelines you can use [`include:file`](yaml/index.md#includefile) to trigger child pipelines
with a configuration file in a different project: with a configuration file in a different project:
```yaml ```yaml
...@@ -148,7 +148,7 @@ microservice_a: ...@@ -148,7 +148,7 @@ microservice_a:
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35632) in GitLab 12.9. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35632) in GitLab 12.9.
Instead of running a child pipeline from a static YAML file, you can define a job that runs Instead of running a child pipeline from a static YAML file, you can define a job that runs
your own script to generate a YAML file, which is then [used to trigger a child pipeline](yaml/README.md#trigger-child-pipeline-with-generated-configuration-file). your own script to generate a YAML file, which is then [used to trigger a child pipeline](yaml/index.md#trigger-child-pipeline-with-generated-configuration-file).
This technique can be very powerful in generating pipelines targeting content that changed or to This technique can be very powerful in generating pipelines targeting content that changed or to
build a matrix of targets and architectures. build a matrix of targets and architectures.
......
doc/ci/pipeline_editor/index.md
View file @ 0d978174
...@@ -18,7 +18,7 @@ From the pipeline editor page you can: ...@@ -18,7 +18,7 @@ From the pipeline editor page you can:
- Select the branch to work from. [Introduced in GitLab 13.12](https://gitlab.com/gitlab-org/gitlab/-/issues/326189), disabled by default. - Select the branch to work from. [Introduced in GitLab 13.12](https://gitlab.com/gitlab-org/gitlab/-/issues/326189), disabled by default.
- [Validate](#validate-ci-configuration) your configuration syntax while editing the file. - [Validate](#validate-ci-configuration) your configuration syntax while editing the file.
- Do a deeper [lint](#lint-ci-configuration) of your configuration, that verifies it with any configuration - Do a deeper [lint](#lint-ci-configuration) of your configuration, that verifies it with any configuration
added with the [`include`](../yaml/README.md#include) keyword. added with the [`include`](../yaml/index.md#include) keyword.
- See a [visualization](#visualize-ci-configuration) of the current configuration. - See a [visualization](#visualize-ci-configuration) of the current configuration.
- View an [expanded](#view-expanded-configuration) version of your configuration. - View an [expanded](#view-expanded-configuration) version of your configuration.
- [Commit](#commit-changes-to-ci-configuration) the changes to a specific branch. - [Commit](#commit-changes-to-ci-configuration) the changes to a specific branch.
...@@ -58,7 +58,7 @@ reflected in the CI lint. It displays the same results as the existing [CI Lint ...@@ -58,7 +58,7 @@ reflected in the CI lint. It displays the same results as the existing [CI Lint
To view a visualization of your `gitlab-ci.yml` configuration, in your project, To view a visualization of your `gitlab-ci.yml` configuration, in your project,
go to **CI/CD > Editor**, and then select the **Visualize** tab. The go to **CI/CD > Editor**, and then select the **Visualize** tab. The
visualization shows all stages and jobs. Any [`needs`](../yaml/README.md#needs) visualization shows all stages and jobs. Any [`needs`](../yaml/index.md#needs)
relationships are displayed as lines connecting jobs together, showing the relationships are displayed as lines connecting jobs together, showing the
hierarchy of execution: hierarchy of execution:
...@@ -80,10 +80,10 @@ To view the fully expanded CI/CD configuration as one combined file, go to the ...@@ -80,10 +80,10 @@ To view the fully expanded CI/CD configuration as one combined file, go to the
pipeline editor's **View merged YAML** tab. This tab displays an expanded configuration pipeline editor's **View merged YAML** tab. This tab displays an expanded configuration
where: where:
- Configuration imported with [`include`](../yaml/README.md#include) is copied into the view. - Configuration imported with [`include`](../yaml/index.md#include) is copied into the view.
- Jobs that use [`extends`](../yaml/README.md#extends) display with the - Jobs that use [`extends`](../yaml/index.md#extends) display with the
[extended configuration merged into the job](../yaml/README.md#merge-details). [extended configuration merged into the job](../yaml/index.md#merge-details).
- YAML anchors are [replaced with the linked configuration](../yaml/README.md#anchors). - YAML anchors are [replaced with the linked configuration](../yaml/index.md#anchors).
## Commit changes to CI configuration ## Commit changes to CI configuration
......
doc/ci/pipelines/index.md
View file @ 0d978174
...@@ -67,9 +67,9 @@ Pipelines can be configured in many different ways: ...@@ -67,9 +67,9 @@ Pipelines can be configured in many different ways:
Pipelines and their component jobs and stages are defined in the CI/CD pipeline configuration file for each project. Pipelines and their component jobs and stages are defined in the CI/CD pipeline configuration file for each project.
- [Jobs](../jobs/index.md) are the basic configuration component. - [Jobs](../jobs/index.md) are the basic configuration component.
- Stages are defined by using the [`stages`](../yaml/README.md#stages) keyword. - Stages are defined by using the [`stages`](../yaml/index.md#stages) keyword.
For a list of configuration options in the CI pipeline file, see the [GitLab CI/CD Pipeline Configuration Reference](../yaml/README.md). For a list of configuration options in the CI pipeline file, see the [GitLab CI/CD Pipeline Configuration Reference](../yaml/index.md).
You can also configure specific aspects of your pipelines through the GitLab UI. For example: You can also configure specific aspects of your pipelines through the GitLab UI. For example:
...@@ -146,7 +146,7 @@ The pipeline now executes the jobs as configured. ...@@ -146,7 +146,7 @@ The pipeline now executes the jobs as configured.
> [Introduced in](https://gitlab.com/gitlab-org/gitlab/-/issues/30101) GitLab 13.7. > [Introduced in](https://gitlab.com/gitlab-org/gitlab/-/issues/30101) GitLab 13.7.
You can use the [`value` and `description`](../yaml/README.md#prefill-variables-in-manual-pipelines) You can use the [`value` and `description`](../yaml/index.md#prefill-variables-in-manual-pipelines)
keywords to define keywords to define
[pipeline-level (global) variables](../variables/index.md#create-a-custom-cicd-variable-in-the-gitlab-ciyml-file) [pipeline-level (global) variables](../variables/index.md#create-a-custom-cicd-variable-in-the-gitlab-ciyml-file)
that are prefilled when running a pipeline manually. that are prefilled when running a pipeline manually.
...@@ -200,7 +200,7 @@ For each `var` or `file_var`, a key and value are required. ...@@ -200,7 +200,7 @@ For each `var` or `file_var`, a key and value are required.
### Add manual interaction to your pipeline ### Add manual interaction to your pipeline
Manual actions, configured using the [`when:manual`](../yaml/README.md#whenmanual) keyword, Manual actions, configured using the [`when:manual`](../yaml/index.md#whenmanual) keyword,
allow you to require manual interaction before moving forward in the pipeline. allow you to require manual interaction before moving forward in the pipeline.
You can do this straight from the pipeline graph. Just click the play button You can do this straight from the pipeline graph. Just click the play button
...@@ -347,7 +347,7 @@ You can group the jobs by: ...@@ -347,7 +347,7 @@ You can group the jobs by:
![jobs grouped by stage](img/pipelines_graph_stage_view_v13_12.png) ![jobs grouped by stage](img/pipelines_graph_stage_view_v13_12.png)
- [Job dependencies](#view-job-dependencies-in-the-pipeline-graph), which arranges - [Job dependencies](#view-job-dependencies-in-the-pipeline-graph), which arranges
jobs based on their [`needs`](../yaml/README.md#needs) dependencies. jobs based on their [`needs`](../yaml/index.md#needs) dependencies.
[Multi-project pipeline graphs](../multi_project_pipelines.md#multi-project-pipeline-visualization) help [Multi-project pipeline graphs](../multi_project_pipelines.md#multi-project-pipeline-visualization) help
you visualize the entire pipeline, including all cross-project inter-dependencies. **(PREMIUM)** you visualize the entire pipeline, including all cross-project inter-dependencies. **(PREMIUM)**
...@@ -365,7 +365,7 @@ This in-development feature might not be available for your use. There can be ...@@ -365,7 +365,7 @@ This in-development feature might not be available for your use. There can be
[risks when enabling features still in development](../../user/feature_flags.md#risks-when-enabling-features-still-in-development). [risks when enabling features still in development](../../user/feature_flags.md#risks-when-enabling-features-still-in-development).
Refer to this feature's version history for more details. Refer to this feature's version history for more details.
You can arrange jobs in the pipeline graph based on their [`needs`](../yaml/README.md#needs) You can arrange jobs in the pipeline graph based on their [`needs`](../yaml/index.md#needs)
dependencies. dependencies.
Jobs in the leftmost column run first, and jobs that depend on them are grouped in the next columns. Jobs in the leftmost column run first, and jobs that depend on them are grouped in the next columns.
......
doc/ci/pipelines/job_artifacts.md
View file @ 0d978174
...@@ -48,7 +48,7 @@ is used. ...@@ -48,7 +48,7 @@ is used.
If you run two types of pipelines (like branch and scheduled) for the same ref, If you run two types of pipelines (like branch and scheduled) for the same ref,
the pipeline that finishes later creates the job artifact. the pipeline that finishes later creates the job artifact.
For more examples, view the [keyword reference for the `.gitlab-ci.yml` file](../yaml/README.md#artifacts). For more examples, view the [keyword reference for the `.gitlab-ci.yml` file](../yaml/index.md#artifacts).
## Download job artifacts ## Download job artifacts
...@@ -173,7 +173,7 @@ https://gitlab.com/gitlab-org/gitlab/-/jobs/artifacts/main/file/htmlcov/index.ht ...@@ -173,7 +173,7 @@ https://gitlab.com/gitlab-org/gitlab/-/jobs/artifacts/main/file/htmlcov/index.ht
## When job artifacts are deleted ## When job artifacts are deleted
See the [`expire_in`](../yaml/README.md#artifactsexpire_in) documentation for information on when See the [`expire_in`](../yaml/index.md#artifactsexpire_in) documentation for information on when
job artifacts are deleted. job artifacts are deleted.
### Keep artifacts from most recent successful jobs ### Keep artifacts from most recent successful jobs
......
doc/ci/pipelines/pipeline_architectures.md
View file @ 0d978174
...@@ -18,7 +18,7 @@ own advantages. These methods can be mixed and matched if needed: ...@@ -18,7 +18,7 @@ own advantages. These methods can be mixed and matched if needed:
- [Child/Parent Pipelines](#child--parent-pipelines): Good for monorepos and projects with lots of independently defined components. - [Child/Parent Pipelines](#child--parent-pipelines): Good for monorepos and projects with lots of independently defined components.
For more details about For more details about
any of the keywords used below, check out our [CI YAML reference](../yaml/README.md) for details. any of the keywords used below, check out our [CI YAML reference](../yaml/index.md) for details.
## Basic Pipelines ## Basic Pipelines
...@@ -96,7 +96,7 @@ deploy_b: ...@@ -96,7 +96,7 @@ deploy_b:
If efficiency is important to you and you want everything to run as quickly as possible, If efficiency is important to you and you want everything to run as quickly as possible,
you can use [Directed Acyclic Graphs (DAG)](../directed_acyclic_graph/index.md). Use the you can use [Directed Acyclic Graphs (DAG)](../directed_acyclic_graph/index.md). Use the
[`needs` keyword](../yaml/README.md#needs) to define dependency relationships between [`needs` keyword](../yaml/index.md#needs) to define dependency relationships between
your jobs. When GitLab knows the relationships between your jobs, it can run everything your jobs. When GitLab knows the relationships between your jobs, it can run everything
as fast as possible, and even skips into subsequent stages when possible. as fast as possible, and even skips into subsequent stages when possible.
...@@ -163,12 +163,12 @@ deploy_b: ...@@ -163,12 +163,12 @@ deploy_b:
In the examples above, it's clear we've got two types of things that could be built independently. In the examples above, it's clear we've got two types of things that could be built independently.
This is an ideal case for using [Child / Parent Pipelines](../parent_child_pipelines.md)) via This is an ideal case for using [Child / Parent Pipelines](../parent_child_pipelines.md)) via
the [`trigger` keyword](../yaml/README.md#trigger). It separates out the configuration the [`trigger` keyword](../yaml/index.md#trigger). It separates out the configuration
into multiple files, keeping things very simple. You can also combine this with: into multiple files, keeping things very simple. You can also combine this with:
- The [`rules` keyword](../yaml/README.md#rules): For example, have the child pipelines triggered only - The [`rules` keyword](../yaml/index.md#rules): For example, have the child pipelines triggered only
when there are changes to that area. when there are changes to that area.
- The [`include` keyword](../yaml/README.md#include): Bring in common behaviors, ensuring - The [`include` keyword](../yaml/index.md#include): Bring in common behaviors, ensuring
you are not repeating yourself. you are not repeating yourself.
- [DAG pipelines](#directed-acyclic-graph-pipelines) inside of child pipelines, achieving the benefits of both. - [DAG pipelines](#directed-acyclic-graph-pipelines) inside of child pipelines, achieving the benefits of both.
......
doc/ci/pipelines/pipeline_artifacts.md
View file @ 0d978174
...@@ -9,7 +9,7 @@ type: reference, howto ...@@ -9,7 +9,7 @@ type: reference, howto
Pipeline artifacts are files created by GitLab after a pipeline finishes. These are different than [job artifacts](job_artifacts.md) because they are not explicitly managed by the `.gitlab-ci.yml` definitions. Pipeline artifacts are files created by GitLab after a pipeline finishes. These are different than [job artifacts](job_artifacts.md) because they are not explicitly managed by the `.gitlab-ci.yml` definitions.
Pipeline artifacts are used by the [test coverage visualization feature](../../user/project/merge_requests/test_coverage_visualization.md) to collect coverage information. It uses the [`artifacts: reports`](../yaml/README.md#artifactsreports) CI/CD keyword. Pipeline artifacts are used by the [test coverage visualization feature](../../user/project/merge_requests/test_coverage_visualization.md) to collect coverage information. It uses the [`artifacts: reports`](../yaml/index.md#artifactsreports) CI/CD keyword.
## Storage ## Storage
......
doc/ci/pipelines/pipeline_efficiency.md
View file @ 0d978174
...@@ -146,7 +146,7 @@ with embedded metric charts and all valuable details to analyze the problem. ...@@ -146,7 +146,7 @@ with embedded metric charts and all valuable details to analyze the problem.
Review the storage use of the following to help analyze costs and efficiency: Review the storage use of the following to help analyze costs and efficiency:
- [Job artifacts](job_artifacts.md) and their [`expire_in`](../yaml/README.md#artifactsexpire_in) - [Job artifacts](job_artifacts.md) and their [`expire_in`](../yaml/index.md#artifactsexpire_in)
configuration. If kept for too long, storage usage grows and could slow pipelines down. configuration. If kept for too long, storage usage grows and could slow pipelines down.
- [Container registry](../../user/packages/container_registry/index.md) usage. - [Container registry](../../user/packages/container_registry/index.md) usage.
- [Package registry](../../user/packages/package_registry/index.md) usage. - [Package registry](../../user/packages/package_registry/index.md) usage.
...@@ -162,9 +162,9 @@ make pipelines run faster and more efficiently. ...@@ -162,9 +162,9 @@ make pipelines run faster and more efficiently.
Try to find which jobs don't need to run in all situations, and use pipeline configuration Try to find which jobs don't need to run in all situations, and use pipeline configuration
to stop them from running: to stop them from running:
- Use the [`interruptible`](../yaml/README.md#interruptible) keyword to stop old pipelines - Use the [`interruptible`](../yaml/index.md#interruptible) keyword to stop old pipelines
when they are superseded by a newer pipeline. when they are superseded by a newer pipeline.
- Use [`rules`](../yaml/README.md#rules) to skip tests that aren't needed. For example, - Use [`rules`](../yaml/index.md#rules) to skip tests that aren't needed. For example,
skip backend tests when only the frontend code is changed. skip backend tests when only the frontend code is changed.
- Run non-essential [scheduled pipelines](schedules.md) less frequently. - Run non-essential [scheduled pipelines](schedules.md) less frequently.
...@@ -195,7 +195,7 @@ Another optimization method is to [cache](../caching/index.md) dependencies. If ...@@ -195,7 +195,7 @@ Another optimization method is to [cache](../caching/index.md) dependencies. If
dependencies change rarely, like [NodeJS `/node_modules`](../caching/index.md#cache-nodejs-dependencies), dependencies change rarely, like [NodeJS `/node_modules`](../caching/index.md#cache-nodejs-dependencies),
caching can make pipeline execution much faster. caching can make pipeline execution much faster.
You can use [`cache:when`](../yaml/README.md#cachewhen) to cache downloaded dependencies You can use [`cache:when`](../yaml/index.md#cachewhen) to cache downloaded dependencies
even when a job fails. even when a job fails.
### Docker Images ### Docker Images
......
doc/ci/pipelines/schedules.md
View file @ 0d978174
...@@ -52,14 +52,14 @@ is installed on. ...@@ -52,14 +52,14 @@ is installed on.
### Using variables ### Using variables
You can pass any number of arbitrary variables. They are available in You can pass any number of arbitrary variables. They are available in
GitLab CI/CD so that they can be used in your [`.gitlab-ci.yml` file](../../ci/yaml/README.md). GitLab CI/CD so that they can be used in your [`.gitlab-ci.yml` file](../../ci/yaml/index.md).
![Scheduled pipeline variables](img/pipeline_schedule_variables.png) ![Scheduled pipeline variables](img/pipeline_schedule_variables.png)
### Using `rules` ### Using `rules`
To configure a job to be executed only when the pipeline has been To configure a job to be executed only when the pipeline has been
scheduled, use the [`rules`](../yaml/README.md#rules) keyword. scheduled, use the [`rules`](../yaml/index.md#rules) keyword.
In this example, `make world` runs in scheduled pipelines, and `make build` In this example, `make world` runs in scheduled pipelines, and `make build`
runs in branch and tag pipelines: runs in branch and tag pipelines:
......
doc/ci/pipelines/settings.md
View file @ 0d978174
...@@ -228,7 +228,7 @@ You can set pending or running pipelines to cancel automatically when a new pipe ...@@ -228,7 +228,7 @@ You can set pending or running pipelines to cancel automatically when a new pipe
1. Check the **Auto-cancel redundant pipelines** checkbox. 1. Check the **Auto-cancel redundant pipelines** checkbox.
1. Click **Save changes**. 1. Click **Save changes**.
Use the [`interruptible`](../yaml/README.md#interruptible) keyword to indicate if a Use the [`interruptible`](../yaml/index.md#interruptible) keyword to indicate if a
running job can be cancelled before it completes. running job can be cancelled before it completes.
## Skip outdated deployment jobs ## Skip outdated deployment jobs
......
doc/ci/quick_start/index.md
View file @ 0d978174
...@@ -142,7 +142,7 @@ The pipeline starts when the commit is committed. ...@@ -142,7 +142,7 @@ The pipeline starts when the commit is committed.
- You can also use [CI/CD configuration visualization](../pipeline_editor/index.md#visualize-ci-configuration) to - You can also use [CI/CD configuration visualization](../pipeline_editor/index.md#visualize-ci-configuration) to
view a graphical representation of your `.gitlab-ci.yml` file. view a graphical representation of your `.gitlab-ci.yml` file.
- For the complete `.gitlab-ci.yml` syntax, see - For the complete `.gitlab-ci.yml` syntax, see
[the `.gitlab-ci.yml` reference topic](../yaml/README.md). [the `.gitlab-ci.yml` reference topic](../yaml/index.md).
### View the status of your pipeline and jobs ### View the status of your pipeline and jobs
......
doc/ci/runners/configure_runners.md
View file @ 0d978174
...@@ -169,13 +169,13 @@ GitLab CI tags are not the same as Git tags. GitLab CI tags are associated with ...@@ -169,13 +169,13 @@ GitLab CI tags are not the same as Git tags. GitLab CI tags are associated with
Git tags are associated with commits. Git tags are associated with commits.
By tagging a runner for the types of jobs it can handle, you can make sure By tagging a runner for the types of jobs it can handle, you can make sure
shared runners will [only run the jobs they are equipped to run](../yaml/README.md#tags). shared runners will [only run the jobs they are equipped to run](../yaml/index.md#tags).
For instance, at GitLab we have runners tagged with `rails` if they contain For instance, at GitLab we have runners tagged with `rails` if they contain
the appropriate dependencies to run Rails test suites. the appropriate dependencies to run Rails test suites.
When you [register a runner](https://docs.gitlab.com/runner/register/), its default behavior is to **only pick** When you [register a runner](https://docs.gitlab.com/runner/register/), its default behavior is to **only pick**
[tagged jobs](../yaml/README.md#tags). [tagged jobs](../yaml/index.md#tags).
To change this, you must have the [Owner role](../../user/permissions.md#project-members-permissions) for the project. To change this, you must have the [Owner role](../../user/permissions.md#project-members-permissions) for the project.
To make a runner pick untagged jobs: To make a runner pick untagged jobs:
...@@ -250,7 +250,7 @@ You can also use variables to configure how many times a runner ...@@ -250,7 +250,7 @@ You can also use variables to configure how many times a runner
> - `GIT_STRATEGY=none` requires GitLab Runner v1.7+. > - `GIT_STRATEGY=none` requires GitLab Runner v1.7+.
You can set the `GIT_STRATEGY` used to fetch the repository content, either You can set the `GIT_STRATEGY` used to fetch the repository content, either
globally or per-job in the [`variables`](../yaml/README.md#variables) section: globally or per-job in the [`variables`](../yaml/index.md#variables) section:
```yaml ```yaml
variables: variables:
...@@ -281,7 +281,7 @@ The `kubernetes` executor always clones into an temporary directory. ...@@ -281,7 +281,7 @@ The `kubernetes` executor always clones into an temporary directory.
A Git strategy of `none` also re-uses the local working copy, but skips all Git A Git strategy of `none` also re-uses the local working copy, but skips all Git
operations normally done by GitLab. GitLab Runner pre-clone scripts are also skipped, operations normally done by GitLab. GitLab Runner pre-clone scripts are also skipped,
if present. This strategy could mean you need to add `fetch` and `checkout` commands if present. This strategy could mean you need to add `fetch` and `checkout` commands
to [your `.gitlab-ci.yml` script](../yaml/README.md#script). to [your `.gitlab-ci.yml` script](../yaml/index.md#script).
It can be used for jobs that operate exclusively on artifacts, like a deployment job. It can be used for jobs that operate exclusively on artifacts, like a deployment job.
Git repository data may be present, but it's likely out of date. You should only Git repository data may be present, but it's likely out of date. You should only
...@@ -293,7 +293,7 @@ rely on files brought into the local working copy from cache or artifacts. ...@@ -293,7 +293,7 @@ rely on files brought into the local working copy from cache or artifacts.
The `GIT_SUBMODULE_STRATEGY` variable is used to control if / how Git The `GIT_SUBMODULE_STRATEGY` variable is used to control if / how Git
submodules are included when fetching the code before a build. You can set them submodules are included when fetching the code before a build. You can set them
globally or per-job in the [`variables`](../yaml/README.md#variables) section. globally or per-job in the [`variables`](../yaml/index.md#variables) section.
There are three possible values: `none`, `normal`, and `recursive`: There are three possible values: `none`, `normal`, and `recursive`:
...@@ -332,7 +332,7 @@ For this feature to work correctly, the submodules must be configured ...@@ -332,7 +332,7 @@ For this feature to work correctly, the submodules must be configured
The `GIT_CHECKOUT` variable can be used when the `GIT_STRATEGY` is set to either The `GIT_CHECKOUT` variable can be used when the `GIT_STRATEGY` is set to either
`clone` or `fetch` to specify whether a `git checkout` should be run. If not `clone` or `fetch` to specify whether a `git checkout` should be run. If not
specified, it defaults to true. You can set them globally or per-job in the specified, it defaults to true. You can set them globally or per-job in the
[`variables`](../yaml/README.md#variables) section. [`variables`](../yaml/index.md#variables) section.
If set to `false`, the runner: If set to `false`, the runner:
...@@ -360,7 +360,7 @@ script: ...@@ -360,7 +360,7 @@ script:
The `GIT_CLEAN_FLAGS` variable is used to control the default behavior of The `GIT_CLEAN_FLAGS` variable is used to control the default behavior of
`git clean` after checking out the sources. You can set it globally or per-job in the `git clean` after checking out the sources. You can set it globally or per-job in the
[`variables`](../yaml/README.md#variables) section. [`variables`](../yaml/index.md#variables) section.
`GIT_CLEAN_FLAGS` accepts all possible options of the [`git clean`](https://git-scm.com/docs/git-clean) `GIT_CLEAN_FLAGS` accepts all possible options of the [`git clean`](https://git-scm.com/docs/git-clean)
command. command.
...@@ -386,7 +386,7 @@ script: ...@@ -386,7 +386,7 @@ script:
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4142) in GitLab Runner 13.1. > [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4142) in GitLab Runner 13.1.
The `GIT_FETCH_EXTRA_FLAGS` variable is used to control the behavior of The `GIT_FETCH_EXTRA_FLAGS` variable is used to control the behavior of
`git fetch`. You can set it globally or per-job in the [`variables`](../yaml/README.md#variables) section. `git fetch`. You can set it globally or per-job in the [`variables`](../yaml/index.md#variables) section.
`GIT_FETCH_EXTRA_FLAGS` accepts all options of the [`git fetch`](https://git-scm.com/docs/git-fetch) command. However, `GIT_FETCH_EXTRA_FLAGS` flags are appended after the default flags that can't be modified. `GIT_FETCH_EXTRA_FLAGS` accepts all options of the [`git fetch`](https://git-scm.com/docs/git-fetch) command. However, `GIT_FETCH_EXTRA_FLAGS` flags are appended after the default flags that can't be modified.
...@@ -450,7 +450,7 @@ variables: ...@@ -450,7 +450,7 @@ variables:
GIT_DEPTH: "3" GIT_DEPTH: "3"
``` ```
You can set it globally or per-job in the [`variables`](../yaml/README.md#variables) section. You can set it globally or per-job in the [`variables`](../yaml/index.md#variables) section.
### Custom build directories ### Custom build directories
...@@ -559,7 +559,7 @@ variables: ...@@ -559,7 +559,7 @@ variables:
GET_SOURCES_ATTEMPTS: 3 GET_SOURCES_ATTEMPTS: 3
``` ```
You can set them globally or per-job in the [`variables`](../yaml/README.md#variables) section. You can set them globally or per-job in the [`variables`](../yaml/index.md#variables) section.
## System calls not available on GitLab.com shared runners ## System calls not available on GitLab.com shared runners
......
doc/ci/runners/index.md
View file @ 0d978174
...@@ -273,12 +273,12 @@ test: ...@@ -273,12 +273,12 @@ test:
for maintenance or updates. for maintenance or updates.
- The Windows shared runner virtual machine instances do not use the - The Windows shared runner virtual machine instances do not use the
GitLab Docker executor. This means that you can't specify GitLab Docker executor. This means that you can't specify
[`image`](../../ci/yaml/README.md#image) or [`services`](../../ci/yaml/README.md#services) in [`image`](../../ci/yaml/index.md#image) or [`services`](../../ci/yaml/index.md#services) in
your pipeline configuration. your pipeline configuration.
- For the beta release, we have included a set of software packages in - For the beta release, we have included a set of software packages in
the base VM image. If your CI job requires additional software that's the base VM image. If your CI job requires additional software that's
not included in this list, then you must add installation not included in this list, then you must add installation
commands to [`before_script`](../../ci/yaml/README.md#before_script) or [`script`](../../ci/yaml/README.md#script) to install the required commands to [`before_script`](../../ci/yaml/index.md#before_script) or [`script`](../../ci/yaml/index.md#script) to install the required
software. Note that each job runs on a new VM instance, so the software. Note that each job runs on a new VM instance, so the
installation of additional software packages needs to be repeated for installation of additional software packages needs to be repeated for
each job in your pipeline. each job in your pipeline.
......
doc/ci/secrets/index.md
View file @ 0d978174
...@@ -14,7 +14,7 @@ sensitive information can be items like API tokens, database credentials, or pri ...@@ -14,7 +14,7 @@ sensitive information can be items like API tokens, database credentials, or pri
Secrets are sourced from your secrets provider. Secrets are sourced from your secrets provider.
Unlike CI/CD variables, which are always presented to a job, secrets must be explicitly Unlike CI/CD variables, which are always presented to a job, secrets must be explicitly
required by a job. Read [GitLab CI/CD pipeline configuration reference](../yaml/README.md#secrets) required by a job. Read [GitLab CI/CD pipeline configuration reference](../yaml/index.md#secrets)
for more information about the syntax. for more information about the syntax.
GitLab has selected [Vault by HashiCorp](https://www.vaultproject.io) as the GitLab has selected [Vault by HashiCorp](https://www.vaultproject.io) as the
...@@ -117,7 +117,7 @@ The path to this file is stored in a CI/CD variable named `DATABASE_PASSWORD`, ...@@ -117,7 +117,7 @@ The path to this file is stored in a CI/CD variable named `DATABASE_PASSWORD`,
similar to [variables of type `file`](../variables/index.md#cicd-variable-types). similar to [variables of type `file`](../variables/index.md#cicd-variable-types).
For more information about the supported syntax, read the For more information about the supported syntax, read the
[`.gitlab-ci.yml` reference](../yaml/README.md#secretsvault). [`.gitlab-ci.yml` reference](../yaml/index.md#secretsvault).
## Configure Vault server roles ## Configure Vault server roles
......
doc/ci/ssh_keys/index.md
View file @ 0d978174
...@@ -94,7 +94,7 @@ to access it. This is where an SSH key pair comes in handy. ...@@ -94,7 +94,7 @@ to access it. This is where an SSH key pair comes in handy.
# - git config --global user.name "User name" # - git config --global user.name "User name"
``` ```
The [`before_script`](../yaml/README.md#before_script) can be set globally The [`before_script`](../yaml/index.md#before_script) can be set globally
or per-job. or per-job.
1. Make sure the private server's [SSH host keys are verified](#verifying-the-ssh-host-keys). 1. Make sure the private server's [SSH host keys are verified](#verifying-the-ssh-host-keys).
......
doc/ci/triggers/index.md
View file @ 0d978174
...@@ -26,7 +26,7 @@ depending on which trigger method is used. ...@@ -26,7 +26,7 @@ depending on which trigger method is used.
| `pipeline` | Using the `trigger:` keyword in the CI/CD configuration file, or using the trigger API with `$CI_JOB_TOKEN`. | | `pipeline` | Using the `trigger:` keyword in the CI/CD configuration file, or using the trigger API with `$CI_JOB_TOKEN`. |
| `trigger` | Using the trigger API using a generated trigger token | | `trigger` | Using the trigger API using a generated trigger token |
This also applies when using the `pipelines` or `triggers` keywords with the legacy [`only/except` basic syntax](../yaml/README.md#only--except). This also applies when using the `pipelines` or `triggers` keywords with the legacy [`only/except` basic syntax](../yaml/index.md#only--except).
### Trigger token ### Trigger token
...@@ -218,7 +218,7 @@ Using trigger variables can be proven useful for a variety of reasons: ...@@ -218,7 +218,7 @@ Using trigger variables can be proven useful for a variety of reasons:
a certain variable is present. a certain variable is present.
Consider the following `.gitlab-ci.yml` where we set three Consider the following `.gitlab-ci.yml` where we set three
[stages](../yaml/README.md#stages) and the `upload_package` job is run only [stages](../yaml/index.md#stages) and the `upload_package` job is run only
when all jobs from the test and build stages pass. When the `UPLOAD_TO_S3` when all jobs from the test and build stages pass. When the `UPLOAD_TO_S3`
variable is non-zero, `make upload` is run. variable is non-zero, `make upload` is run.
......
doc/ci/troubleshooting.md
View file @ 0d978174
...@@ -49,7 +49,7 @@ and check if their values are what you expect. ...@@ -49,7 +49,7 @@ and check if their values are what you expect.
## GitLab CI/CD documentation ## GitLab CI/CD documentation
The [complete `gitlab-ci.yml` reference](yaml/README.md) contains a full list of The [complete `gitlab-ci.yml` reference](yaml/index.md) contains a full list of
every keyword you may need to use to configure your pipelines. every keyword you may need to use to configure your pipelines.
You can also look at a large number of pipeline configuration [examples](examples/index.md) You can also look at a large number of pipeline configuration [examples](examples/index.md)
...@@ -105,7 +105,7 @@ If a pipeline does not seem to run at all, with no error message, it may also be ...@@ -105,7 +105,7 @@ If a pipeline does not seem to run at all, with no error message, it may also be
due to `rules` or `only/except` configuration, or the `workflow: rules` keyword. due to `rules` or `only/except` configuration, or the `workflow: rules` keyword.
If you are converting from `only/except` to the `rules` keyword, you should check If you are converting from `only/except` to the `rules` keyword, you should check
the [`rules` configuration details](yaml/README.md#rules) carefully. The behavior the [`rules` configuration details](yaml/index.md#rules) carefully. The behavior
of `only/except` and `rules` is different and can cause unexpected behavior when migrating of `only/except` and `rules` is different and can cause unexpected behavior when migrating
between the two. between the two.
...@@ -123,8 +123,8 @@ This is usually caused by the `rules` configuration, and there are several ways ...@@ -123,8 +123,8 @@ This is usually caused by the `rules` configuration, and there are several ways
#### A job is not in the pipeline #### A job is not in the pipeline
GitLab determines if a job is added to a pipeline based on the [`only/except`](yaml/README.md#only--except) GitLab determines if a job is added to a pipeline based on the [`only/except`](yaml/index.md#only--except)
or [`rules`](yaml/README.md#rules) defined for the job. If it didn't run, it's probably or [`rules`](yaml/index.md#rules) defined for the job. If it didn't run, it's probably
not evaluating as you expect. not evaluating as you expect.
#### No pipeline or the wrong type of pipeline runs #### No pipeline or the wrong type of pipeline runs
...@@ -141,7 +141,7 @@ be checked to make sure the jobs are added to the correct pipeline type. For ...@@ -141,7 +141,7 @@ be checked to make sure the jobs are added to the correct pipeline type. For
example, if a merge request pipeline did not run, the jobs may have been added to example, if a merge request pipeline did not run, the jobs may have been added to
a branch pipeline instead. a branch pipeline instead.
It's also possible that your [`workflow: rules`](yaml/README.md#workflow) configuration It's also possible that your [`workflow: rules`](yaml/index.md#workflow) configuration
blocked the pipeline, or allowed the wrong pipeline type. blocked the pipeline, or allowed the wrong pipeline type.
### A job runs unexpectedly ### A job runs unexpectedly
...@@ -150,8 +150,8 @@ A common reason a job is added to a pipeline unexpectedly is because the `change ...@@ -150,8 +150,8 @@ A common reason a job is added to a pipeline unexpectedly is because the `change
keyword always evaluates to true in certain cases. For example, `changes` is always keyword always evaluates to true in certain cases. For example, `changes` is always
true in certain pipeline types, including scheduled pipelines and pipelines for tags. true in certain pipeline types, including scheduled pipelines and pipelines for tags.
The `changes` keyword is used in combination with [`only/except`](yaml/README.md#onlychanges--exceptchanges) The `changes` keyword is used in combination with [`only/except`](yaml/index.md#onlychanges--exceptchanges)
or [`rules`](yaml/README.md#ruleschanges)). It's recommended to use `changes` with or [`rules`](yaml/index.md#ruleschanges)). It's recommended to use `changes` with
`rules` or `only/except` configuration that ensures the job is only added to branch `rules` or `only/except` configuration that ensures the job is only added to branch
pipelines or merge request pipelines. pipelines or merge request pipelines.
...@@ -249,17 +249,17 @@ If the merge train pipeline was canceled before the merge request was merged, wi ...@@ -249,17 +249,17 @@ If the merge train pipeline was canceled before the merge request was merged, wi
Pipeline configuration warnings are shown when you: Pipeline configuration warnings are shown when you:
- [Validate configuration with the CI Lint tool](yaml/README.md). - [Validate configuration with the CI Lint tool](yaml/index.md).
- [Manually run a pipeline](pipelines/index.md#run-a-pipeline-manually). - [Manually run a pipeline](pipelines/index.md#run-a-pipeline-manually).
### "Job may allow multiple pipelines to run for a single action" warning ### "Job may allow multiple pipelines to run for a single action" warning
When you use [`rules`](yaml/README.md#rules) with a `when:` clause without an `if:` When you use [`rules`](yaml/index.md#rules) with a `when:` clause without an `if:`
clause, multiple pipelines may run. Usually this occurs when you push a commit to clause, multiple pipelines may run. Usually this occurs when you push a commit to
a branch that has an open merge request associated with it. a branch that has an open merge request associated with it.
To [prevent duplicate pipelines](jobs/job_control.md#avoid-duplicate-pipelines), use To [prevent duplicate pipelines](jobs/job_control.md#avoid-duplicate-pipelines), use
[`workflow: rules`](yaml/README.md#workflow) or rewrite your rules to control [`workflow: rules`](yaml/index.md#workflow) or rewrite your rules to control
which pipelines can run. which pipelines can run.
### Console workaround if job using resource_group gets stuck ### Console workaround if job using resource_group gets stuck
......
doc/ci/unit_test_reports.md
View file @ 0d978174
...@@ -41,7 +41,7 @@ Consider the following workflow: ...@@ -41,7 +41,7 @@ Consider the following workflow:
## How it works ## How it works
First, GitLab Runner uploads all [JUnit report format 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) First, GitLab Runner uploads all [JUnit report format 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](yaml/README.md#artifactsreportsjunit) to GitLab. Then, when you visit a merge request, GitLab starts as [artifacts](yaml/index.md#artifactsreportsjunit) to GitLab. Then, when you visit a merge request, GitLab starts
comparing the head and base branch's JUnit report format XML files, where: comparing the head and base branch's JUnit report format XML files, where:
- The base branch is the target branch (usually the default branch). - The base branch is the target branch (usually the default branch).
...@@ -77,7 +77,7 @@ If a test failed in the project's default branch in the last 14 days, a message ...@@ -77,7 +77,7 @@ If a test failed in the project's default branch in the last 14 days, a message
## How to set it up ## How to set it up
To enable the Unit test reports in merge requests, you need to add To enable the Unit test reports in merge requests, you need to add
[`artifacts:reports:junit`](yaml/README.md#artifactsreportsjunit) [`artifacts:reports:junit`](yaml/index.md#artifactsreportsjunit)
in `.gitlab-ci.yml`, and specify the path(s) of the generated test reports. in `.gitlab-ci.yml`, and specify the path(s) of the generated test reports.
The reports must be `.xml` files, otherwise [GitLab returns an Error 500](https://gitlab.com/gitlab-org/gitlab/-/issues/216575). The reports must be `.xml` files, otherwise [GitLab returns an Error 500](https://gitlab.com/gitlab-org/gitlab/-/issues/216575).
...@@ -87,8 +87,8 @@ XML reports are stored in GitLab as artifacts and their results are shown in the ...@@ -87,8 +87,8 @@ XML reports are stored in GitLab as artifacts and their results are shown in the
merge request widget. merge request widget.
To make the Unit test report output files browsable, include them with the To make the Unit test report output files browsable, include them with the
[`artifacts:paths`](yaml/README.md#artifactspaths) keyword as well, as shown in the [Ruby example](#ruby-example). [`artifacts:paths`](yaml/index.md#artifactspaths) keyword as well, as shown in the [Ruby example](#ruby-example).
To upload the report even if the job fails (for example if the tests do not pass), use the [`artifacts:when:always`](yaml/README.md#artifactswhen) To upload the report even if the job fails (for example if the tests do not pass), use the [`artifacts:when:always`](yaml/index.md#artifactswhen)
keyword. keyword.
You cannot have multiple tests with the same name and class in your JUnit report format XML file. You cannot have multiple tests with the same name and class in your JUnit report format XML file.
...@@ -355,7 +355,7 @@ If parsing JUnit report XML results in an error, an indicator is shown next to t ...@@ -355,7 +355,7 @@ If parsing JUnit report XML results in an error, an indicator is shown next to t
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202114) in GitLab 13.0 behind the `:junit_pipeline_screenshots_view` feature flag, disabled by default. > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202114) in GitLab 13.0 behind the `:junit_pipeline_screenshots_view` feature flag, disabled by default.
> - The feature flag was removed and was [made generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/216979) in GitLab 13.12. > - The feature flag was removed and was [made generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/216979) in GitLab 13.12.
Upload your screenshots as [artifacts](yaml/README.md#artifactsreportsjunit) to GitLab. If JUnit Upload your screenshots as [artifacts](yaml/index.md#artifactsreportsjunit) to GitLab. If JUnit
report format XML files contain an `attachment` tag, GitLab parses the attachment. Note that: report format XML files contain an `attachment` tag, GitLab parses the attachment. Note that:
- The `attachment` tag **must** contain the relative path to `$CI_PROJECT_DIR` of the screenshots you uploaded. For - The `attachment` tag **must** contain the relative path to `$CI_PROJECT_DIR` of the screenshots you uploaded. For
...@@ -368,7 +368,7 @@ report format XML files contain an `attachment` tag, GitLab parses the attachmen ...@@ -368,7 +368,7 @@ report format XML files contain an `attachment` tag, GitLab parses the attachmen
``` ```
- You should set the job that uploads the screenshot to - You should set the job that uploads the screenshot to
[`artifacts:when: always`](yaml/README.md#artifactswhen) so that it still uploads a screenshot [`artifacts:when: always`](yaml/index.md#artifactswhen) so that it still uploads a screenshot
when a test fails. when a test fails.
A link to the test case attachment appears in the test case details in A link to the test case attachment appears in the test case details in
......
doc/ci/variables/index.md
View file @ 0d978174
...@@ -73,7 +73,7 @@ Make sure each variable is defined for the [scope you want to use it in](where_v ...@@ -73,7 +73,7 @@ Make sure each variable is defined for the [scope you want to use it in](where_v
### Create a custom CI/CD variable in the `.gitlab-ci.yml` file ### Create a custom CI/CD variable in the `.gitlab-ci.yml` file
To create a custom variable in the [`.gitlab-ci.yml`](../yaml/README.md#variables) file, To create a custom variable in the [`.gitlab-ci.yml`](../yaml/index.md#variables) file,
define the variable and value with `variables` keyword. define the variable and value with `variables` keyword.
You can use the `variables` keyword in a job or at the top level of the `.gitlab-ci.yml` file. You can use the `variables` keyword in a job or at the top level of the `.gitlab-ci.yml` file.
...@@ -119,7 +119,7 @@ script: ...@@ -119,7 +119,7 @@ script:
- 'eval "$LS_CMD"' # Executes 'ls -al $TMP_DIR' - 'eval "$LS_CMD"' # Executes 'ls -al $TMP_DIR'
``` ```
Use the [`value` and `description`](../yaml/README.md#prefill-variables-in-manual-pipelines) Use the [`value` and `description`](../yaml/index.md#prefill-variables-in-manual-pipelines)
keywords to define [variables that are prefilled](../pipelines/index.md#prefill-variables-in-manual-pipelines) keywords to define [variables that are prefilled](../pipelines/index.md#prefill-variables-in-manual-pipelines)
for [manually-triggered pipelines](../pipelines/index.md#run-a-pipeline-manually). for [manually-triggered pipelines](../pipelines/index.md#run-a-pipeline-manually).
...@@ -493,13 +493,13 @@ These variables cannot be used as CI/CD variables to configure a pipeline, but ...@@ -493,13 +493,13 @@ These variables cannot be used as CI/CD variables to configure a pipeline, but
they can be used in job scripts. they can be used in job scripts.
1. In the job script, save the variable as a `.env` file. 1. In the job script, save the variable as a `.env` file.
1. Save the `.env` file as an [`artifacts:reports:dotenv`](../yaml/README.md#artifactsreportsdotenv) 1. Save the `.env` file as an [`artifacts:reports:dotenv`](../yaml/index.md#artifactsreportsdotenv)
artifact. artifact.
1. Set a job in a later stage to receive the artifact by using the [`dependencies`](../yaml/README.md#dependencies) 1. Set a job in a later stage to receive the artifact by using the [`dependencies`](../yaml/index.md#dependencies)
or the [`needs`](../yaml/README.md#artifact-downloads-with-needs) keywords. or the [`needs`](../yaml/index.md#artifact-downloads-with-needs) keywords.
1. The later job can then [use the variable in scripts](#use-cicd-variables-in-job-scripts). 1. The later job can then [use the variable in scripts](#use-cicd-variables-in-job-scripts).
For example, with the [`dependencies`](../yaml/README.md#dependencies) keyword: For example, with the [`dependencies`](../yaml/index.md#dependencies) keyword:
```yaml ```yaml
build: build:
...@@ -518,7 +518,7 @@ deploy: ...@@ -518,7 +518,7 @@ deploy:
- build - build
``` ```
For example, with the [`needs`](../yaml/README.md#artifact-downloads-with-needs) keyword: For example, with the [`needs`](../yaml/index.md#artifact-downloads-with-needs) keyword:
```yaml ```yaml
build: build:
......
doc/ci/variables/predefined_variables.md
View file @ 0d978174
...@@ -49,10 +49,10 @@ There are also [Kubernetes-specific deployment variables](../../user/project/clu ...@@ -49,10 +49,10 @@ There are also [Kubernetes-specific deployment variables](../../user/project/clu
| `CI_DEPLOY_PASSWORD` | 10.8 | all | The authentication password of the [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token), if the project has one. | | `CI_DEPLOY_PASSWORD` | 10.8 | all | The authentication password of the [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token), if the project has one. |
| `CI_DEPLOY_USER` | 10.8 | all | The authentication username of the [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token), if the project has one. | | `CI_DEPLOY_USER` | 10.8 | all | The authentication username of the [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token), if the project has one. |
| `CI_DISPOSABLE_ENVIRONMENT` | all | 10.1 | Only available if the job is executed in a disposable environment (something that is created only for this job and disposed of/destroyed after the execution - all executors except `shell` and `ssh`). `true` when available. | | `CI_DISPOSABLE_ENVIRONMENT` | all | 10.1 | Only available if the job is executed in a disposable environment (something that is created only for this job and disposed of/destroyed after the execution - all executors except `shell` and `ssh`). `true` when available. |
| `CI_ENVIRONMENT_NAME` | 8.15 | all | The name of the environment for this job. Available if [`environment:name`](../yaml/README.md#environmentname) is set. | | `CI_ENVIRONMENT_NAME` | 8.15 | all | The name of the environment for this job. Available if [`environment:name`](../yaml/index.md#environmentname) is set. |
| `CI_ENVIRONMENT_SLUG` | 8.15 | all | The simplified version of the environment name, suitable for inclusion in DNS, URLs, Kubernetes labels, and so on. Available if [`environment:name`](../yaml/README.md#environmentname) is set. The slug is [truncated to 24 characters](https://gitlab.com/gitlab-org/gitlab/-/issues/20941). | | `CI_ENVIRONMENT_SLUG` | 8.15 | all | The simplified version of the environment name, suitable for inclusion in DNS, URLs, Kubernetes labels, and so on. Available if [`environment:name`](../yaml/index.md#environmentname) is set. The slug is [truncated to 24 characters](https://gitlab.com/gitlab-org/gitlab/-/issues/20941). |
| `CI_ENVIRONMENT_URL` | 9.3 | all | The URL of the environment for this job. Available if [`environment:url`](../yaml/README.md#environmenturl) is set. | | `CI_ENVIRONMENT_URL` | 9.3 | all | The URL of the environment for this job. Available if [`environment:url`](../yaml/index.md#environmenturl) is set. |
| `CI_ENVIRONMENT_ACTION` | 13.11 | all | The action annotation specified for this job's environment. Available if [`environment:action`](../yaml/README.md#environmentaction) is set. Can be `start`, `prepare`, or `stop`. | | `CI_ENVIRONMENT_ACTION` | 13.11 | all | The action annotation specified for this job's environment. Available if [`environment:action`](../yaml/index.md#environmentaction) is set. Can be `start`, `prepare`, or `stop`. |
| `CI_ENVIRONMENT_TIER` | 14.0 | all | The [deployment tier of the environment](../environments/index.md#deployment-tier-of-environments) for this job. | | `CI_ENVIRONMENT_TIER` | 14.0 | all | The [deployment tier of the environment](../environments/index.md#deployment-tier-of-environments) for this job. |
| `CI_HAS_OPEN_REQUIREMENTS` | 13.1 | all | Only available if the pipeline's project has an open [requirement](../../user/project/requirements/index.md). `true` when available. | | `CI_HAS_OPEN_REQUIREMENTS` | 13.1 | all | Only available if the pipeline's project has an open [requirement](../../user/project/requirements/index.md). `true` when available. |
| `CI_JOB_ID` | 9.0 | all | The internal ID of the job, unique across all jobs in the GitLab instance. | | `CI_JOB_ID` | 9.0 | all | The internal ID of the job, unique across all jobs in the GitLab instance. |
...@@ -61,13 +61,13 @@ There are also [Kubernetes-specific deployment variables](../../user/project/clu ...@@ -61,13 +61,13 @@ There are also [Kubernetes-specific deployment variables](../../user/project/clu
| `CI_JOB_MANUAL` | 8.12 | all | `true` if a job was started manually. | | `CI_JOB_MANUAL` | 8.12 | all | `true` if a job was started manually. |
| `CI_JOB_NAME` | 9.0 | 0.5 | The name of the job. | | `CI_JOB_NAME` | 9.0 | 0.5 | The name of the job. |
| `CI_JOB_STAGE` | 9.0 | 0.5 | The name of the job's stage. | | `CI_JOB_STAGE` | 9.0 | 0.5 | The name of the job's stage. |
| `CI_JOB_STATUS` | all | 13.5 | The status of the job as each runner stage is executed. Use with [`after_script`](../yaml/README.md#after_script). Can be `success`, `failed`, or `canceled`. | | `CI_JOB_STATUS` | all | 13.5 | The status of the job as each runner stage is executed. Use with [`after_script`](../yaml/index.md#after_script). Can be `success`, `failed`, or `canceled`. |
| `CI_JOB_TOKEN` | 9.0 | 1.2 | A token to authenticate with [certain API endpoints](../../api/index.md#gitlab-cicd-job-token). The token is valid as long as the job is running. | | `CI_JOB_TOKEN` | 9.0 | 1.2 | A token to authenticate with [certain API endpoints](../../api/index.md#gitlab-cicd-job-token). The token is valid as long as the job is running. |
| `CI_JOB_URL` | 11.1 | 0.5 | The job details URL. | | `CI_JOB_URL` | 11.1 | 0.5 | The job details URL. |
| `CI_JOB_STARTED_AT` | 13.10 | all | The UTC datetime when a job started, in [ISO 8601](https://tools.ietf.org/html/rfc3339#appendix-A) format. | | `CI_JOB_STARTED_AT` | 13.10 | all | The UTC datetime when a job started, in [ISO 8601](https://tools.ietf.org/html/rfc3339#appendix-A) format. |
| `CI_KUBERNETES_ACTIVE` | 13.0 | all | Only available if the pipeline has a Kubernetes cluster available for deployments. `true` when available. | | `CI_KUBERNETES_ACTIVE` | 13.0 | all | Only available if the pipeline has a Kubernetes cluster available for deployments. `true` when available. |
| `CI_NODE_INDEX` | 11.5 | all | The index of the job in the job set. Only available if the job uses [`parallel`](../yaml/README.md#parallel). | | `CI_NODE_INDEX` | 11.5 | all | The index of the job in the job set. Only available if the job uses [`parallel`](../yaml/index.md#parallel). |
| `CI_NODE_TOTAL` | 11.5 | all | The total number of instances of this job running in parallel. Set to `1` if the job does not use [`parallel`](../yaml/README.md#parallel). | | `CI_NODE_TOTAL` | 11.5 | all | The total number of instances of this job running in parallel. Set to `1` if the job does not use [`parallel`](../yaml/index.md#parallel). |
| `CI_OPEN_MERGE_REQUESTS` | 13.8 | all | A comma-separated list of up to four merge requests that use the current branch and project as the merge request source. Only available in branch and merge request pipelines if the branch has an associated merge request. For example, `gitlab-org/gitlab!333,gitlab-org/gitlab-foss!11`. | | `CI_OPEN_MERGE_REQUESTS` | 13.8 | all | A comma-separated list of up to four merge requests that use the current branch and project as the merge request source. Only available in branch and merge request pipelines if the branch has an associated merge request. For example, `gitlab-org/gitlab!333,gitlab-org/gitlab-foss!11`. |
| `CI_PAGES_DOMAIN` | 11.8 | all | The configured domain that hosts GitLab Pages. | | `CI_PAGES_DOMAIN` | 11.8 | all | The configured domain that hosts GitLab Pages. |
| `CI_PAGES_URL` | 11.8 | all | The URL for a GitLab Pages site. Always a subdomain of `CI_PAGES_DOMAIN`. | | `CI_PAGES_URL` | 11.8 | all | The URL for a GitLab Pages site. Always a subdomain of `CI_PAGES_DOMAIN`. |
......
doc/ci/variables/where_variables_can_be_used.md
View file @ 0d978174
...@@ -149,7 +149,7 @@ In the case of `after_script` scripts, they can: ...@@ -149,7 +149,7 @@ In the case of `after_script` scripts, they can:
- Not use variables defined in `before_script` and `script`. - Not use variables defined in `before_script` and `script`.
These restrictions exist because `after_script` scripts are executed in a These restrictions exist because `after_script` scripts are executed in a
[separated shell context](../yaml/README.md#after_script). [separated shell context](../yaml/index.md#after_script).
## Persisted variables ## Persisted variables
......
doc/ci/yaml/README.md
View file @ 0d978174
This diff is collapsed.
doc/ci/yaml/gitlab_ci_yaml.md
View file @ 0d978174
...@@ -13,7 +13,7 @@ type: reference ...@@ -13,7 +13,7 @@ type: reference
To use GitLab CI/CD, you need: To use GitLab CI/CD, you need:
- Application code hosted in a Git repository. - Application code hosted in a Git repository.
- A file called [`.gitlab-ci.yml`](README.md) in the root of your repository, which - A file called [`.gitlab-ci.yml`](index.md) in the root of your repository, which
contains the CI/CD configuration. contains the CI/CD configuration.
In the `.gitlab-ci.yml` file, you can define: In the `.gitlab-ci.yml` file, you can define:
...@@ -27,7 +27,7 @@ In the `.gitlab-ci.yml` file, you can define: ...@@ -27,7 +27,7 @@ In the `.gitlab-ci.yml` file, you can define:
The scripts are grouped into **jobs**, and jobs run as part of a larger The scripts are grouped into **jobs**, and jobs run as part of a larger
**pipeline**. You can group multiple independent jobs into **stages** that run in a defined order. **pipeline**. You can group multiple independent jobs into **stages** that run in a defined order.
The CI/CD configuration needs at least one job that is [not hidden](README.md#hide-jobs). The CI/CD configuration needs at least one job that is [not hidden](index.md#hide-jobs).
You should organize your jobs in a sequence that suits your application and is in accordance with You should organize your jobs in a sequence that suits your application and is in accordance with
the tests you wish to perform. To [visualize](../pipeline_editor/index.md#visualize-ci-configuration) the process, imagine the tests you wish to perform. To [visualize](../pipeline_editor/index.md#visualize-ci-configuration) the process, imagine
...@@ -89,4 +89,4 @@ If anything goes wrong, you can ...@@ -89,4 +89,4 @@ If anything goes wrong, you can
![rollback button](img/rollback.png) ![rollback button](img/rollback.png)
[View the full syntax for the `.gitlab-ci.yml` file](README.md). [View the full syntax for the `.gitlab-ci.yml` file](index.md).
doc/ci/yaml/includes.md
View file @ 0d978174
...@@ -7,8 +7,8 @@ type: reference ...@@ -7,8 +7,8 @@ type: reference
# GitLab CI/CD include examples **(FREE)** # GitLab CI/CD include examples **(FREE)**
In addition to the [`includes` examples](README.md#include) listed in the In addition to the [`includes` examples](index.md#include) listed in the
[GitLab CI YAML reference](README.md), this page lists more variations of `include` [GitLab CI YAML reference](index.md), this page lists more variations of `include`
usage. usage.
## Single string or array of multiple values ## Single string or array of multiple values
......
doc/ci/yaml/index.md 0 → 100644
View file @ 0d978174
This diff is collapsed.
doc/ci/yaml/script.md
View file @ 0d978174
...@@ -7,7 +7,7 @@ type: reference ...@@ -7,7 +7,7 @@ type: reference
# GitLab CI/CD script syntax **(FREE)** # GitLab CI/CD script syntax **(FREE)**
You can use special syntax in [`script`](README.md#script) sections to: You can use special syntax in [`script`](index.md#script) sections to:
- [Split long commands](#split-long-commands) into multiline commands. - [Split long commands](#split-long-commands) into multiline commands.
- [Use color codes](#add-color-codes-to-script-output) to make job logs easier to review. - [Use color codes](#add-color-codes-to-script-output) to make job logs easier to review.
......
doc/development/auto_devops.md
View file @ 0d978174
...@@ -18,7 +18,7 @@ is also available on YouTube. ...@@ -18,7 +18,7 @@ is also available on YouTube.
Auto DevOps builds on top of GitLab CI/CD to create an automatic pipeline Auto DevOps builds on top of GitLab CI/CD to create an automatic pipeline
based on your project contents. When Auto DevOps is enabled for a based on your project contents. When Auto DevOps is enabled for a
project, the user does not need to explicitly include any pipeline configuration project, the user does not need to explicitly include any pipeline configuration
through a [`.gitlab-ci.yml` file](../ci/yaml/README.md). through a [`.gitlab-ci.yml` file](../ci/yaml/index.md).
In the absence of a `.gitlab-ci.yml` file, the [Auto DevOps CI In the absence of a `.gitlab-ci.yml` file, the [Auto DevOps CI
template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
......
doc/development/cicd/cicd_reference_documentation_guide.md
View file @ 0d978174
...@@ -91,7 +91,7 @@ Keyword description and main details. ...@@ -91,7 +91,7 @@ Keyword description and main details.
### YAML reference style example ### YAML reference style example
See the [`only:changes` / `except:changes`](../../ci/yaml/README.md#onlychanges--exceptchanges) See the [`only:changes` / `except:changes`](../../ci/yaml/index.md#onlychanges--exceptchanges)
documentation for an example of the YAML reference style. The following example is a documentation for an example of the YAML reference style. The following example is a
shortened version of that documentation's Markdown: shortened version of that documentation's Markdown:
......
doc/development/cicd/index.md
View file @ 0d978174
...@@ -12,7 +12,7 @@ Development guides that are specific to CI/CD are listed here. ...@@ -12,7 +12,7 @@ Development guides that are specific to CI/CD are listed here.
If you are creating new CI/CD templates, please read [the development guide for GitLab CI/CD templates](templates.md). If you are creating new CI/CD templates, please read [the development guide for GitLab CI/CD templates](templates.md).
See the [CI/CD YAML reference documentation guide](cicd_reference_documentation_guide.md) See the [CI/CD YAML reference documentation guide](cicd_reference_documentation_guide.md)
to learn how to update the [reference page](../../ci/yaml/README.md). to learn how to update the [reference page](../../ci/yaml/index.md).
## CI Architecture overview ## CI Architecture overview
...@@ -33,7 +33,7 @@ On the left side we have the events that can trigger a pipeline based on various ...@@ -33,7 +33,7 @@ On the left side we have the events that can trigger a pipeline based on various
- When project is [subscribed to an upstream project](../../ci/multi_project_pipelines.md#trigger-a-pipeline-when-an-upstream-project-is-rebuilt). - When project is [subscribed to an upstream project](../../ci/multi_project_pipelines.md#trigger-a-pipeline-when-an-upstream-project-is-rebuilt).
- When [Auto DevOps](../../topics/autodevops/index.md) is enabled. - When [Auto DevOps](../../topics/autodevops/index.md) is enabled.
- When GitHub integration is used with [external pull requests](../../ci/ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). - When GitHub integration is used with [external pull requests](../../ci/ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests).
- When an upstream pipeline contains a [bridge job](../../ci/yaml/README.md#trigger) which triggers a downstream pipeline. - When an upstream pipeline contains a [bridge job](../../ci/yaml/index.md#trigger) which triggers a downstream pipeline.
Triggering any of these events invokes the [`CreatePipelineService`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/ci/create_pipeline_service.rb) Triggering any of these events invokes the [`CreatePipelineService`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/ci/create_pipeline_service.rb)
which takes as input event data and the user triggering it, then attempts to create a pipeline. which takes as input event data and the user triggering it, then attempts to create a pipeline.
...@@ -42,7 +42,7 @@ The `CreatePipelineService` relies heavily on the [`YAML Processor`](https://git ...@@ -42,7 +42,7 @@ The `CreatePipelineService` relies heavily on the [`YAML Processor`](https://git
component, which is responsible for taking in a YAML blob as input and returns the abstract data structure of a component, which is responsible for taking in a YAML blob as input and returns the abstract data structure of a
pipeline (including stages and all jobs). This component also validates the structure of the YAML while pipeline (including stages and all jobs). This component also validates the structure of the YAML while
processing it, and returns any syntax or semantic errors. The `YAML Processor` component is where we define processing it, and returns any syntax or semantic errors. The `YAML Processor` component is where we define
[all the keywords](../../ci/yaml/README.md) available to structure a pipeline. [all the keywords](../../ci/yaml/index.md) available to structure a pipeline.
The `CreatePipelineService` receives the abstract data structure returned by the `YAML Processor`, The `CreatePipelineService` receives the abstract data structure returned by the `YAML Processor`,
which then converts it to persisted models (pipeline, stages, jobs, etc.). After that, the pipeline is ready which then converts it to persisted models (pipeline, stages, jobs, etc.). After that, the pipeline is ready
...@@ -79,12 +79,12 @@ case the runner downloads them using a dedicated API endpoint. ...@@ -79,12 +79,12 @@ case the runner downloads them using a dedicated API endpoint.
Artifacts are stored in object storage, while metadata is kept in the database. An important example of artifacts Artifacts are stored in object storage, while metadata is kept in the database. An important example of artifacts
are reports (JUnit, SAST, DAST, etc.) which are parsed and rendered in the merge request. are reports (JUnit, SAST, DAST, etc.) which are parsed and rendered in the merge request.
Job status transitions are not all automated. A user may run [manual jobs](../../ci/yaml/README.md#whenmanual), cancel a pipeline, retry Job status transitions are not all automated. A user may run [manual jobs](../../ci/yaml/index.md#whenmanual), cancel a pipeline, retry
specific failed jobs or the entire pipeline. Anything that specific failed jobs or the entire pipeline. Anything that
causes a job to change status triggers `ProcessPipelineService`, as it's responsible for causes a job to change status triggers `ProcessPipelineService`, as it's responsible for
tracking the status of the entire pipeline. tracking the status of the entire pipeline.
A special type of job is the [bridge job](../../ci/yaml/README.md#trigger) which is executed server-side A special type of job is the [bridge job](../../ci/yaml/index.md#trigger) which is executed server-side
when transitioning to the `pending` state. This job is responsible for creating a downstream pipeline, such as when transitioning to the `pending` state. This job is responsible for creating a downstream pipeline, such as
a multi-project or child pipeline. The workflow loop starts again a multi-project or child pipeline. The workflow loop starts again
from the `CreatePipelineService` every time a downstream pipeline is triggered. from the `CreatePipelineService` every time a downstream pipeline is triggered.
......
doc/development/cicd/templates.md
View file @ 0d978174
...@@ -16,7 +16,7 @@ Before submitting a merge request with a new or updated CI/CD template, you must ...@@ -16,7 +16,7 @@ Before submitting a merge request with a new or updated CI/CD template, you must
- Place the template in the correct [directory](#template-directories). - Place the template in the correct [directory](#template-directories).
- Follow the [CI/CD template authoring guidelines](#template-authoring-guidelines). - Follow the [CI/CD template authoring guidelines](#template-authoring-guidelines).
- Name the template following the `*.gitlab-ci.yml` format. - Name the template following the `*.gitlab-ci.yml` format.
- Use valid [`.gitlab-ci.yml` syntax](../../ci/yaml/README.md). Verify it's valid - Use valid [`.gitlab-ci.yml` syntax](../../ci/yaml/index.md). Verify it's valid
with the [CI/CD lint tool](../../ci/lint.md). with the [CI/CD lint tool](../../ci/lint.md).
- Include [a changelog](../changelog.md) if the merge request introduces a user-facing change. - Include [a changelog](../changelog.md) if the merge request introduces a user-facing change.
- Follow the [template review process](#contribute-cicd-template-merge-requests). - Follow the [template review process](#contribute-cicd-template-merge-requests).
...@@ -59,8 +59,8 @@ don't have any other `.gitlab-ci.yml` files. ...@@ -59,8 +59,8 @@ don't have any other `.gitlab-ci.yml` files.
When authoring pipeline templates: When authoring pipeline templates:
- Place any [global keywords](../../ci/yaml/README.md#global-keywords) like `image` - Place any [global keywords](../../ci/yaml/index.md#global-keywords) like `image`
or `before_script` in a [`default`](../../ci/yaml/README.md#custom-default-keyword-values) or `before_script` in a [`default`](../../ci/yaml/index.md#custom-default-keyword-values)
section at the top of the template. section at the top of the template.
- Note clearly in the [code comments](#explain-the-template-with-comments) if the - Note clearly in the [code comments](#explain-the-template-with-comments) if the
template is designed to be used with the `includes` keyword in an existing template is designed to be used with the `includes` keyword in an existing
...@@ -68,7 +68,7 @@ When authoring pipeline templates: ...@@ -68,7 +68,7 @@ When authoring pipeline templates:
A **job template** provides specific jobs that can be added to an existing CI/CD A **job template** provides specific jobs that can be added to an existing CI/CD
workflow to accomplish specific tasks. It usually should be used by adding it to workflow to accomplish specific tasks. It usually should be used by adding it to
an existing `.gitlab-ci.yml` file by using the [`includes`](../../ci/yaml/README.md#global-keywords) an existing `.gitlab-ci.yml` file by using the [`includes`](../../ci/yaml/index.md#global-keywords)
keyword. You can also copy and paste the contents into an existing `.gitlab-ci.yml` file. keyword. You can also copy and paste the contents into an existing `.gitlab-ci.yml` file.
Configure job templates so that users can add them to their current pipeline with very Configure job templates so that users can add them to their current pipeline with very
...@@ -77,7 +77,7 @@ other pipeline configuration. ...@@ -77,7 +77,7 @@ other pipeline configuration.
When authoring job templates: When authoring job templates:
- Do not use [global](../../ci/yaml/README.md#global-keywords) or [`default`](../../ci/yaml/README.md#custom-default-keyword-values) - Do not use [global](../../ci/yaml/index.md#global-keywords) or [`default`](../../ci/yaml/index.md#custom-default-keyword-values)
keywords. When a root `.gitlab-ci.yml` includes a template, global or default keywords keywords. When a root `.gitlab-ci.yml` includes a template, global or default keywords
might be overridden and cause unexpected behavior. If a job template requires a might be overridden and cause unexpected behavior. If a job template requires a
specific stage, explain in the code comments that users must manually add the stage specific stage, explain in the code comments that users must manually add the stage
...@@ -127,8 +127,8 @@ job2: ...@@ -127,8 +127,8 @@ job2:
#### Use `rules` instead of `only` or `except` #### Use `rules` instead of `only` or `except`
Avoid using [`only` or `except`](../../ci/yaml/README.md#only--except) if possible. Avoid using [`only` or `except`](../../ci/yaml/index.md#only--except) if possible.
Only and except is not being developed any more, and [`rules`](../../ci/yaml/README.md#rules) Only and except is not being developed any more, and [`rules`](../../ci/yaml/index.md#rules)
is now the preferred syntax: is now the preferred syntax:
```yaml ```yaml
......
doc/development/documentation/index.md
View file @ 0d978174
...@@ -123,7 +123,7 @@ following: ...@@ -123,7 +123,7 @@ following:
- `tutorial`: Learn a process/concept by doing. - `tutorial`: Learn a process/concept by doing.
[Example page](../../gitlab-basics/start-using-git.md). [Example page](../../gitlab-basics/start-using-git.md).
- `reference`: A collection of information used as a reference to use a feature - `reference`: A collection of information used as a reference to use a feature
or a functionality. [Example page](../../ci/yaml/README.md). or a functionality. [Example page](../../ci/yaml/index.md).
### Redirection metadata ### Redirection metadata
...@@ -475,10 +475,10 @@ If you want to know the in-depth details, here's what's really happening: ...@@ -475,10 +475,10 @@ If you want to know the in-depth details, here's what's really happening:
The following GitLab features are used among others: The following GitLab features are used among others:
- [Manual actions](../../ci/yaml/README.md#whenmanual) - [Manual actions](../../ci/yaml/index.md#whenmanual)
- [Multi project pipelines](../../ci/multi_project_pipelines.md) - [Multi project pipelines](../../ci/multi_project_pipelines.md)
- [Review Apps](../../ci/review_apps/index.md) - [Review Apps](../../ci/review_apps/index.md)
- [Artifacts](../../ci/yaml/README.md#artifacts) - [Artifacts](../../ci/yaml/index.md#artifacts)
- [Specific runner](../../ci/runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects) - [Specific runner](../../ci/runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects)
- [Pipelines for merge requests](../../ci/merge_request_pipelines/index.md) - [Pipelines for merge requests](../../ci/merge_request_pipelines/index.md)
......
doc/development/integrations/secure.md
View file @ 0d978174
...@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w ...@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Security scanner integration # Security scanner integration
Integrating a security scanner into GitLab consists of providing end users Integrating a security scanner into GitLab consists of providing end users
with a [CI job definition](../../ci/yaml/README.md) with a [CI job definition](../../ci/yaml/index.md)
they can add to their CI configuration files to scan their GitLab projects. they can add to their CI configuration files to scan their GitLab projects.
This CI job should then output its results in a GitLab-specified format. These results are then This CI job should then output its results in a GitLab-specified format. These results are then
automatically presented in various places in GitLab, such as the Pipeline view, Merge Request automatically presented in various places in GitLab, such as the Pipeline view, Merge Request
...@@ -23,7 +23,7 @@ scanner, as well as requirements and guidelines for the Docker image. ...@@ -23,7 +23,7 @@ scanner, as well as requirements and guidelines for the Docker image.
This section describes several important fields to add to the security scanner's job This section describes several important fields to add to the security scanner's job
definition file. Full documentation on these and other available fields can be viewed definition file. Full documentation on these and other available fields can be viewed
in the [CI documentation](../../ci/yaml/README.md#image). in the [CI documentation](../../ci/yaml/index.md#image).
### Name ### Name
...@@ -34,41 +34,41 @@ For instance, the dependency scanning job based on the "MySec" scanner would be ...@@ -34,41 +34,41 @@ For instance, the dependency scanning job based on the "MySec" scanner would be
### Image ### Image
The [`image`](../../ci/yaml/README.md#image) keyword is used to specify The [`image`](../../ci/yaml/index.md#image) keyword is used to specify
the [Docker image](../../ci/docker/using_docker_images.md#what-is-an-image) the [Docker image](../../ci/docker/using_docker_images.md#what-is-an-image)
containing the security scanner. containing the security scanner.
### Script ### Script
The [`script`](../../ci/yaml/README.md#script) keyword The [`script`](../../ci/yaml/index.md#script) keyword
is used to specify the commands to run the scanner. is used to specify the commands to run the scanner.
Because the `script` entry can't be left empty, it must be set to the command that performs the scan. Because the `script` entry can't be left empty, it must be set to the command that performs the scan.
It is not possible to rely on the predefined `ENTRYPOINT` and `CMD` of the Docker image It is not possible to rely on the predefined `ENTRYPOINT` and `CMD` of the Docker image
to perform the scan automatically, without passing any command. to perform the scan automatically, without passing any command.
The [`before_script`](../../ci/yaml/README.md#before_script) The [`before_script`](../../ci/yaml/index.md#before_script)
should not be used in the job definition because users may rely on this to prepare their projects before performing the scan. should not be used in the job definition because users may rely on this to prepare their projects before performing the scan.
For instance, it is common practice to use `before_script` to install system libraries For instance, it is common practice to use `before_script` to install system libraries
a particular project needs before performing SAST or Dependency Scanning. a particular project needs before performing SAST or Dependency Scanning.
Similarly, [`after_script`](../../ci/yaml/README.md#after_script) Similarly, [`after_script`](../../ci/yaml/index.md#after_script)
should not be used in the job definition, because it may be overridden by users. should not be used in the job definition, because it may be overridden by users.
### Stage ### Stage
For consistency, scanning jobs should belong to the `test` stage when possible. For consistency, scanning jobs should belong to the `test` stage when possible.
The [`stage`](../../ci/yaml/README.md#stage) keyword can be omitted because `test` is the default value. The [`stage`](../../ci/yaml/index.md#stage) keyword can be omitted because `test` is the default value.
### Fail-safe ### Fail-safe
To be aligned with the [GitLab Security paradigm](https://about.gitlab.com/direction/secure/#security-paradigm), To be aligned with the [GitLab Security paradigm](https://about.gitlab.com/direction/secure/#security-paradigm),
scanning jobs should not block the pipeline when they fail, scanning jobs should not block the pipeline when they fail,
so the [`allow_failure`](../../ci/yaml/README.md#allow_failure) parameter should be set to `true`. so the [`allow_failure`](../../ci/yaml/index.md#allow_failure) parameter should be set to `true`.
### Artifacts ### Artifacts
Scanning jobs must declare a report that corresponds to the type of scanning they perform, 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/yaml/index.md#artifactsreports) keyword.
Valid reports are: `dependency_scanning`, `container_scanning`, `dast`, `api_fuzzing`, `coverage_fuzzing`, and `sast`. Valid reports are: `dependency_scanning`, `container_scanning`, `dast`, `api_fuzzing`, `coverage_fuzzing`, and `sast`.
For example, here is the definition of a SAST job that generates a file named `gl-sast-report.json`, For example, here is the definition of a SAST job that generates a file named `gl-sast-report.json`,
...@@ -209,7 +209,7 @@ It is recommended to name the output file after the type of scanning, and to use ...@@ -209,7 +209,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. Since all Secure reports are JSON files, it is recommended to use `.json` as a file extension.
For instance, a suggested filename for a Dependency Scanning report is `gl-dependency-scanning.json`. For instance, a suggested filename for a Dependency Scanning report is `gl-dependency-scanning.json`.
The [`artifacts:reports`](../../ci/yaml/README.md#artifactsreports) keyword The [`artifacts:reports`](../../ci/yaml/index.md#artifactsreports) keyword
of the job definition must be consistent with the file path where the Security report is written. 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, For instance, if a Dependency Scanning analyzer writes its report to the CI project directory,
and if this report filename is `depscan.json`, and if this report filename is `depscan.json`,
......
doc/development/integrations/secure_partner_integration.md
View file @ 0d978174
...@@ -83,7 +83,7 @@ and complete an integration with the Secure stage. ...@@ -83,7 +83,7 @@ and complete an integration with the Secure stage.
1. Ensure your pipeline jobs create a report artifact that GitLab can process 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. to successfully display your own product's results with the rest of GitLab.
- See detailed [technical directions](secure.md) for this step. - 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/yaml/index.md#artifactsreports).
- Read about [job artifacts](../../ci/pipelines/job_artifacts.md). - Read about [job artifacts](../../ci/pipelines/job_artifacts.md).
- Your report artifact must be in one of our currently supported formats. - Your report artifact must be in one of our currently supported formats.
For more information, see the [documentation on reports](secure.md#report). For more information, see the [documentation on reports](secure.md#report).
......
doc/development/pipelines.md
View file @ 0d978174
...@@ -14,12 +14,12 @@ which itself includes files under ...@@ -14,12 +14,12 @@ which itself includes files under
for easier maintenance. for easier maintenance.
We're striving to [dogfood](https://about.gitlab.com/handbook/engineering/#dogfooding) We're striving to [dogfood](https://about.gitlab.com/handbook/engineering/#dogfooding)
GitLab [CI/CD features and best-practices](../ci/yaml/README.md) GitLab [CI/CD features and best-practices](../ci/yaml/index.md)
as much as possible. as much as possible.
## Overview ## Overview
Pipelines for the GitLab project are created using the [`workflow:rules` keyword](../ci/yaml/README.md#workflow) Pipelines for the GitLab project are created using the [`workflow:rules` keyword](../ci/yaml/index.md#workflow)
feature of the GitLab CI/CD. feature of the GitLab CI/CD.
Pipelines are always created for the following scenarios: Pipelines are always created for the following scenarios:
...@@ -49,7 +49,7 @@ depending on the changes made in the MR: ...@@ -49,7 +49,7 @@ depending on the changes made in the MR:
- [Frontend-only MR pipeline](#frontend-only-mr-pipeline): This is typically created for an MR that only changes frontend code. - [Frontend-only MR pipeline](#frontend-only-mr-pipeline): This is typically created for an MR that only changes frontend code.
- [QA-only MR pipeline](#qa-only-mr-pipeline): This is typically created for an MR that only changes end to end tests related code. - [QA-only MR pipeline](#qa-only-mr-pipeline): This is typically created for an MR that only changes end to end tests related code.
We use the [`rules:`](../ci/yaml/README.md#rules) and [`needs:`](../ci/yaml/README.md#needs) keywords extensively We use the [`rules:`](../ci/yaml/index.md#rules) and [`needs:`](../ci/yaml/index.md#needs) keywords extensively
to determine the jobs that need to be run in a pipeline. Note that an MR that includes multiple types of changes would to determine the jobs that need to be run in a pipeline. Note that an MR that includes multiple types of changes would
have a pipelines that include jobs from multiple types (e.g. a combination of docs-only and code-only pipelines). have a pipelines that include jobs from multiple types (e.g. a combination of docs-only and code-only pipelines).
...@@ -537,7 +537,7 @@ the `gitlab-org/gitlab-foss` project. ...@@ -537,7 +537,7 @@ the `gitlab-org/gitlab-foss` project.
### Interruptible pipelines ### Interruptible pipelines
By default, all jobs are [interruptible](../ci/yaml/README.md#interruptible), except the By default, all jobs are [interruptible](../ci/yaml/index.md#interruptible), except the
`dont-interrupt-me` job which runs automatically on `main`, and is `manual` `dont-interrupt-me` job which runs automatically on `main`, and is `manual`
otherwise. otherwise.
...@@ -717,13 +717,13 @@ each pipeline includes default variables defined in ...@@ -717,13 +717,13 @@ each pipeline includes default variables defined in
### Common job definitions ### Common job definitions
Most of the jobs [extend from a few CI definitions](../ci/yaml/README.md#extends) Most of the jobs [extend from a few CI definitions](../ci/yaml/index.md#extends)
defined in [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) defined in [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml)
that are scoped to a single [configuration keyword](../ci/yaml/README.md#job-keywords). that are scoped to a single [configuration keyword](../ci/yaml/index.md#job-keywords).
| Job definitions | Description | | Job definitions | Description |
|------------------|-------------| |------------------|-------------|
| `.default-retry` | Allows a job to [retry](../ci/yaml/README.md#retry) upon `unknown_failure`, `api_failure`, `runner_system_failure`, `job_execution_timeout`, or `stuck_or_timeout_failure`. | | `.default-retry` | Allows a job to [retry](../ci/yaml/index.md#retry) upon `unknown_failure`, `api_failure`, `runner_system_failure`, `job_execution_timeout`, or `stuck_or_timeout_failure`. |
| `.default-before_script` | Allows a job to use a default `before_script` definition suitable for Ruby/Rails tasks that may need a database running (e.g. tests). | | `.default-before_script` | Allows a job to use a default `before_script` definition suitable for Ruby/Rails tasks that may need a database running (e.g. tests). |
| `.setup-test-env-cache` | Allows a job to use a default `cache` definition suitable for setting up test environment for subsequent Ruby/Rails tasks. | | `.setup-test-env-cache` | Allows a job to use a default `cache` definition suitable for setting up test environment for subsequent Ruby/Rails tasks. |
| `.rails-cache` | Allows a job to use a default `cache` definition suitable for Ruby/Rails tasks. | | `.rails-cache` | Allows a job to use a default `cache` definition suitable for Ruby/Rails tasks. |
...@@ -742,16 +742,16 @@ that are scoped to a single [configuration keyword](../ci/yaml/README.md#job-key ...@@ -742,16 +742,16 @@ that are scoped to a single [configuration keyword](../ci/yaml/README.md#job-key
### `rules`, `if:` conditions and `changes:` patterns ### `rules`, `if:` conditions and `changes:` patterns
We're using the [`rules` keyword](../ci/yaml/README.md#rules) extensively. We're using the [`rules` keyword](../ci/yaml/index.md#rules) extensively.
All `rules` definitions are defined in All `rules` definitions are defined in
[`rules.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/rules.gitlab-ci.yml), [`rules.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/rules.gitlab-ci.yml),
then included in individual jobs via [`extends`](../ci/yaml/README.md#extends). then included in individual jobs via [`extends`](../ci/yaml/index.md#extends).
The `rules` definitions are composed of `if:` conditions and `changes:` patterns, The `rules` definitions are composed of `if:` conditions and `changes:` patterns,
which are also defined in which are also defined in
[`rules.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/rules.gitlab-ci.yml) [`rules.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/rules.gitlab-ci.yml)
and included in `rules` definitions via [YAML anchors](../ci/yaml/README.md#anchors) and included in `rules` definitions via [YAML anchors](../ci/yaml/index.md#anchors)
#### `if:` conditions #### `if:` conditions
......
doc/index.md
View file @ 0d978174
...@@ -40,7 +40,7 @@ Have a look at some of our most popular topics: ...@@ -40,7 +40,7 @@ Have a look at some of our most popular topics:
|:-------------------------------------------------------------------------------------------|:------------| |:-------------------------------------------------------------------------------------------|:------------|
| [Two-factor authentication](user/profile/account/two_factor_authentication.md) | Improve the security of your GitLab account. | | [Two-factor authentication](user/profile/account/two_factor_authentication.md) | Improve the security of your GitLab account. |
| [GitLab groups](user/group/index.md) | Manage projects together. | | [GitLab groups](user/group/index.md) | Manage projects together. |
| [GitLab CI/CD pipeline configuration reference](ci/yaml/README.md) | Available configuration options for `.gitlab-ci.yml` files. | | [GitLab CI/CD pipeline configuration reference](ci/yaml/index.md) | Available configuration options for `.gitlab-ci.yml` files. |
| [Activate GitLab EE with a license](user/admin_area/license.md) | Activate GitLab Enterprise Edition functionality with a license. | | [Activate GitLab EE with a license](user/admin_area/license.md) | Activate GitLab Enterprise Edition functionality with a license. |
| [Back up and restore GitLab](raketasks/backup_restore.md) | Rake tasks for backing up and restoring GitLab self-managed instances. | | [Back up and restore GitLab](raketasks/backup_restore.md) | Rake tasks for backing up and restoring GitLab self-managed instances. |
| [GitLab release and maintenance policy](policy/maintenance.md) | Policies for version naming and cadence, and also upgrade recommendations. | | [GitLab release and maintenance policy](policy/maintenance.md) | Policies for version naming and cadence, and also upgrade recommendations. |
......
doc/topics/autodevops/customize.md
View file @ 0d978174
...@@ -187,11 +187,11 @@ to the desired environment. See [Limit environment scope of CI/CD variables](../ ...@@ -187,11 +187,11 @@ to the desired environment. See [Limit environment scope of CI/CD variables](../
Auto DevOps is completely customizable because the Auto DevOps is completely customizable because the
[Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
is just an implementation of a [`.gitlab-ci.yml`](../../ci/yaml/README.md) file, is just an implementation of a [`.gitlab-ci.yml`](../../ci/yaml/index.md) file,
and uses only features available to any implementation of `.gitlab-ci.yml`. and uses only features available to any implementation of `.gitlab-ci.yml`.
To modify the CI/CD pipeline used by Auto DevOps, To modify the CI/CD pipeline used by Auto DevOps,
[`include` the template](../../ci/yaml/README.md#includetemplate), and customize [`include` the template](../../ci/yaml/index.md#includetemplate), and customize
it as needed by adding a `.gitlab-ci.yml` file to the root of your repository it as needed by adding a `.gitlab-ci.yml` file to the root of your repository
containing the following: containing the following:
...@@ -202,7 +202,7 @@ include: ...@@ -202,7 +202,7 @@ include:
Add your changes, and your additions are merged with the Add your changes, and your additions are merged with the
[Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
using the behavior described for [`include`](../../ci/yaml/README.md#include). using the behavior described for [`include`](../../ci/yaml/index.md#include).
If you need to specifically remove a part of the file, you can also copy and paste the contents of the If you need to specifically remove a part of the file, you can also copy and paste the contents of the
[Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
...@@ -254,13 +254,13 @@ include: ...@@ -254,13 +254,13 @@ include:
See the [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) for information on available jobs. See the [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) for information on available jobs.
WARNING: WARNING:
Auto DevOps templates using the [`only`](../../ci/yaml/README.md#only--except) or Auto DevOps templates using the [`only`](../../ci/yaml/index.md#only--except) or
[`except`](../../ci/yaml/README.md#only--except) syntax have switched [`except`](../../ci/yaml/index.md#only--except) syntax have switched
to the [`rules`](../../ci/yaml/README.md#rules) syntax, starting in to the [`rules`](../../ci/yaml/index.md#rules) syntax, starting in
[GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/213336). [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/213336).
If your `.gitlab-ci.yml` extends these Auto DevOps templates and override the `only` or If your `.gitlab-ci.yml` extends these Auto DevOps templates and override the `only` or
`except` keywords, you must migrate your templates to use the `except` keywords, you must migrate your templates to use the
[`rules`](../../ci/yaml/README.md#rules) syntax after the [`rules`](../../ci/yaml/index.md#rules) syntax after the
base template is migrated to use the `rules` syntax. base template is migrated to use the `rules` syntax.
For users who cannot migrate just yet, you can alternatively pin your templates to For users who cannot migrate just yet, you can alternatively pin your templates to
the [GitLab 12.10 based templates](https://gitlab.com/gitlab-org/auto-devops-v12-10). the [GitLab 12.10 based templates](https://gitlab.com/gitlab-org/auto-devops-v12-10).
......
doc/topics/autodevops/index.md
View file @ 0d978174
...@@ -63,7 +63,7 @@ Since [GitLab 12.7](https://gitlab.com/gitlab-org/gitlab/-/issues/26655), ...@@ -63,7 +63,7 @@ Since [GitLab 12.7](https://gitlab.com/gitlab-org/gitlab/-/issues/26655),
Auto DevOps runs on pipelines automatically only if a [`Dockerfile` or matching buildpack](stages.md#auto-build) Auto DevOps runs on pipelines automatically only if a [`Dockerfile` or matching buildpack](stages.md#auto-build)
exists. exists.
If a [CI/CD configuration file](../../ci/yaml/README.md) is present in the If a [CI/CD configuration file](../../ci/yaml/index.md) is present in the
project, it isn't changed and won't be affected by Auto DevOps. project, it isn't changed and won't be affected by Auto DevOps.
### At the project level ### At the project level
......
doc/topics/autodevops/requirements.md
View file @ 0d978174
...@@ -125,7 +125,7 @@ only the deployment to Kubernetes runs. ...@@ -125,7 +125,7 @@ only the deployment to Kubernetes runs.
WARNING: WARNING:
Setting the `AUTO_DEVOPS_PLATFORM_TARGET` variable to `ECS` triggers jobs Setting the `AUTO_DEVOPS_PLATFORM_TARGET` variable to `ECS` triggers jobs
defined in the [`Jobs/Deploy/ECS.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy/ECS.gitlab-ci.yml). defined in the [`Jobs/Deploy/ECS.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy/ECS.gitlab-ci.yml).
However, it's not recommended to [include](../../ci/yaml/README.md#includetemplate) However, it's not recommended to [include](../../ci/yaml/index.md#includetemplate)
it on its own. This template is designed to be used with Auto DevOps only. It may change it on its own. This template is designed to be used with Auto DevOps only. It may change
unexpectedly causing your pipeline to fail if included on its own. Also, the job unexpectedly causing your pipeline to fail if included on its own. Also, the job
names within this template may also change. Do not override these jobs' names in your names within this template may also change. Do not override these jobs' names in your
......
doc/topics/autodevops/upgrading_auto_deploy_dependencies.md
View file @ 0d978174
...@@ -31,11 +31,11 @@ are using. First verify which template is in use: ...@@ -31,11 +31,11 @@ are using. First verify which template is in use:
- [The GitLab.com stable Auto Deploy template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml) - [The GitLab.com stable Auto Deploy template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml)
is being used if **one** of the following is true: is being used if **one** of the following is true:
- Your Auto DevOps project doesn't have a `.gitlab-ci.yml` file. - Your Auto DevOps project doesn't have a `.gitlab-ci.yml` file.
- Your Auto DevOps project has a `.gitlab-ci.yml` and [includes](../../ci/yaml/README.md#includetemplate) - Your Auto DevOps project has a `.gitlab-ci.yml` and [includes](../../ci/yaml/index.md#includetemplate)
the `Auto-DevOps.gitlab-ci.yml` template. the `Auto-DevOps.gitlab-ci.yml` template.
- [The latest Auto Deploy template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.latest.gitlab-ci.yml) - [The latest Auto Deploy template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.latest.gitlab-ci.yml)
is being used if **both** of the following is true: is being used if **both** of the following is true:
- Your Auto DevOps project has a `.gitlab-ci.yml` file and [includes](../../ci/yaml/README.md#includetemplate) - Your Auto DevOps project has a `.gitlab-ci.yml` file and [includes](../../ci/yaml/index.md#includetemplate)
the `Auto-DevOps.gitlab-ci.yml` template. the `Auto-DevOps.gitlab-ci.yml` template.
- It also includes [the latest Auto Deploy template](#early-adopters) - It also includes [the latest Auto Deploy template](#early-adopters)
......
doc/user/admin_area/settings/continuous_integration.md
View file @ 0d978174
...@@ -88,7 +88,7 @@ The setting at all levels is only available to GitLab administrators. ...@@ -88,7 +88,7 @@ The setting at all levels is only available to GitLab administrators.
The default expiration time of the [job artifacts](../../../administration/job_artifacts.md) The default expiration time of the [job artifacts](../../../administration/job_artifacts.md)
can be set in the Admin Area of your GitLab instance. The syntax of duration is can be set in the Admin Area of your GitLab instance. The syntax of duration is
described in [`artifacts:expire_in`](../../../ci/yaml/README.md#artifactsexpire_in) described in [`artifacts:expire_in`](../../../ci/yaml/index.md#artifactsexpire_in)
and the default value is `30 days`. and the default value is `30 days`.
1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the top bar, select **Menu >** **{admin}** **Admin**.
...@@ -97,7 +97,7 @@ and the default value is `30 days`. ...@@ -97,7 +97,7 @@ and the default value is `30 days`.
1. Click **Save changes** for the changes to take effect. 1. Click **Save changes** for the changes to take effect.
This setting is set per job and can be overridden in This setting is set per job and can be overridden in
[`.gitlab-ci.yml`](../../../ci/yaml/README.md#artifactsexpire_in). [`.gitlab-ci.yml`](../../../ci/yaml/index.md#artifactsexpire_in).
To disable the expiration, set it to `0`. The default unit is in seconds. To disable the expiration, set it to `0`. The default unit is in seconds.
NOTE: NOTE:
...@@ -233,13 +233,13 @@ use a template from: ...@@ -233,13 +233,13 @@ use a template from:
NOTE: NOTE:
When you use a configuration defined in an instance template repository, When you use a configuration defined in an instance template repository,
nested [`include:`](../../../ci/yaml/README.md#include) keywords nested [`include:`](../../../ci/yaml/index.md#include) keywords
(including `include:file`, `include:local`, `include:remote`, and `include:template`) (including `include:file`, `include:local`, `include:remote`, and `include:template`)
[do not work](https://gitlab.com/gitlab-org/gitlab/-/issues/35345). [do not work](https://gitlab.com/gitlab-org/gitlab/-/issues/35345).
The project CI/CD configuration merges into the required pipeline configuration when The project CI/CD configuration merges into the required pipeline configuration when
a pipeline runs. The merged configuration is the same as if the required pipeline configuration a pipeline runs. The merged configuration is the same as if the required pipeline configuration
added the project configuration with the [`include` keyword](../../../ci/yaml/README.md#include). added the project configuration with the [`include` keyword](../../../ci/yaml/index.md#include).
To view a project's full merged configuration, [View the merged YAML](../../../ci/pipeline_editor/index.md#view-expanded-configuration) To view a project's full merged configuration, [View the merged YAML](../../../ci/pipeline_editor/index.md#view-expanded-configuration)
in the pipeline editor. in the pipeline editor.
......
doc/user/admin_area/settings/index.md
View file @ 0d978174
...@@ -68,7 +68,7 @@ To access the default page for Admin Area settings: ...@@ -68,7 +68,7 @@ To access the default page for Admin Area settings:
| Option | Description | | Option | Description |
| ------ | ----------- | | ------ | ----------- |
| [Continuous Integration and Deployment](continuous_integration.md) | Auto DevOps, runners and job artifacts. | | [Continuous Integration and Deployment](continuous_integration.md) | Auto DevOps, runners and job artifacts. |
| [Required pipeline configuration](continuous_integration.md#required-pipeline-configuration) **(PREMIUM SELF)** | Set an instance-wide auto included [pipeline configuration](../../../ci/yaml/README.md). This pipeline configuration is run after the project's own configuration. | | [Required pipeline configuration](continuous_integration.md#required-pipeline-configuration) **(PREMIUM SELF)** | Set an instance-wide auto included [pipeline configuration](../../../ci/yaml/index.md). This pipeline configuration is run after the project's own configuration. |
| [Package Registry](continuous_integration.md#package-registry-configuration) | Settings related to the use and experience of using the GitLab Package Registry. Note there are [risks involved](../../packages/container_registry/index.md#use-with-external-container-registries) in enabling some of these settings. | | [Package Registry](continuous_integration.md#package-registry-configuration) | Settings related to the use and experience of using the GitLab Package Registry. Note there are [risks involved](../../packages/container_registry/index.md#use-with-external-container-registries) in enabling some of these settings. |
## Reporting ## Reporting
......
doc/user/analytics/value_stream_analytics.md
View file @ 0d978174
...@@ -112,7 +112,7 @@ environments is configured. ...@@ -112,7 +112,7 @@ environments is configured.
1. Push branch, and create a merge request that contains the [issue closing pattern](../project/issues/managing_issues.md#closing-issues-automatically) 1. Push branch, and create a merge request that contains the [issue closing pattern](../project/issues/managing_issues.md#closing-issues-automatically)
in its description at 14:00 (stop of **Code** stage and start of **Test** and in its description at 14:00 (stop of **Code** stage and start of **Test** and
**Review** stages). **Review** stages).
1. The CI starts running your scripts defined in [`.gitlab-ci.yml`](../../ci/yaml/README.md) and 1. The CI starts running your scripts defined in [`.gitlab-ci.yml`](../../ci/yaml/index.md) and
takes 5 minutes (stop of **Test** stage). takes 5 minutes (stop of **Test** stage).
1. Review merge request, ensure that everything is okay, and then merge the merge 1. Review merge request, ensure that everything is okay, and then merge the merge
request at 19:00 (stop of **Review** stage and start of **Staging** stage). request at 19:00 (stop of **Review** stage and start of **Staging** stage).
......
doc/user/application_security/api_fuzzing/index.md
View file @ 0d978174
...@@ -134,7 +134,7 @@ To configure API fuzzing in GitLab with an OpenAPI Specification: ...@@ -134,7 +134,7 @@ To configure API fuzzing in GitLab with an OpenAPI Specification:
1. Add the `fuzz` stage to your `.gitlab-ci.yml` file. 1. Add the `fuzz` stage to your `.gitlab-ci.yml` file.
1. [Include](../../../ci/yaml/README.md#includetemplate) 1. [Include](../../../ci/yaml/index.md#includetemplate)
the [`API-Fuzzing.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/API-Fuzzing.gitlab-ci.yml) the [`API-Fuzzing.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/API-Fuzzing.gitlab-ci.yml)
in your `.gitlab-ci.yml` file. in your `.gitlab-ci.yml` file.
...@@ -200,7 +200,7 @@ To configure API fuzzing to use a HAR file: ...@@ -200,7 +200,7 @@ To configure API fuzzing to use a HAR file:
1. Add the `fuzz` stage to your `.gitlab-ci.yml` file. 1. Add the `fuzz` stage to your `.gitlab-ci.yml` file.
1. [Include](../../../ci/yaml/README.md#includetemplate) 1. [Include](../../../ci/yaml/index.md#includetemplate)
the [`API-Fuzzing.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/API-Fuzzing.gitlab-ci.yml) the [`API-Fuzzing.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/API-Fuzzing.gitlab-ci.yml)
in your `.gitlab-ci.yml` file. in your `.gitlab-ci.yml` file.
...@@ -271,7 +271,7 @@ To configure API fuzzing to use a Postman Collection file: ...@@ -271,7 +271,7 @@ To configure API fuzzing to use a Postman Collection file:
1. Add the `fuzz` stage to your `.gitlab-ci.yml` file. 1. Add the `fuzz` stage to your `.gitlab-ci.yml` file.
1. [Include](../../../ci/yaml/README.md#includetemplate) 1. [Include](../../../ci/yaml/index.md#includetemplate)
the [`API-Fuzzing.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/API-Fuzzing.gitlab-ci.yml) the [`API-Fuzzing.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/API-Fuzzing.gitlab-ci.yml)
in your `.gitlab-ci.yml` file. in your `.gitlab-ci.yml` file.
......
doc/user/application_security/container_scanning/index.md
View file @ 0d978174
...@@ -59,7 +59,7 @@ To enable container scanning in your pipeline, you need the following: ...@@ -59,7 +59,7 @@ To enable container scanning in your pipeline, you need the following:
How you enable container scanning depends on your GitLab version: How you enable container scanning depends on your GitLab version:
- GitLab 11.9 and later: [Include](../../../ci/yaml/README.md#includetemplate) the - GitLab 11.9 and later: [Include](../../../ci/yaml/index.md#includetemplate) the
[`Container-Scanning.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml) [`Container-Scanning.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml)
that comes with your GitLab installation. that comes with your GitLab installation.
- GitLab versions earlier than 11.9: Copy and use the job from the - GitLab versions earlier than 11.9: Copy and use the job from the
...@@ -73,8 +73,8 @@ Other changes: ...@@ -73,8 +73,8 @@ Other changes:
[`centos:centos8`](https://hub.docker.com/_/centos) [`centos:centos8`](https://hub.docker.com/_/centos)
as the new base. It also removes the use of the [start.sh](https://gitlab.com/gitlab-org/security-products/analyzers/klar/-/merge_requests/77) as the new base. It also removes the use of the [start.sh](https://gitlab.com/gitlab-org/security-products/analyzers/klar/-/merge_requests/77)
script and instead executes the analyzer by default. Any customizations made to the script and instead executes the analyzer by default. Any customizations made to the
`container_scanning` job's [`before_script`](../../../ci/yaml/README.md#before_script) `container_scanning` job's [`before_script`](../../../ci/yaml/index.md#before_script)
and [`after_script`](../../../ci/yaml/README.md#after_script) and [`after_script`](../../../ci/yaml/index.md#after_script)
blocks may not work with the new version. To roll back to the previous [`alpine:3.11.3`](https://hub.docker.com/_/alpine)-based blocks may not work with the new version. To roll back to the previous [`alpine:3.11.3`](https://hub.docker.com/_/alpine)-based
Docker image, you can specify the major version through the [`CS_MAJOR_VERSION`](#available-cicd-variables) Docker image, you can specify the major version through the [`CS_MAJOR_VERSION`](#available-cicd-variables)
variable. variable.
...@@ -101,7 +101,7 @@ The included template: ...@@ -101,7 +101,7 @@ The included template:
(see [requirements](#requirements)) and scans it for possible vulnerabilities. (see [requirements](#requirements)) and scans it for possible vulnerabilities.
GitLab saves the results as a GitLab saves the results as a
[Container Scanning report artifact](../../../ci/yaml/README.md#artifactsreportscontainer_scanning) [Container Scanning report artifact](../../../ci/yaml/index.md#artifactsreportscontainer_scanning)
that you can download and analyze later. When downloading, you always receive the most-recent that you can download and analyze later. When downloading, you always receive the most-recent
artifact. artifact.
...@@ -130,12 +130,12 @@ include: ...@@ -130,12 +130,12 @@ include:
There may be cases where you want to customize how GitLab scans your containers. For example, you There may be cases where you want to customize how GitLab scans your containers. For example, you
may want to enable more verbose output, access a Docker registry that requires may want to enable more verbose output, access a Docker registry that requires
authentication, and more. To change such settings, use the [`variables`](../../../ci/yaml/README.md#variables) authentication, and more. To change such settings, use the [`variables`](../../../ci/yaml/index.md#variables)
parameter in your `.gitlab-ci.yml` to set [CI/CD variables](#available-cicd-variables). parameter in your `.gitlab-ci.yml` to set [CI/CD variables](#available-cicd-variables).
The variables you set in your `.gitlab-ci.yml` overwrite those in The variables you set in your `.gitlab-ci.yml` overwrite those in
`Container-Scanning.gitlab-ci.yml`. `Container-Scanning.gitlab-ci.yml`.
This example [includes](../../../ci/yaml/README.md#include) the container scanning template and This example [includes](../../../ci/yaml/index.md#include) the container scanning template and
enables verbose output for the analyzer: enables verbose output for the analyzer:
```yaml ```yaml
...@@ -190,8 +190,8 @@ container_scanning: ...@@ -190,8 +190,8 @@ container_scanning:
``` ```
WARNING: WARNING:
GitLab 13.0 and later doesn't support [`only` and `except`](../../../ci/yaml/README.md#only--except). GitLab 13.0 and later doesn't support [`only` and `except`](../../../ci/yaml/index.md#only--except).
When overriding the template, you must use [`rules`](../../../ci/yaml/README.md#rules) When overriding the template, you must use [`rules`](../../../ci/yaml/index.md#rules)
instead. instead.
### Change scanners ### Change scanners
......
doc/user/application_security/coverage_fuzzing/index.md
View file @ 0d978174
...@@ -38,7 +38,7 @@ Docker image with the fuzz engine to run your app. ...@@ -38,7 +38,7 @@ Docker image with the fuzz engine to run your app.
## Configuration ## Configuration
To enable fuzzing, you must To enable fuzzing, you must
[include](../../../ci/yaml/README.md#includetemplate) [include](../../../ci/yaml/index.md#includetemplate)
the [`Coverage-Fuzzing.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/Coverage-Fuzzing.gitlab-ci.yml) the [`Coverage-Fuzzing.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/Coverage-Fuzzing.gitlab-ci.yml)
provided as part of your GitLab installation. provided as part of your GitLab installation.
...@@ -59,8 +59,8 @@ my_fuzz_target: ...@@ -59,8 +59,8 @@ my_fuzz_target:
- ./gitlab-cov-fuzz run --regression=$REGRESSION -- <your fuzz target> - ./gitlab-cov-fuzz run --regression=$REGRESSION -- <your fuzz target>
``` ```
The included template makes available the [hidden job](../../../ci/yaml/README.md#hide-jobs) The included template makes available the [hidden job](../../../ci/yaml/index.md#hide-jobs)
`.fuzz_base`, which you must [extend](../../../ci/yaml/README.md#extends) for each of your fuzz `.fuzz_base`, which you must [extend](../../../ci/yaml/index.md#extends) for each of your fuzz
targets. Each fuzz target **must** have a separate job. For example, the targets. Each fuzz target **must** have a separate job. For example, the
[go-fuzzing-example project](https://gitlab.com/gitlab-org/security-products/demos/go-fuzzing-example) [go-fuzzing-example project](https://gitlab.com/gitlab-org/security-products/demos/go-fuzzing-example)
contains one job that extends `.fuzz_base` for its single fuzz target. contains one job that extends `.fuzz_base` for its single fuzz target.
......
doc/user/application_security/dast/index.md
View file @ 0d978174
...@@ -202,7 +202,7 @@ To include the DAST template: ...@@ -202,7 +202,7 @@ To include the DAST template:
1. Add the template to GitLab, based on your version of GitLab: 1. Add the template to GitLab, based on your version of GitLab:
- In GitLab 11.9 and later, [include](../../../ci/yaml/README.md#includetemplate) - In GitLab 11.9 and later, [include](../../../ci/yaml/index.md#includetemplate)
the template by adding the following to your `.gitlab-ci.yml` file: the template by adding the following to your `.gitlab-ci.yml` file:
```yaml ```yaml
...@@ -218,7 +218,7 @@ To include the DAST template: ...@@ -218,7 +218,7 @@ To include the DAST template:
1. Define the URL to be scanned by DAST by using one of these methods: 1. Define the URL to be scanned by DAST by using one of these methods:
- Set the `DAST_WEBSITE` [CI/CD variable](../../../ci/yaml/README.md#variables). - Set the `DAST_WEBSITE` [CI/CD variable](../../../ci/yaml/index.md#variables).
If set, this value takes precedence. If set, this value takes precedence.
- Add the URL in an `environment_url.txt` file at the root of your project. This is - Add the URL in an `environment_url.txt` file at the root of your project. This is
...@@ -247,7 +247,7 @@ The included template creates a `dast` job in your CI/CD pipeline and scans ...@@ -247,7 +247,7 @@ The included template creates a `dast` job in your CI/CD pipeline and scans
your project's running application for possible vulnerabilities. your project's running application for possible vulnerabilities.
The results are saved as a The results are saved as a
[DAST report artifact](../../../ci/yaml/README.md#artifactsreportsdast) [DAST report artifact](../../../ci/yaml/index.md#artifactsreportsdast)
that you can later download and analyze. Due to implementation limitations, we that you can later download and analyze. Due to implementation limitations, we
always take the latest DAST artifact available. Behind the scenes, the always take the latest DAST artifact available. Behind the scenes, the
[GitLab DAST Docker image](https://gitlab.com/gitlab-org/security-products/dast) [GitLab DAST Docker image](https://gitlab.com/gitlab-org/security-products/dast)
...@@ -487,11 +487,11 @@ To view details of vulnerabilities detected by DAST: ...@@ -487,11 +487,11 @@ To view details of vulnerabilities detected by DAST:
### Customizing the DAST settings ### Customizing the DAST settings
WARNING: WARNING:
Beginning in GitLab 13.0, the use of [`only` and `except`](../../../ci/yaml/README.md#only--except) Beginning in GitLab 13.0, the use of [`only` and `except`](../../../ci/yaml/index.md#only--except)
is no longer supported. When overriding the template, you must use [`rules`](../../../ci/yaml/README.md#rules) instead. is no longer supported. When overriding the template, you must use [`rules`](../../../ci/yaml/index.md#rules) instead.
The DAST settings can be changed through CI/CD variables by using the The DAST settings can be changed through CI/CD variables by using the
[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`. [`variables`](../../../ci/yaml/index.md#variables) parameter in `.gitlab-ci.yml`.
These variables are documented in [available variables](#available-cicd-variables). These variables are documented in [available variables](#available-cicd-variables).
For example: For example:
...@@ -505,7 +505,7 @@ variables: ...@@ -505,7 +505,7 @@ variables:
DAST_SPIDER_MINS: 120 DAST_SPIDER_MINS: 120
``` ```
Because the template is [evaluated before](../../../ci/yaml/README.md#include) the pipeline Because the template is [evaluated before](../../../ci/yaml/index.md#include) the pipeline
configuration, the last mention of the variable takes precedence. configuration, the last mention of the variable takes precedence.
#### Enabling and disabling rules #### Enabling and disabling rules
......
doc/user/application_security/dast_api/index.md
View file @ 0d978174
...@@ -85,7 +85,7 @@ the body generation is limited to these body types: ...@@ -85,7 +85,7 @@ the body generation is limited to these body types:
Follow these steps to configure DAST API in GitLab with an OpenAPI specification: Follow these steps to configure DAST API in GitLab with an OpenAPI specification:
1. To use DAST API, you must [include](../../../ci/yaml/README.md#includetemplate) 1. To use DAST API, you must [include](../../../ci/yaml/index.md#includetemplate)
the [`DAST-API.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/DAST-API.gitlab-ci.yml) the [`DAST-API.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/DAST-API.gitlab-ci.yml)
that's provided as part of your GitLab installation. Add the following to your that's provided as part of your GitLab installation. Add the following to your
`.gitlab-ci.yml` file: `.gitlab-ci.yml` file:
...@@ -184,7 +184,7 @@ cookies. We recommend that you review the HAR file contents before adding them t ...@@ -184,7 +184,7 @@ cookies. We recommend that you review the HAR file contents before adding them t
Follow these steps to configure DAST API to use a HAR file that provides information about the Follow these steps to configure DAST API to use a HAR file that provides information about the
target API to test: target API to test:
1. To use DAST API, you must [include](../../../ci/yaml/README.md#includetemplate) 1. To use DAST API, you must [include](../../../ci/yaml/index.md#includetemplate)
the [`DAST-API.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/DAST-API.gitlab-ci.yml) the [`DAST-API.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/DAST-API.gitlab-ci.yml)
that's provided as part of your GitLab installation. To do so, add the following to your that's provided as part of your GitLab installation. To do so, add the following to your
`.gitlab-ci.yml` file: `.gitlab-ci.yml` file:
...@@ -284,7 +284,7 @@ them to a repository. ...@@ -284,7 +284,7 @@ them to a repository.
Follow these steps to configure DAST API to use a Postman Collection file that provides Follow these steps to configure DAST API to use a Postman Collection file that provides
information about the target API to test: information about the target API to test:
1. To use DAST API, you must [include](../../../ci/yaml/README.md#includetemplate) 1. To use DAST API, you must [include](../../../ci/yaml/index.md#includetemplate)
the [`DAST-API.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/DAST-API.gitlab-ci.yml) the [`DAST-API.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/DAST-API.gitlab-ci.yml)
that's provided as part of your GitLab installation. To do so, add the following to your that's provided as part of your GitLab installation. To do so, add the following to your
`.gitlab-ci.yml` file: `.gitlab-ci.yml` file:
......
doc/user/application_security/dependency_scanning/index.md
View file @ 0d978174
...@@ -55,7 +55,7 @@ is **not** `19.03.0`. See [troubleshooting information](#error-response-from-dae ...@@ -55,7 +55,7 @@ is **not** `19.03.0`. See [troubleshooting information](#error-response-from-dae
## Supported languages and package managers ## Supported languages and package managers
GitLab relies on [`rules`](../../../ci/yaml/README.md#rules) to start relevant analyzers depending on the languages detected in the repository. GitLab relies on [`rules`](../../../ci/yaml/index.md#rules) to start relevant analyzers depending on the languages detected in the repository.
The current detection logic limits the maximum search depth to two levels. For example, the `gemnasium-dependency_scanning` job is enabled if a repository contains either a `Gemfile` or `api/Gemfile` file, but not if the only supported dependency file is `api/client/Gemfile`. The current detection logic limits the maximum search depth to two levels. For example, the `gemnasium-dependency_scanning` job is enabled if a repository contains either a `Gemfile` or `api/Gemfile` file, but not if the only supported dependency file is `api/client/Gemfile`.
The following languages and dependency managers are supported: The following languages and dependency managers are supported:
...@@ -90,7 +90,7 @@ The [Security Scanner Integration](../../../development/integrations/secure.md) ...@@ -90,7 +90,7 @@ The [Security Scanner Integration](../../../development/integrations/secure.md)
## Configuration ## Configuration
To enable dependency scanning for GitLab 11.9 and later, you must To enable dependency scanning for GitLab 11.9 and later, you must
[include](../../../ci/yaml/README.md#includetemplate) the [include](../../../ci/yaml/index.md#includetemplate) the
[`Dependency-Scanning.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/Dependency-Scanning.gitlab-ci.yml) [`Dependency-Scanning.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/Dependency-Scanning.gitlab-ci.yml)
that is provided as a part of your GitLab installation. that is provided as a part of your GitLab installation.
For GitLab versions earlier than 11.9, you can copy and use the job as defined For GitLab versions earlier than 11.9, you can copy and use the job as defined
...@@ -106,14 +106,14 @@ include: ...@@ -106,14 +106,14 @@ include:
The included template creates dependency scanning jobs in your CI/CD The included template creates dependency scanning jobs in your CI/CD
pipeline and scans your project's source code for possible vulnerabilities. pipeline and scans your project's source code for possible vulnerabilities.
The results are saved as a The results are saved as a
[dependency scanning report artifact](../../../ci/yaml/README.md#artifactsreportsdependency_scanning) [dependency scanning report artifact](../../../ci/yaml/index.md#artifactsreportsdependency_scanning)
that you can later download and analyze. Due to implementation limitations, we that you can later download and analyze. Due to implementation limitations, we
always take the latest dependency scanning artifact available. always take the latest dependency scanning artifact available.
### Customizing the dependency scanning settings ### Customizing the dependency scanning settings
The dependency scanning settings can be changed through [CI/CD variables](#available-cicd-variables) by using the The dependency scanning settings can be changed through [CI/CD variables](#available-cicd-variables) by using the
[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`. [`variables`](../../../ci/yaml/index.md#variables) parameter in `.gitlab-ci.yml`.
For example: For example:
```yaml ```yaml
...@@ -124,14 +124,14 @@ variables: ...@@ -124,14 +124,14 @@ variables:
SECURE_LOG_LEVEL: error SECURE_LOG_LEVEL: error
``` ```
Because template is [evaluated before](../../../ci/yaml/README.md#include) the pipeline Because template is [evaluated before](../../../ci/yaml/index.md#include) the pipeline
configuration, the last mention of the variable takes precedence. configuration, the last mention of the variable takes precedence.
### Overriding dependency scanning jobs ### Overriding dependency scanning jobs
WARNING: WARNING:
Beginning in GitLab 13.0, the use of [`only` and `except`](../../../ci/yaml/README.md#only--except) Beginning in GitLab 13.0, the use of [`only` and `except`](../../../ci/yaml/index.md#only--except)
is no longer supported. When overriding the template, you must use [`rules`](../../../ci/yaml/README.md#rules) instead. is no longer supported. When overriding the template, you must use [`rules`](../../../ci/yaml/index.md#rules) instead.
To override a job definition (for example, to change properties like `variables` or `dependencies`), To override a job definition (for example, to change properties like `variables` or `dependencies`),
declare a new job with the same name as the one to override. Place this new job after the template declare a new job with the same name as the one to override. Place this new job after the template
...@@ -596,7 +596,7 @@ Generally, the approach is the following: ...@@ -596,7 +596,7 @@ Generally, the approach is the following:
1. Define a dedicated converter job in your `.gitlab-ci.yml` file. 1. Define a dedicated converter job in your `.gitlab-ci.yml` file.
Use a suitable Docker image, script, or both to facilitate the conversion. Use a suitable Docker image, script, or both to facilitate the conversion.
1. Let that job upload the converted, supported file as an artifact. 1. Let that job upload the converted, supported file as an artifact.
1. Add [`dependencies: [<your-converter-job>]`](../../../ci/yaml/README.md#dependencies) 1. Add [`dependencies: [<your-converter-job>]`](../../../ci/yaml/index.md#dependencies)
to your `dependency_scanning` job to make use of the converted definitions files. to your `dependency_scanning` job to make use of the converted definitions files.
For example, the currently unsupported `poetry.lock` file can be For example, the currently unsupported `poetry.lock` file can be
...@@ -643,7 +643,7 @@ For information on this, see the [general Application Security troubleshooting s ...@@ -643,7 +643,7 @@ For information on this, see the [general Application Security troubleshooting s
### Limitation when using rules:exists ### Limitation when using rules:exists
The [dependency scanning CI template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/Dependency-Scanning.gitlab-ci.yml) The [dependency scanning CI template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/Dependency-Scanning.gitlab-ci.yml)
uses the [`rules:exists`](../../../ci/yaml/README.md#rulesexists) uses the [`rules:exists`](../../../ci/yaml/index.md#rulesexists)
syntax. This directive is limited to 10000 checks and always returns `true` after reaching this syntax. This directive is limited to 10000 checks and always returns `true` after reaching this
number. Because of this, and depending on the number of files in your repository, a dependency number. Because of this, and depending on the number of files in your repository, a dependency
scanning job might be triggered even if the scanner doesn't support your project. scanning job might be triggered even if the scanner doesn't support your project.
......
doc/user/application_security/index.md
View file @ 0d978174
...@@ -129,7 +129,7 @@ All jobs are permitted to fail by default. This means that if they fail it do no ...@@ -129,7 +129,7 @@ All jobs are permitted to fail by default. This means that if they fail it do no
If you want to prevent vulnerabilities from being merged, you should do this by adding [Security Approvals in Merge Requests](#security-approvals-in-merge-requests) which prevents unknown, high or critical findings from being merged without an approval from a specific group of people that you choose. If you want to prevent vulnerabilities from being merged, you should do this by adding [Security Approvals in Merge Requests](#security-approvals-in-merge-requests) which prevents unknown, high or critical findings from being merged without an approval from a specific group of people that you choose.
We do not recommend changing the job [`allow_failure` setting](../../ci/yaml/README.md#allow_failure) as that fails the entire pipeline. We do not recommend changing the job [`allow_failure` setting](../../ci/yaml/index.md#allow_failure) as that fails the entire pipeline.
### JSON Artifact ### JSON Artifact
...@@ -357,7 +357,7 @@ You can do it quickly by following the hyperlink given to run a new pipeline. ...@@ -357,7 +357,7 @@ You can do it quickly by following the hyperlink given to run a new pipeline.
### Getting error message `sast job: stage parameter should be [some stage name here]` ### Getting error message `sast job: stage parameter should be [some stage name here]`
When [including](../../ci/yaml/README.md#includetemplate) a `.gitlab-ci.yml` template When [including](../../ci/yaml/index.md#includetemplate) a `.gitlab-ci.yml` template
like [`SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml), like [`SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml),
the following error may occur, depending on your GitLab CI/CD configuration: the following error may occur, depending on your GitLab CI/CD configuration:
...@@ -410,7 +410,7 @@ This provides useful information to investigate further. ...@@ -410,7 +410,7 @@ This provides useful information to investigate further.
### Getting error message `sast job: config key may not be used with 'rules': only/except` ### Getting error message `sast job: config key may not be used with 'rules': only/except`
When [including](../../ci/yaml/README.md#includetemplate) a `.gitlab-ci.yml` template When [including](../../ci/yaml/index.md#includetemplate) a `.gitlab-ci.yml` template
like [`SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml), like [`SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml),
the following error may occur, depending on your GitLab CI/CD configuration: the following error may occur, depending on your GitLab CI/CD configuration:
...@@ -421,7 +421,7 @@ Found errors in your .gitlab-ci.yml: ...@@ -421,7 +421,7 @@ Found errors in your .gitlab-ci.yml:
``` ```
This error appears when the included job's `rules` configuration has been [overridden](sast/index.md#overriding-sast-jobs) This error appears when the included job's `rules` configuration has been [overridden](sast/index.md#overriding-sast-jobs)
with [the deprecated `only` or `except` syntax.](../../ci/yaml/README.md#only--except) with [the deprecated `only` or `except` syntax.](../../ci/yaml/index.md#only--except)
To fix this issue, you must either: To fix this issue, you must either:
- [Transition your `only/except` syntax to `rules`](#transitioning-your-onlyexcept-syntax-to-rules). - [Transition your `only/except` syntax to `rules`](#transitioning-your-onlyexcept-syntax-to-rules).
...@@ -432,8 +432,8 @@ To fix this issue, you must either: ...@@ -432,8 +432,8 @@ To fix this issue, you must either:
#### Transitioning your `only/except` syntax to `rules` #### Transitioning your `only/except` syntax to `rules`
When overriding the template to control job execution, previous instances of When overriding the template to control job execution, previous instances of
[`only` or `except`](../../ci/yaml/README.md#only--except) are no longer compatible [`only` or `except`](../../ci/yaml/index.md#only--except) are no longer compatible
and must be transitioned to [the `rules` syntax](../../ci/yaml/README.md#rules). and must be transitioned to [the `rules` syntax](../../ci/yaml/index.md#rules).
If your override is aimed at limiting jobs to only run on `master`, the previous syntax If your override is aimed at limiting jobs to only run on `master`, the previous syntax
would look similar to: would look similar to:
...@@ -489,11 +489,11 @@ spotbugs-sast: ...@@ -489,11 +489,11 @@ spotbugs-sast:
- if: $CI_COMMIT_TAG == null - if: $CI_COMMIT_TAG == null
``` ```
[Learn more on the usage of `rules`](../../ci/yaml/README.md#rules). [Learn more on the usage of `rules`](../../ci/yaml/index.md#rules).
#### Pin your templates to the deprecated versions #### Pin your templates to the deprecated versions
To ensure the latest support, we **strongly** recommend that you migrate to [`rules`](../../ci/yaml/README.md#rules). To ensure the latest support, we **strongly** recommend that you migrate to [`rules`](../../ci/yaml/index.md#rules).
If you're unable to immediately update your CI configuration, there are several workarounds that If you're unable to immediately update your CI configuration, there are several workarounds that
involve pinning to the previous template versions, for example: involve pinning to the previous template versions, for example:
......
doc/user/application_security/offline_deployments/index.md
View file @ 0d978174
...@@ -108,7 +108,7 @@ example of such a transfer: ...@@ -108,7 +108,7 @@ example of such a transfer:
### Using the official GitLab template ### Using the official GitLab template
GitLab provides a [vendored template](../../../ci/yaml/README.md#includetemplate) GitLab provides a [vendored template](../../../ci/yaml/index.md#includetemplate)
to ease this process. to ease this process.
This template should be used in a new, empty project, with a `gitlab-ci.yml` file containing: This template should be used in a new, empty project, with a `gitlab-ci.yml` file containing:
......
doc/user/application_security/sast/index.md
View file @ 0d978174
...@@ -162,7 +162,7 @@ To configure SAST for a project you can: ...@@ -162,7 +162,7 @@ To configure SAST for a project you can:
### Configure SAST manually ### Configure SAST manually
For GitLab 11.9 and later, to enable SAST you must [include](../../../ci/yaml/README.md#includetemplate) For GitLab 11.9 and later, to enable SAST you must [include](../../../ci/yaml/index.md#includetemplate)
the [`SAST.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml) the [`SAST.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml)
provided as a part of your GitLab installation. For GitLab versions earlier than 11.9, you provided as a part of your GitLab installation. For GitLab versions earlier than 11.9, you
can copy and use the job as defined that template. can copy and use the job as defined that template.
...@@ -178,7 +178,7 @@ The included template creates SAST jobs in your CI/CD pipeline and scans ...@@ -178,7 +178,7 @@ The included template creates SAST jobs in your CI/CD pipeline and scans
your project's source code for possible vulnerabilities. your project's source code for possible vulnerabilities.
The results are saved as a The results are saved as a
[SAST report artifact](../../../ci/yaml/README.md#artifactsreportssast) [SAST report artifact](../../../ci/yaml/index.md#artifactsreportssast)
that you can later download and analyze. Due to implementation limitations, we that you can later download and analyze. Due to implementation limitations, we
always take the latest SAST artifact available. always take the latest SAST artifact available.
...@@ -206,7 +206,7 @@ page: ...@@ -206,7 +206,7 @@ page:
The SAST settings can be changed through [CI/CD variables](#available-cicd-variables) The SAST settings can be changed through [CI/CD variables](#available-cicd-variables)
by using the by using the
[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`. [`variables`](../../../ci/yaml/index.md#variables) parameter in `.gitlab-ci.yml`.
In the following example, we include the SAST template and at the same time we In the following example, we include the SAST template and at the same time we
set the `SAST_GOSEC_LEVEL` variable to `2`: set the `SAST_GOSEC_LEVEL` variable to `2`:
...@@ -218,14 +218,14 @@ variables: ...@@ -218,14 +218,14 @@ variables:
SAST_GOSEC_LEVEL: 2 SAST_GOSEC_LEVEL: 2
``` ```
Because the template is [evaluated before](../../../ci/yaml/README.md#include) Because the template is [evaluated before](../../../ci/yaml/index.md#include)
the pipeline configuration, the last mention of the variable takes precedence. the pipeline configuration, the last mention of the variable takes precedence.
### Overriding SAST jobs ### Overriding SAST jobs
WARNING: WARNING:
Beginning in GitLab 13.0, the use of [`only` and `except`](../../../ci/yaml/README.md#only--except) Beginning in GitLab 13.0, the use of [`only` and `except`](../../../ci/yaml/index.md#only--except)
is no longer supported. When overriding the template, you must use [`rules`](../../../ci/yaml/README.md#rules) instead. is no longer supported. When overriding the template, you must use [`rules`](../../../ci/yaml/index.md#rules) instead.
To override a job definition, (for example, change properties like `variables` or `dependencies`), To override a job definition, (for example, change properties like `variables` or `dependencies`),
declare a job with the same name as the SAST job to override. Place this new job after the template declare a job with the same name as the SAST job to override. Place this new job after the template
...@@ -556,7 +556,7 @@ The SAST tool emits a JSON report file. For more information, see the ...@@ -556,7 +556,7 @@ The SAST tool emits a JSON report file. For more information, see the
[schema for this report](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/dist/sast-report-format.json). [schema for this report](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/dist/sast-report-format.json).
The JSON report file can be downloaded from the CI pipelines page, or the The JSON report file can be downloaded from the CI pipelines page, or the
pipelines tab on merge requests by [setting `artifacts: paths`](../../../ci/yaml/README.md#artifactspaths) to `gl-sast-report.json`. For more information see [Downloading artifacts](../../../ci/pipelines/job_artifacts.md). pipelines tab on merge requests by [setting `artifacts: paths`](../../../ci/yaml/index.md#artifactspaths) to `gl-sast-report.json`. For more information see [Downloading artifacts](../../../ci/pipelines/job_artifacts.md).
Here's an example SAST report: Here's an example SAST report:
...@@ -765,7 +765,7 @@ uses the `rules:exists` parameter. For performance reasons, a maximum number of ...@@ -765,7 +765,7 @@ uses the `rules:exists` parameter. For performance reasons, a maximum number of
against the given glob pattern. If the number of matches exceeds the maximum, the `rules:exists` against the given glob pattern. If the number of matches exceeds the maximum, the `rules:exists`
parameter returns `true`. Depending on the number of files in your repository, a SAST job might be parameter returns `true`. Depending on the number of files in your repository, a SAST job might be
triggered even if the scanner doesn't support your project. For more details about this issue, see triggered even if the scanner doesn't support your project. For more details about this issue, see
the [`rules:exists` documentation](../../../ci/yaml/README.md#rulesexists). the [`rules:exists` documentation](../../../ci/yaml/index.md#rulesexists).
### SpotBugs UTF-8 unmappable character errors ### SpotBugs UTF-8 unmappable character errors
...@@ -791,7 +791,7 @@ For Maven builds, add the following to your `pom.xml` file: ...@@ -791,7 +791,7 @@ For Maven builds, add the following to your `pom.xml` file:
### Flawfinder encoding error ### Flawfinder encoding error
This occurs when Flawfinder encounters an invalid UTF-8 character. To fix this, convert all source code in your project to UTF-8 character encoding. This can be done with [`cvt2utf`](https://github.com/x1angli/cvt2utf) or [`iconv`](https://www.gnu.org/software/libiconv/documentation/libiconv-1.13/iconv.1.html) either over the entire project or per job using the [`before_script`](../../../ci/yaml/README.md#before_script) feature. This occurs when Flawfinder encounters an invalid UTF-8 character. To fix this, convert all source code in your project to UTF-8 character encoding. This can be done with [`cvt2utf`](https://github.com/x1angli/cvt2utf) or [`iconv`](https://www.gnu.org/software/libiconv/documentation/libiconv-1.13/iconv.1.html) either over the entire project or per job using the [`before_script`](../../../ci/yaml/index.md#before_script) feature.
### Semgrep slowness, unexpected results, or other errors ### Semgrep slowness, unexpected results, or other errors
......
doc/user/application_security/secret_detection/index.md
View file @ 0d978174
...@@ -133,7 +133,7 @@ The included template creates Secret Detection jobs in your CI/CD pipeline and s ...@@ -133,7 +133,7 @@ The included template creates Secret Detection jobs in your CI/CD pipeline and s
your project's source code for secrets. your project's source code for secrets.
The results are saved as a The results are saved as a
[Secret Detection report artifact](../../../ci/yaml/README.md#artifactsreportssecret_detection) [Secret Detection report artifact](../../../ci/yaml/index.md#artifactsreportssecret_detection)
that you can later download and analyze. Due to implementation limitations, we that you can later download and analyze. Due to implementation limitations, we
always take the latest Secret Detection artifact available. always take the latest Secret Detection artifact available.
...@@ -166,15 +166,15 @@ that you can review and merge to complete the configuration. ...@@ -166,15 +166,15 @@ that you can review and merge to complete the configuration.
The Secret Detection scan settings can be changed through [CI/CD variables](#available-cicd-variables) The Secret Detection scan settings can be changed through [CI/CD variables](#available-cicd-variables)
by using the by using the
[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`. [`variables`](../../../ci/yaml/index.md#variables) parameter in `.gitlab-ci.yml`.
To override a job definition, (for example, change properties like `variables` or `dependencies`), To override a job definition, (for example, change properties like `variables` or `dependencies`),
declare a job with the same name as the SAST job to override. Place this new job after the template declare a job with the same name as the SAST job to override. Place this new job after the template
inclusion and specify any additional keys under it. inclusion and specify any additional keys under it.
WARNING: WARNING:
Beginning in GitLab 13.0, the use of [`only` and `except`](../../../ci/yaml/README.md#only--except) Beginning in GitLab 13.0, the use of [`only` and `except`](../../../ci/yaml/index.md#only--except)
is no longer supported. When overriding the template, you must use [`rules`](../../../ci/yaml/README.md#rules) instead. is no longer supported. When overriding the template, you must use [`rules`](../../../ci/yaml/index.md#rules) instead.
#### GIT_DEPTH #### GIT_DEPTH
...@@ -197,7 +197,7 @@ secret_detection: ...@@ -197,7 +197,7 @@ secret_detection:
SECRET_DETECTION_HISTORIC_SCAN: "true" SECRET_DETECTION_HISTORIC_SCAN: "true"
``` ```
Because the template is [evaluated before](../../../ci/yaml/README.md#include) Because the template is [evaluated before](../../../ci/yaml/index.md#include)
the pipeline configuration, the last mention of the variable takes precedence. the pipeline configuration, the last mention of the variable takes precedence.
#### Available CI/CD variables #### Available CI/CD variables
......
doc/user/application_security/security_dashboard/index.md
View file @ 0d978174
...@@ -39,7 +39,7 @@ The security dashboard and vulnerability report displays information about vulne ...@@ -39,7 +39,7 @@ The security dashboard and vulnerability report displays information about vulne
1. At least one project inside a group must be configured with at least one of 1. At least one project inside a group must be configured with at least one of
the [supported reports](#supported-reports). 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/yaml/index.md#artifactsreports).
1. [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 or newer must be used. 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. If you're using the shared runners on GitLab.com, this is already the case.
......
doc/user/clusters/management_project.md
View file @ 0d978174
...@@ -58,7 +58,7 @@ To select a cluster management project to use: ...@@ -58,7 +58,7 @@ To select a cluster management project to use:
### Configuring your pipeline ### Configuring your pipeline
After designating a project as the management project for the cluster, After designating a project as the management project for the cluster,
write a [`.gitlab-ci.yml`](../../ci/yaml/README.md) in that project. For example: write a [`.gitlab-ci.yml`](../../ci/yaml/index.md) in that project. For example:
```yaml ```yaml
configure cluster: configure cluster:
...@@ -87,7 +87,7 @@ to a management project: ...@@ -87,7 +87,7 @@ to a management project:
| Production | `production` | | Production | `production` |
The following environments set in The following environments set in
[`.gitlab-ci.yml`](../../ci/yaml/README.md) deploy to the [`.gitlab-ci.yml`](../../ci/yaml/index.md) deploy to the
Development, Staging, and Production cluster respectively. Development, Staging, and Production cluster respectively.
```yaml ```yaml
......
doc/user/compliance/license_compliance/index.md
View file @ 0d978174
...@@ -90,11 +90,11 @@ To run a License Compliance scanning job, you need GitLab Runner with the ...@@ -90,11 +90,11 @@ To run a License Compliance scanning job, you need GitLab Runner with the
## Configuration ## Configuration
For GitLab 12.8 and later, to enable License Compliance, you must For GitLab 12.8 and later, to enable License Compliance, you must
[include](../../../ci/yaml/README.md#includetemplate) the [include](../../../ci/yaml/index.md#includetemplate) the
[`License-Scanning.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/License-Scanning.gitlab-ci.yml) [`License-Scanning.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/License-Scanning.gitlab-ci.yml)
that's provided as a part of your GitLab installation. that's provided as a part of your GitLab installation.
For older versions of GitLab from 11.9 to 12.7, you must For older versions of GitLab from 11.9 to 12.7, you must
[include](../../../ci/yaml/README.md#includetemplate) the [include](../../../ci/yaml/index.md#includetemplate) the
[`License-Management.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/d2cc841c55d65bc8134bfb3a467e66c36ac32b0a/lib/gitlab/ci/templates/Security/License-Management.gitlab-ci.yml). [`License-Management.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/d2cc841c55d65bc8134bfb3a467e66c36ac32b0a/lib/gitlab/ci/templates/Security/License-Management.gitlab-ci.yml).
For GitLab versions earlier than 11.9, you can copy and use the job as defined For GitLab versions earlier than 11.9, you can copy and use the job as defined
that template. that template.
...@@ -115,14 +115,14 @@ the `license_management` job, so you must migrate to the `license_scanning` job ...@@ -115,14 +115,14 @@ the `license_management` job, so you must migrate to the `license_scanning` job
`License-Scanning.gitlab-ci.yml` template. `License-Scanning.gitlab-ci.yml` template.
The results are saved as a The results are saved as a
[License Compliance report artifact](../../../ci/yaml/README.md#artifactsreportslicense_scanning) [License Compliance report artifact](../../../ci/yaml/index.md#artifactsreportslicense_scanning)
that you can later download and analyze. Due to implementation limitations, we that you can later download and analyze. Due to implementation limitations, we
always take the latest License Compliance artifact available. Behind the scenes, the always take the latest License Compliance artifact available. Behind the scenes, the
[GitLab License Compliance Docker image](https://gitlab.com/gitlab-org/security-products/analyzers/license-finder) [GitLab License Compliance Docker image](https://gitlab.com/gitlab-org/security-products/analyzers/license-finder)
is used to detect the languages/frameworks and in turn analyzes the licenses. is used to detect the languages/frameworks and in turn analyzes the licenses.
The License Compliance settings can be changed through [CI/CD variables](#available-cicd-variables) by using the The License Compliance settings can be changed through [CI/CD variables](#available-cicd-variables) by using the
[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`. [`variables`](../../../ci/yaml/index.md#variables) parameter in `.gitlab-ci.yml`.
### When License Compliance runs ### When License Compliance runs
...@@ -180,8 +180,8 @@ directory of your project. ...@@ -180,8 +180,8 @@ directory of your project.
### Overriding the template ### Overriding the template
WARNING: WARNING:
Beginning in GitLab 13.0, the use of [`only` and `except`](../../../ci/yaml/README.md#only--except) Beginning in GitLab 13.0, the use of [`only` and `except`](../../../ci/yaml/index.md#only--except)
is no longer supported. When overriding the template, you must use [`rules`](../../../ci/yaml/README.md#rules) instead. is no longer supported. When overriding the template, you must use [`rules`](../../../ci/yaml/index.md#rules) instead.
If you want to override the job definition (for example, change properties like If you want to override the job definition (for example, change properties like
`variables` or `dependencies`), you need to declare a `license_scanning` job `variables` or `dependencies`), you need to declare a `license_scanning` job
...@@ -441,7 +441,7 @@ documentation for a list of settings that you can apply. ...@@ -441,7 +441,7 @@ documentation for a list of settings that you can apply.
The `license_scanning` job runs in a [Debian 10](https://www.debian.org/releases/buster/) Docker The `license_scanning` job runs in a [Debian 10](https://www.debian.org/releases/buster/) Docker
image. The supplied image ships with some build tools such as [CMake](https://cmake.org/) and [GCC](https://gcc.gnu.org/). image. The supplied image ships with some build tools such as [CMake](https://cmake.org/) and [GCC](https://gcc.gnu.org/).
However, not all project types are supported by default. To install additional tools needed to However, not all project types are supported by default. To install additional tools needed to
compile dependencies, use a [`before_script`](../../../ci/yaml/README.md#before_script) compile dependencies, use a [`before_script`](../../../ci/yaml/index.md#before_script)
to install the necessary build tools using the [`apt`](https://wiki.debian.org/PackageManagementTools) to install the necessary build tools using the [`apt`](https://wiki.debian.org/PackageManagementTools)
package manager. For a comprehensive list, consult [the Conan documentation](https://docs.conan.io/en/latest/introduction.html#all-platforms-all-build-systems-and-compilers). package manager. For a comprehensive list, consult [the Conan documentation](https://docs.conan.io/en/latest/introduction.html#all-platforms-all-build-systems-and-compilers).
......
doc/user/gitlab_com/index.md
View file @ 0d978174
...@@ -111,7 +111,7 @@ the related documentation. ...@@ -111,7 +111,7 @@ the related documentation.
| Setting | GitLab.com | Default | | Setting | GitLab.com | Default |
|-------------------------------------|------------|---------| |-------------------------------------|------------|---------|
| Artifacts maximum size (compressed) | 1 GB | 100 MB | | Artifacts maximum size (compressed) | 1 GB | 100 MB |
| Artifacts [expiry time](../../ci/yaml/README.md#artifactsexpire_in) | From June 22, 2020, deleted after 30 days unless otherwise specified (artifacts created before that date have no expiry). | deleted after 30 days unless otherwise specified | | Artifacts [expiry time](../../ci/yaml/index.md#artifactsexpire_in) | From June 22, 2020, deleted after 30 days unless otherwise specified (artifacts created before that date have no expiry). | deleted after 30 days unless otherwise specified |
| Scheduled Pipeline Cron | `*/5 * * * *` | `3-59/10 * * * *` | | Scheduled Pipeline Cron | `*/5 * * * *` | `3-59/10 * * * *` |
| [Max jobs in active pipelines](../../administration/instance_limits.md#number-of-jobs-in-active-pipelines) | `500` for Free tier, unlimited otherwise | Unlimited | | [Max jobs in active pipelines](../../administration/instance_limits.md#number-of-jobs-in-active-pipelines) | `500` for Free tier, unlimited otherwise | Unlimited |
| [Max CI/CD subscriptions to a project](../../administration/instance_limits.md#number-of-cicd-subscriptions-to-a-project) | `2` | Unlimited | | [Max CI/CD subscriptions to a project](../../administration/instance_limits.md#number-of-cicd-subscriptions-to-a-project) | `2` | Unlimited |
......
doc/user/group/clusters/index.md
View file @ 0d978174
...@@ -122,7 +122,7 @@ For example, if your project has the following Kubernetes clusters: ...@@ -122,7 +122,7 @@ For example, if your project has the following Kubernetes clusters:
| Test | `test` | Group | | Test | `test` | Group |
| Development| `*` | Group | | Development| `*` | Group |
And the following environments are set in [`.gitlab-ci.yml`](../../../ci/yaml/README.md): And the following environments are set in [`.gitlab-ci.yml`](../../../ci/yaml/index.md):
```yaml ```yaml
stages: stages:
......
doc/user/group/value_stream_analytics/index.md
View file @ 0d978174
...@@ -133,7 +133,7 @@ Value Stream Analytics dashboard does not present any data for: ...@@ -133,7 +133,7 @@ Value Stream Analytics dashboard does not present any data for:
## How the production environment is identified ## How the production environment is identified
Value Stream Analytics identifies production environments by looking for project Value Stream Analytics identifies production environments by looking for project
[environments](../../../ci/yaml/README.md#environment) with a name matching any of these patterns: [environments](../../../ci/yaml/index.md#environment) with a name matching any of these patterns:
- `prod` or `prod/*` - `prod` or `prod/*`
- `production` or `production/*` - `production` or `production/*`
...@@ -162,7 +162,7 @@ environments is configured. ...@@ -162,7 +162,7 @@ environments is configured.
1. Push branch and create a merge request that contains the [issue closing pattern](../../project/issues/managing_issues.md#closing-issues-automatically) 1. Push branch and create a merge request that contains the [issue closing pattern](../../project/issues/managing_issues.md#closing-issues-automatically)
in its description at 14:00 (stop of **Code** stage / start of **Test** and in its description at 14:00 (stop of **Code** stage / start of **Test** and
**Review** stages). **Review** stages).
1. The CI starts running your scripts defined in [`.gitlab-ci.yml`](../../../ci/yaml/README.md) and 1. The CI starts running your scripts defined in [`.gitlab-ci.yml`](../../../ci/yaml/index.md) and
takes 5min (stop of **Test** stage). takes 5min (stop of **Test** stage).
1. Review merge request, ensure that everything is OK and merge the merge 1. Review merge request, ensure that everything is OK and merge the merge
request at 19:00. (stop of **Review** stage / start of **Staging** stage). request at 19:00. (stop of **Review** stage / start of **Staging** stage).
......
doc/user/infrastructure/mr_integration.md
View file @ 0d978174
...@@ -10,7 +10,7 @@ Collaborating around Infrastructure as Code (IaC) changes requires both code cha ...@@ -10,7 +10,7 @@ Collaborating around Infrastructure as Code (IaC) changes requires both code cha
## Output Terraform Plan information into a merge request ## Output Terraform Plan information into a merge request
Using the [GitLab Terraform Report artifact](../../ci/yaml/README.md#artifactsreportsterraform), Using the [GitLab Terraform Report artifact](../../ci/yaml/index.md#artifactsreportsterraform),
you can expose details from `terraform plan` runs directly into a merge request widget, you can expose details from `terraform plan` runs directly into a merge request widget,
enabling you to see statistics about the resources that Terraform creates, enabling you to see statistics about the resources that Terraform creates,
modifies, or destroys. modifies, or destroys.
...@@ -57,7 +57,7 @@ To manually configure a GitLab Terraform Report artifact requires the following ...@@ -57,7 +57,7 @@ To manually configure a GitLab Terraform Report artifact requires the following
1. Define a `script` that runs `terraform plan` and `terraform show`. These commands 1. Define a `script` that runs `terraform plan` and `terraform show`. These commands
pipe the output and convert the relevant bits into a store variable `PLAN_JSON`. pipe the output and convert the relevant bits into a store variable `PLAN_JSON`.
This JSON is used to create a This JSON is used to create a
[GitLab Terraform Report artifact](../../ci/yaml/README.md#artifactsreportsterraform). [GitLab Terraform Report artifact](../../ci/yaml/index.md#artifactsreportsterraform).
The Terraform report obtains a Terraform `tfplan.json` file. The collected The Terraform report obtains a Terraform `tfplan.json` file. The collected
Terraform plan report is uploaded to GitLab as an artifact, and is shown in merge requests. Terraform plan report is uploaded to GitLab as an artifact, and is shown in merge requests.
......
doc/user/packages/container_registry/index.md
View file @ 0d978174
...@@ -135,7 +135,7 @@ To view these commands, go to your project's **Packages & Registries > Container ...@@ -135,7 +135,7 @@ To view these commands, go to your project's **Packages & Registries > Container
## Build and push by using GitLab CI/CD ## Build and push by using GitLab CI/CD
Use [GitLab CI/CD](../../../ci/yaml/README.md) to build and push images to the Use [GitLab CI/CD](../../../ci/yaml/index.md) to build and push images to the
Container Registry. Use it to test, build, and deploy your project from the Docker Container Registry. Use it to test, build, and deploy your project from the Docker
image you created. image you created.
...@@ -309,7 +309,7 @@ in addition to the steps in the ...@@ -309,7 +309,7 @@ in addition to the steps in the
[Docker-in-Docker](../../../ci/docker/using_docker_build.md#use-the-docker-executor-with-the-docker-image-docker-in-docker) section: [Docker-in-Docker](../../../ci/docker/using_docker_build.md#use-the-docker-executor-with-the-docker-image-docker-in-docker) section:
1. Update the `image` and `service` to point to your registry. 1. Update the `image` and `service` to point to your registry.
1. Add a service [alias](../../../ci/yaml/README.md#servicesalias). 1. Add a service [alias](../../../ci/yaml/index.md#servicesalias).
Below is an example of what your `.gitlab-ci.yml` should look like: Below is an example of what your `.gitlab-ci.yml` should look like:
...@@ -339,7 +339,7 @@ in addition to the steps in the ...@@ -339,7 +339,7 @@ in addition to the steps in the
[Docker-in-Docker](../../../ci/docker/using_docker_build.md#use-the-docker-executor-with-the-docker-image-docker-in-docker) section: [Docker-in-Docker](../../../ci/docker/using_docker_build.md#use-the-docker-executor-with-the-docker-image-docker-in-docker) section:
1. Update the `image` and `service` to point to your registry. 1. Update the `image` and `service` to point to your registry.
1. Add a service [alias](../../../ci/yaml/README.md#servicesalias). 1. Add a service [alias](../../../ci/yaml/index.md#servicesalias).
Below is an example of what your `.gitlab-ci.yml` should look like: Below is an example of what your `.gitlab-ci.yml` should look like:
......
doc/user/packages/dependency_proxy/index.md
View file @ 0d978174
...@@ -134,13 +134,13 @@ To store a Docker image in Dependency Proxy storage: ...@@ -134,13 +134,13 @@ To store a Docker image in Dependency Proxy storage:
1. Use one of these commands. In these examples, the image is `alpine:latest`. 1. Use one of these commands. In these examples, the image is `alpine:latest`.
1. You can also pull images by digest to specify exactly which version of an image to pull. 1. You can also pull images by digest to specify exactly which version of an image to pull.
- Pull an image by tag by adding the image to your [`.gitlab-ci.yml`](../../../ci/yaml/README.md#image) file: - Pull an image by tag by adding the image to your [`.gitlab-ci.yml`](../../../ci/yaml/index.md#image) file:
```shell ```shell
image: gitlab.example.com/groupname/dependency_proxy/containers/alpine:latest image: gitlab.example.com/groupname/dependency_proxy/containers/alpine:latest
``` ```
- Pull an image by digest by adding the image to your [`.gitlab-ci.yml`](../../../ci/yaml/README.md#image) file: - Pull an image by digest by adding the image to your [`.gitlab-ci.yml`](../../../ci/yaml/index.md#image) file:
```shell ```shell
image: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/alpine@sha256:c9375e662992791e3f39e919b26f510e5254b42792519c180aad254e6b38f4dc image: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/alpine@sha256:c9375e662992791e3f39e919b26f510e5254b42792519c180aad254e6b38f4dc
......
doc/user/project/clusters/multiple_kubernetes_clusters.md
View file @ 0d978174
...@@ -35,7 +35,7 @@ For example, let's say the following Kubernetes clusters exist in a project: ...@@ -35,7 +35,7 @@ For example, let's say the following Kubernetes clusters exist in a project:
| Production | `production` | | Production | `production` |
And the following environments are set in And the following environments are set in
[`.gitlab-ci.yml`](../../../ci/yaml/README.md): [`.gitlab-ci.yml`](../../../ci/yaml/index.md):
```yaml ```yaml
stages: stages:
......
doc/user/project/clusters/serverless/aws.md
View file @ 0d978174
...@@ -381,7 +381,7 @@ control to AWS Lambda, API Gateway, CloudFormation, and IAM resources. ...@@ -381,7 +381,7 @@ control to AWS Lambda, API Gateway, CloudFormation, and IAM resources.
### Crafting the `.gitlab-ci.yml` file ### Crafting the `.gitlab-ci.yml` file
In a [`.gitlab-ci.yml`](../../../../ci/yaml/README.md) file in the root of your project, In a [`.gitlab-ci.yml`](../../../../ci/yaml/index.md) file in the root of your project,
add the following and replace `<S3_bucket_name>` with the name of the S3 bucket where you add the following and replace `<S3_bucket_name>` with the name of the S3 bucket where you
want to store your package: want to store your package:
......
doc/user/project/deploy_boards.md
View file @ 0d978174
...@@ -59,7 +59,7 @@ specific environment, there are a lot of use cases. To name a few: ...@@ -59,7 +59,7 @@ specific environment, there are a lot of use cases. To name a few:
- You want to promote what's running in staging, to production. You go to the - You want to promote what's running in staging, to production. You go to the
environments list, verify that what's running in staging is what you think is environments list, verify that what's running in staging is what you think is
running, then click on the [manual action](../../ci/yaml/README.md#whenmanual) to deploy to production. running, then click on the [manual action](../../ci/yaml/index.md#whenmanual) to deploy to production.
- You trigger a deploy, and you have many containers to upgrade so you know - You trigger a deploy, and you have many containers to upgrade so you know
this takes a while (you've also throttled your deploy to only take down X this takes a while (you've also throttled your deploy to only take down X
containers at a time). But you need to tell someone when it's deployed, so you containers at a time). But you need to tell someone when it's deployed, so you
......
doc/user/project/integrations/mattermost_slash_commands.md
View file @ 0d978174
...@@ -141,7 +141,7 @@ The available slash commands for Mattermost are: ...@@ -141,7 +141,7 @@ The available slash commands for Mattermost are:
| ------- | ----------- | ------- | | ------- | ----------- | ------- |
| <kbd>/&lt;trigger&gt; issue new &lt;title&gt; <kbd>⇧ Shift</kbd>+<kbd>↵ Enter</kbd> &lt;description&gt;</kbd> | Create a new issue in the project that `<trigger>` is tied to. `<description>` is optional. | `/gitlab issue new We need to change the homepage` | | <kbd>/&lt;trigger&gt; issue new &lt;title&gt; <kbd>⇧ Shift</kbd>+<kbd>↵ Enter</kbd> &lt;description&gt;</kbd> | Create a new issue in the project that `<trigger>` is tied to. `<description>` is optional. | `/gitlab issue new We need to change the homepage` |
| <kbd>/&lt;trigger&gt; issue show &lt;issue-number&gt;</kbd> | Show the issue with ID `<issue-number>` from the project that `<trigger>` is tied to. | `/gitlab issue show 42` | | <kbd>/&lt;trigger&gt; issue show &lt;issue-number&gt;</kbd> | Show the issue with ID `<issue-number>` from the project that `<trigger>` is tied to. | `/gitlab issue show 42` |
| <kbd>/&lt;trigger&gt; deploy &lt;environment&gt; to &lt;environment&gt;</kbd> | Start the CI job that deploys from one environment to another, for example `staging` to `production`. CI/CD must be [properly configured](../../../ci/yaml/README.md). | `/gitlab deploy staging to production` | | <kbd>/&lt;trigger&gt; deploy &lt;environment&gt; to &lt;environment&gt;</kbd> | Start the CI job that deploys from one environment to another, for example `staging` to `production`. CI/CD must be [properly configured](../../../ci/yaml/index.md). | `/gitlab deploy staging to production` |
To see a list of available commands to interact with GitLab, type the To see a list of available commands to interact with GitLab, type the
trigger word followed by <kbd>help</kbd>. Example: `/gitlab help` trigger word followed by <kbd>help</kbd>. Example: `/gitlab help`
......
doc/user/project/merge_requests/accessibility_testing.md
View file @ 0d978174
...@@ -37,7 +37,7 @@ This example shows how to run [pa11y](https://pa11y.org/) ...@@ -37,7 +37,7 @@ This example shows how to run [pa11y](https://pa11y.org/)
on your code with GitLab CI/CD using the [GitLab Accessibility Docker image](https://gitlab.com/gitlab-org/ci-cd/accessibility). on your code with GitLab CI/CD using the [GitLab Accessibility Docker image](https://gitlab.com/gitlab-org/ci-cd/accessibility).
For GitLab 12.9 and later, to define the `a11y` job, you must For GitLab 12.9 and later, to define the `a11y` job, you must
[include](../../../ci/yaml/README.md#includetemplate) the [include](../../../ci/yaml/index.md#includetemplate) the
[`Accessibility.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml) [`Accessibility.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml)
included with your GitLab installation, as shown below. included with your GitLab installation, as shown below.
......
doc/user/project/merge_requests/browser_performance_testing.md
View file @ 0d978174
...@@ -40,7 +40,7 @@ Consider the following workflow: ...@@ -40,7 +40,7 @@ Consider the following workflow:
## How browser performance testing works ## How browser performance testing works
First, define a job in your `.gitlab-ci.yml` file that generates the First, define a job in your `.gitlab-ci.yml` file that generates the
[Browser Performance report artifact](../../../ci/yaml/README.md#artifactsreportsbrowser_performance). [Browser Performance report artifact](../../../ci/yaml/index.md#artifactsreportsbrowser_performance).
GitLab then checks this report, compares key performance metrics for each page GitLab then checks this report, compares key performance metrics for each page
between the source and target branches, and shows the information in the merge request. between the source and target branches, and shows the information in the merge request.
...@@ -89,7 +89,7 @@ The above example: ...@@ -89,7 +89,7 @@ The above example:
GitLab 12.3 or earlier, you must [add the configuration manually](#gitlab-versions-132-and-earlier). GitLab 12.3 or earlier, you must [add the configuration manually](#gitlab-versions-132-and-earlier).
The template uses the [GitLab plugin for sitespeed.io](https://gitlab.com/gitlab-org/gl-performance), The template uses the [GitLab plugin for sitespeed.io](https://gitlab.com/gitlab-org/gl-performance),
and it saves the full HTML sitespeed.io report as a [Browser Performance report artifact](../../../ci/yaml/README.md#artifactsreportsbrowser_performance) and it saves the full HTML sitespeed.io report as a [Browser Performance report artifact](../../../ci/yaml/index.md#artifactsreportsbrowser_performance)
that you can later download and analyze. This implementation always takes the latest that you can later download and analyze. This implementation always takes the latest
Browser Performance artifact available. If [GitLab Pages](../pages/index.md) is enabled, Browser Performance artifact available. If [GitLab Pages](../pages/index.md) is enabled,
you can view the report directly in your browser. you can view the report directly in your browser.
......
doc/user/project/merge_requests/code_quality.md
View file @ 0d978174
...@@ -111,7 +111,7 @@ include: ...@@ -111,7 +111,7 @@ include:
The above example creates a `code_quality` job in your CI/CD pipeline which The above example creates a `code_quality` job in your CI/CD pipeline which
scans your source code for code quality issues. The report is saved as a scans your source code for code quality issues. The report is saved as a
[Code Quality report artifact](../../../ci/yaml/README.md#artifactsreportscodequality) [Code Quality report artifact](../../../ci/yaml/index.md#artifactsreportscodequality)
that you can later download and analyze. that you can later download and analyze.
It's also possible to override the URL to the Code Quality image by It's also possible to override the URL to the Code Quality image by
...@@ -282,7 +282,7 @@ run on [pipelines for merge requests](../../../ci/merge_request_pipelines/index. ...@@ -282,7 +282,7 @@ run on [pipelines for merge requests](../../../ci/merge_request_pipelines/index.
If pipelines for merge requests is enabled, the `code_quality:rules` must be redefined. If pipelines for merge requests is enabled, the `code_quality:rules` must be redefined.
The template has these [`rules`](../../../ci/yaml/README.md#rules) for the `code quality` job: The template has these [`rules`](../../../ci/yaml/index.md#rules) for the `code quality` job:
```yaml ```yaml
code_quality: code_quality:
...@@ -292,7 +292,7 @@ code_quality: ...@@ -292,7 +292,7 @@ code_quality:
- if: '$CI_COMMIT_TAG || $CI_COMMIT_BRANCH' - if: '$CI_COMMIT_TAG || $CI_COMMIT_BRANCH'
``` ```
If you are using merge request pipelines, your `rules` (or [`workflow: rules`](../../../ci/yaml/README.md#workflow)) If you are using merge request pipelines, your `rules` (or [`workflow: rules`](../../../ci/yaml/index.md#workflow))
might look like this example: might look like this example:
```yaml ```yaml
...@@ -334,7 +334,7 @@ do this: ...@@ -334,7 +334,7 @@ do this:
1. Define a job in your `.gitlab-ci.yml` file that generates the 1. Define a job in your `.gitlab-ci.yml` file that generates the
[Code Quality report [Code Quality report
artifact](../../../ci/yaml/README.md#artifactsreportscodequality). artifact](../../../ci/yaml/index.md#artifactsreportscodequality).
1. Configure your tool to generate the Code Quality report artifact as a JSON 1. Configure your tool to generate the Code Quality report artifact as a JSON
file that implements a subset of the [Code Climate file that implements a subset of the [Code Climate
spec](https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md#data-types). spec](https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md#data-types).
...@@ -535,7 +535,7 @@ This can be due to multiple reasons: ...@@ -535,7 +535,7 @@ This can be due to multiple reasons:
- Your pipeline is not set to run the code quality job on your target branch. If there is no report generated from the target branch, your MR branch reports have nothing to compare to. - Your pipeline is not set to run the code quality job on your target branch. If there is no report generated from the target branch, your MR branch reports have nothing to compare to.
- If no [degradation or error is detected](https://docs.codeclimate.com/docs/maintainability#section-checks), - If no [degradation or error is detected](https://docs.codeclimate.com/docs/maintainability#section-checks),
nothing is displayed. nothing is displayed.
- The [`artifacts:expire_in`](../../../ci/yaml/README.md#artifactsexpire_in) CI/CD - The [`artifacts:expire_in`](../../../ci/yaml/index.md#artifactsexpire_in) CI/CD
setting can cause the Code Quality artifact(s) to expire faster than desired. setting can cause the Code Quality artifact(s) to expire faster than desired.
- The widgets use the pipeline of the latest commit to the target branch. If commits are made to the default branch that do not run the code quality job, this may cause the merge request widget to have no base report for comparison. - The widgets use the pipeline of the latest commit to the target branch. If commits are made to the default branch that do not run the code quality job, this may cause the merge request widget to have no base report for comparison.
- If you use the [`REPORT_STDOUT` environment variable](https://gitlab.com/gitlab-org/ci-cd/codequality#environment-variables), no report file is generated and nothing displays in the merge request. - If you use the [`REPORT_STDOUT` environment variable](https://gitlab.com/gitlab-org/ci-cd/codequality#environment-variables), no report file is generated and nothing displays in the merge request.
......
doc/user/project/merge_requests/fail_fast_testing.md
View file @ 0d978174
...@@ -19,7 +19,7 @@ that it believes to be relevant to the input files. ...@@ -19,7 +19,7 @@ that it believes to be relevant to the input files.
`tff` is designed for Ruby on Rails projects, so the `Verify/FailFast` template is `tff` is designed for Ruby on Rails projects, so the `Verify/FailFast` template is
configured to run when changes to Ruby files are detected. By default, it runs in configured to run when changes to Ruby files are detected. By default, it runs in
the [`.pre` stage](../../../ci/yaml/README.md#pre-and-post) of a GitLab CI/CD pipeline, the [`.pre` stage](../../../ci/yaml/index.md#pre-and-post) of a GitLab CI/CD pipeline,
before all other stages. before all other stages.
## Example use case ## Example use case
...@@ -62,7 +62,7 @@ rspec-complete: ...@@ -62,7 +62,7 @@ rspec-complete:
- bundle exec rspec - bundle exec rspec
``` ```
To run the most relevant specs first instead of the whole suite, [`include`](../../../ci/yaml/README.md#include) To run the most relevant specs first instead of the whole suite, [`include`](../../../ci/yaml/index.md#include)
the template by adding the following to your CI/CD configuration: the template by adding the following to your CI/CD configuration:
```yaml ```yaml
......
doc/user/project/merge_requests/index.md
View file @ 0d978174
...@@ -119,7 +119,7 @@ For a software developer working in a team: ...@@ -119,7 +119,7 @@ For a software developer working in a team:
1. Pushes a commit with their final review. 1. Pushes a commit with their final review.
1. [Approves the merge request](approvals/index.md). 1. [Approves the merge request](approvals/index.md).
1. Sets it to [merge when pipeline succeeds](merge_when_pipeline_succeeds.md). 1. Sets it to [merge when pipeline succeeds](merge_when_pipeline_succeeds.md).
1. Your changes get deployed to production with [manual actions](../../../ci/yaml/README.md#whenmanual) for GitLab CI/CD. 1. Your changes get deployed to production with [manual actions](../../../ci/yaml/index.md#whenmanual) for GitLab CI/CD.
1. Your implementations were successfully shipped to your customer. 1. Your implementations were successfully shipped to your customer.
For a web developer writing a webpage for your company's website: For a web developer writing a webpage for your company's website:
......
doc/user/project/merge_requests/load_performance_testing.md
View file @ 0d978174
...@@ -28,7 +28,7 @@ GET calls to a popular API endpoint in your application to see how it performs. ...@@ -28,7 +28,7 @@ GET calls to a popular API endpoint in your application to see how it performs.
## How Load Performance Testing works ## How Load Performance Testing works
First, define a job in your `.gitlab-ci.yml` file that generates the First, define a job in your `.gitlab-ci.yml` file that generates the
[Load Performance report artifact](../../../ci/yaml/README.md#artifactsreportsload_performance). [Load Performance report artifact](../../../ci/yaml/index.md#artifactsreportsload_performance).
GitLab checks this report, compares key load performance metrics GitLab checks this report, compares key load performance metrics
between the source and target branches, and then shows the information in a merge request widget: between the source and target branches, and then shows the information in a merge request widget:
...@@ -140,7 +140,7 @@ For example, you can override the duration of the test with a CLI option: ...@@ -140,7 +140,7 @@ For example, you can override the duration of the test with a CLI option:
GitLab only displays the key performance metrics in the MR widget if k6's results are saved GitLab only displays the key performance metrics in the MR widget if k6's results are saved
via [summary export](https://k6.io/docs/results-visualization/json#summary-export) via [summary export](https://k6.io/docs/results-visualization/json#summary-export)
as a [Load Performance report artifact](../../../ci/yaml/README.md#artifactsreportsload_performance). as a [Load Performance report artifact](../../../ci/yaml/index.md#artifactsreportsload_performance).
The latest Load Performance artifact available is always used, using the The latest Load Performance artifact available is always used, using the
summary values from the test. summary values from the test.
......
doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
View file @ 0d978174
...@@ -67,8 +67,8 @@ You should be careful to configure CI/CD so that pipelines run for every merge r ...@@ -67,8 +67,8 @@ You should be careful to configure CI/CD so that pipelines run for every merge r
### Limitations ### Limitations
When this setting is enabled, a merge request is prevented from being merged if there When this setting is enabled, a merge request is prevented from being merged if there
is no pipeline. This may conflict with some use cases where [`only/except`](../../../ci/yaml/README.md#only--except) is no pipeline. This may conflict with some use cases where [`only/except`](../../../ci/yaml/index.md#only--except)
or [`rules`](../../../ci/yaml/README.md#rules) are used and they don't generate any pipelines. or [`rules`](../../../ci/yaml/index.md#rules) are used and they don't generate any pipelines.
You should ensure that [there is always a pipeline](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/54226) You should ensure that [there is always a pipeline](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/54226)
and that it's successful. and that it's successful.
...@@ -101,7 +101,7 @@ for details on avoiding two pipelines for a single merge request. ...@@ -101,7 +101,7 @@ for details on avoiding two pipelines for a single merge request.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211482) in GitLab 13.1. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211482) in GitLab 13.1.
When the **Pipelines must succeed** checkbox is checked, [skipped pipelines](../../../ci/yaml/README.md#skip-pipeline) prevent When the **Pipelines must succeed** checkbox is checked, [skipped pipelines](../../../ci/yaml/index.md#skip-pipeline) prevent
merge requests from being merged. To change this behavior: merge requests from being merged. To change this behavior:
1. Navigate to your project's **Settings > General** page. 1. Navigate to your project's **Settings > General** page.
......
doc/user/project/merge_requests/test_coverage_visualization.md
View file @ 0d978174
...@@ -21,14 +21,14 @@ MR is merged. ...@@ -21,14 +21,14 @@ MR is merged.
## How test coverage visualization works ## How test coverage visualization works
Collecting the coverage information is done via GitLab CI/CD's Collecting the coverage information is done via GitLab CI/CD's
[artifacts reports feature](../../../ci/yaml/README.md#artifactsreports). [artifacts reports feature](../../../ci/yaml/index.md#artifactsreports).
You can specify one or more coverage reports to collect, including wildcard paths. You can specify one or more coverage reports to collect, including wildcard paths.
GitLab then takes the coverage information in all the files and combines it GitLab then takes the coverage information in all the files and combines it
together. together.
For the coverage analysis to work, you have to provide a properly formatted For the coverage analysis to work, you have to provide a properly formatted
[Cobertura XML](https://cobertura.github.io/cobertura/) report to [Cobertura XML](https://cobertura.github.io/cobertura/) report to
[`artifacts:reports:cobertura`](../../../ci/yaml/README.md#artifactsreportscobertura). [`artifacts:reports:cobertura`](../../../ci/yaml/index.md#artifactsreportscobertura).
This format was originally developed for Java, but most coverage analysis frameworks This format was originally developed for Java, but most coverage analysis frameworks
for other languages have plugins to add support for it, like: for other languages have plugins to add support for it, like:
...@@ -129,7 +129,7 @@ The `source` is ignored if the path does not follow this pattern. The parser ass ...@@ -129,7 +129,7 @@ The `source` is ignored if the path does not follow this pattern. The parser ass
### JavaScript example ### JavaScript example
The following [`gitlab-ci.yml`](../../../ci/yaml/README.md) example uses [Mocha](https://mochajs.org/) The following [`gitlab-ci.yml`](../../../ci/yaml/index.md) example uses [Mocha](https://mochajs.org/)
JavaScript testing and [nyc](https://github.com/istanbuljs/nyc) coverage-tooling to JavaScript testing and [nyc](https://github.com/istanbuljs/nyc) coverage-tooling to
generate the coverage artifact: generate the coverage artifact:
...@@ -147,7 +147,7 @@ test: ...@@ -147,7 +147,7 @@ test:
#### Maven example #### Maven example
The following [`gitlab-ci.yml`](../../../ci/yaml/README.md) example for Java or Kotlin uses [Maven](https://maven.apache.org/) The following [`gitlab-ci.yml`](../../../ci/yaml/index.md) example for Java or Kotlin uses [Maven](https://maven.apache.org/)
to build the project and [JaCoCo](https://www.eclemma.org/jacoco/) coverage-tooling to to build the project and [JaCoCo](https://www.eclemma.org/jacoco/) coverage-tooling to
generate the coverage artifact. generate the coverage artifact.
You can check the [Docker image configuration and scripts](https://gitlab.com/haynes/jacoco2cobertura) if you want to build your own image. You can check the [Docker image configuration and scripts](https://gitlab.com/haynes/jacoco2cobertura) if you want to build your own image.
...@@ -185,7 +185,7 @@ coverage-jdk11: ...@@ -185,7 +185,7 @@ coverage-jdk11:
#### Gradle example #### Gradle example
The following [`gitlab-ci.yml`](../../../ci/yaml/README.md) example for Java or Kotlin uses [Gradle](https://gradle.org/) The following [`gitlab-ci.yml`](../../../ci/yaml/index.md) example for Java or Kotlin uses [Gradle](https://gradle.org/)
to build the project and [JaCoCo](https://www.eclemma.org/jacoco/) coverage-tooling to to build the project and [JaCoCo](https://www.eclemma.org/jacoco/) coverage-tooling to
generate the coverage artifact. generate the coverage artifact.
You can check the [Docker image configuration and scripts](https://gitlab.com/haynes/jacoco2cobertura) if you want to build your own image. You can check the [Docker image configuration and scripts](https://gitlab.com/haynes/jacoco2cobertura) if you want to build your own image.
...@@ -223,7 +223,7 @@ coverage-jdk11: ...@@ -223,7 +223,7 @@ coverage-jdk11:
### Python example ### Python example
The following [`gitlab-ci.yml`](../../../ci/yaml/README.md) example for Python uses [pytest-cov](https://pytest-cov.readthedocs.io/) to collect test coverage data and [coverage.py](https://coverage.readthedocs.io/) to convert the report to use full relative paths. The following [`gitlab-ci.yml`](../../../ci/yaml/index.md) example for Python uses [pytest-cov](https://pytest-cov.readthedocs.io/) to collect test coverage data and [coverage.py](https://coverage.readthedocs.io/) to convert the report to use full relative paths.
The information isn't displayed without the conversion. The information isn't displayed without the conversion.
This example assumes that the code for your package is in `src/` and your tests are in `tests.py`: This example assumes that the code for your package is in `src/` and your tests are in `tests.py`:
...@@ -243,7 +243,7 @@ run tests: ...@@ -243,7 +243,7 @@ run tests:
### C/C++ example ### C/C++ example
The following [`gitlab-ci.yml`](../../../ci/yaml/README.md) example for C/C++ with The following [`gitlab-ci.yml`](../../../ci/yaml/index.md) example for C/C++ with
`gcc` or `g++` as the compiler uses [`gcovr`](https://gcovr.com/en/stable/) to generate the coverage `gcc` or `g++` as the compiler uses [`gcovr`](https://gcovr.com/en/stable/) to generate the coverage
output file in Cobertura XML format. output file in Cobertura XML format.
......
doc/user/project/merge_requests/testing_and_reports_in_merge_requests.md
View file @ 0d978174
...@@ -17,7 +17,7 @@ or link to useful information directly from merge requests: ...@@ -17,7 +17,7 @@ or link to useful information directly from merge requests:
| [Browser Performance Testing](browser_performance_testing.md) **(PREMIUM)** | Quickly determine the browser performance impact of pending code changes. | | [Browser Performance Testing](browser_performance_testing.md) **(PREMIUM)** | Quickly determine the browser performance impact of pending code changes. |
| [Load Performance Testing](load_performance_testing.md) **(PREMIUM)** | Quickly determine the server performance impact of pending code changes. | | [Load Performance Testing](load_performance_testing.md) **(PREMIUM)** | Quickly determine the server performance impact of pending code changes. |
| [Code Quality](code_quality.md) | Analyze your source code quality using the [Code Climate](https://codeclimate.com/) analyzer and show the Code Climate report right in the merge request widget area. | | [Code Quality](code_quality.md) | Analyze your source code quality using the [Code Climate](https://codeclimate.com/) analyzer and show the Code Climate report right in the merge request widget area. |
| [Display arbitrary job artifacts](../../../ci/yaml/README.md#artifactsexpose_as) | Configure CI pipelines with the `artifacts:expose_as` parameter to directly link to selected [artifacts](../../../ci/pipelines/job_artifacts.md) in merge requests. | | [Display arbitrary job artifacts](../../../ci/yaml/index.md#artifactsexpose_as) | Configure CI pipelines with the `artifacts:expose_as` parameter to directly link to selected [artifacts](../../../ci/pipelines/job_artifacts.md) in merge requests. |
| [GitLab CI/CD](../../../ci/index.md) | Build, test, and deploy your code in a per-branch basis with built-in CI/CD. | | [GitLab CI/CD](../../../ci/index.md) | Build, test, and deploy your code in a per-branch basis with built-in CI/CD. |
| [Unit test reports](../../../ci/unit_test_reports.md) | Configure your CI jobs to use Unit test reports, and let GitLab display a report on the merge request so that it's easier and faster to identify the failure without having to check the entire job log. | | [Unit test reports](../../../ci/unit_test_reports.md) | Configure your CI jobs to use Unit test reports, and let GitLab display a report on the merge request so that it's easier and faster to identify the failure without having to check the entire job log. |
| [License Compliance](../../compliance/license_compliance/index.md) **(ULTIMATE)** | Manage the licenses of your dependencies. | | [License Compliance](../../compliance/license_compliance/index.md) **(ULTIMATE)** | Manage the licenses of your dependencies. |
......
doc/user/project/pages/introduction.md
View file @ 0d978174
This diff is collapsed.
doc/user/project/releases/index.md
View file @ 0d978174
This diff is collapsed.
doc/user/project/repository/index.md
View file @ 0d978174
This diff is collapsed.
doc/user/project/requirements/index.md
View file @ 0d978174
This diff is collapsed.
doc/user/project/settings/index.md
View file @ 0d978174
This diff is collapsed.
doc/user/project/web_ide/index.md
View file @ 0d978174
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7