changes:# Will include the job and set to when:manual if any of the follow paths match a modified file.
changes:# Include the job and set to when:manual if any of the follow paths match a modified file.
-Dockerfile
-Dockerfile
-docker/scripts/*
-docker/scripts/*
when:manual
when:manual
...
@@ -1730,7 +1730,7 @@ the pipeline if the following is true:
...
@@ -1730,7 +1730,7 @@ the pipeline if the following is true:
-`(any listed refs are true) AND (any listed variables are true) AND (any listed changes are true) AND (any chosen Kubernetes status matches)`
-`(any listed refs are true) AND (any listed variables are true) AND (any listed changes are true) AND (any chosen Kubernetes status matches)`
In the example below, the `test` job will `only` be created when **all** of the following are true:
In the example below, the `test` job is `only` created when **all** of the following are true:
- The pipeline has been [scheduled](../pipelines/schedules.md)**or** runs for `master`.
- The pipeline has been [scheduled](../pipelines/schedules.md)**or** runs for `master`.
- The `variables` keyword matches.
- The `variables` keyword matches.
...
@@ -1889,7 +1889,7 @@ the `docker build` job is created, but only if changes were made to any of the f
...
@@ -1889,7 +1889,7 @@ the `docker build` job is created, but only if changes were made to any of the f
CAUTION: **Warning:**
CAUTION: **Warning:**
If you use `only:changes` with [only allow merge requests to be merged if the pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds),
If you use `only:changes` with [only allow merge requests to be merged if the pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds),
undesired behavior can result if you don't [also use `only:merge_requests`](#using-onlychanges-with-pipelines-for-merge-requests).
you should [also use `only:merge_requests`](#using-onlychanges-with-pipelines-for-merge-requests). Otherwise it may not work as expected.
You can also use glob patterns to match multiple files in either the root directory
You can also use glob patterns to match multiple files in either the root directory
of the repository, or in _any_ directory within the repository. However, they must be wrapped
of the repository, or in _any_ directory within the repository. However, they must be wrapped
...
@@ -1949,13 +1949,9 @@ docker build service one:
...
@@ -1949,13 +1949,9 @@ docker build service one:
-service-one/**/*
-service-one/**/*
```
```
In the scenario above, if a merge request is created or updated that changes
In this scenario, if a merge request changes
either files in `service-one` directory or the `Dockerfile`, GitLab creates
files in the `service-one` directory or the `Dockerfile`, GitLab creates
and triggers the `docker build service one` job.
the `docker build service one` job.
Note that if [pipelines for merge requests](../merge_request_pipelines/index.md) is
combined with `only: [change]`, but `only: [merge_requests]` is omitted, there could be
unwanted behavior.
For example:
For example:
...
@@ -2776,8 +2772,8 @@ The cache is shared between jobs, so if you're using different
...
@@ -2776,8 +2772,8 @@ The cache is shared between jobs, so if you're using different
paths for different jobs, you should also set a different `cache:key`.
paths for different jobs, you should also set a different `cache:key`.
Otherwise cache content can be overwritten.
Otherwise cache content can be overwritten.
The `key` parameter defines the affinity of caching between jobs,
The `key` parameter defines the affinity of caching between jobs.
to have a single cache for all jobs, cache per-job, cache per-branch
You can have a single cache for all jobs, cache per-job, cache per-branch,
or any other way that fits your workflow. This way, you can fine tune caching,
or any other way that fits your workflow. This way, you can fine tune caching,
including caching data between different jobs or even different branches.
including caching data between different jobs or even different branches.
...
@@ -3381,7 +3377,7 @@ deploy:
...
@@ -3381,7 +3377,7 @@ deploy:
script:make deploy
script:make deploy
```
```
##### When a dependent job will fail
##### When a dependent job fails
> Introduced in GitLab 10.3.
> Introduced in GitLab 10.3.
...
@@ -3772,10 +3768,10 @@ starting, which reduces parallelization.
...
@@ -3772,10 +3768,10 @@ starting, which reduces parallelization.
#### Trigger a pipeline by API call
#### Trigger a pipeline by API call
Triggers can be used to force a rebuild of a specific branch, tag or commit,
To force a rebuild of a specific branch, tag, or commit, you can use an API call
with an API call when a pipeline gets created using a trigger token.
with a trigger token.
Not to be confused with the [`trigger`](#trigger) parameter.
The trigger token is different than the [`trigger`](#trigger) parameter.
[Read more in the triggers documentation.](../triggers/README.md)
[Read more in the triggers documentation.](../triggers/README.md)
...
@@ -3818,7 +3814,7 @@ step-2:
...
@@ -3818,7 +3814,7 @@ step-2:
step-3:
step-3:
stage:stage3
stage:stage3
script:
script:
-echo "Because step-2 can not be canceled, this step will never be canceled, even though set as interruptible."
-echo "Because step-2 can not be canceled, this step can never be canceled, even though it's set as interruptible."
interruptible:true
interruptible:true
```
```
...
@@ -3837,7 +3833,7 @@ Sometimes running multiple jobs or pipelines at the same time in an environment
...
@@ -3837,7 +3833,7 @@ Sometimes running multiple jobs or pipelines at the same time in an environment
can lead to errors during the deployment.
can lead to errors during the deployment.
To avoid these errors, the `resource_group` attribute can be used to ensure that
To avoid these errors, the `resource_group` attribute can be used to ensure that
the runner doesn't run certain jobs simultaneously. Resource groups behave similiar
the runner doesn't run certain jobs simultaneously. Resource groups behave similar
to semaphores in other programming languages.
to semaphores in other programming languages.
When the `resource_group` key is defined for a job in `.gitlab-ci.yml`,
When the `resource_group` key is defined for a job in `.gitlab-ci.yml`,
...
@@ -4003,7 +3999,7 @@ tags. These options cannot be used together, so choose one:
...
@@ -4003,7 +3999,7 @@ tags. These options cannot be used together, so choose one:
-'m1'
-'m1'
-'m2'
-'m2'
-'m3'
-'m3'
released_at:'2020-07-15T08:00:00Z'# Optional, will auto generate if not defined, or can use a variable.
released_at:'2020-07-15T08:00:00Z'# Optional, is auto generated if not defined, or can use a variable.
```
```
- To create a release automatically when commits are pushed or merged to the default branch,
- To create a release automatically when commits are pushed or merged to the default branch,
...
@@ -4049,7 +4045,7 @@ tags. These options cannot be used together, so choose one:
...
@@ -4049,7 +4045,7 @@ tags. These options cannot be used together, so choose one:
-'m1'
-'m1'
-'m2'
-'m2'
-'m3'
-'m3'
released_at:'2020-07-15T08:00:00Z'# Optional, will auto generate if not defined, or can use a variable.
released_at:'2020-07-15T08:00:00Z'# Optional, is auto generated if not defined, or can use a variable.