Merge branch 'docs/copy-edit-pipelines' into 'master'
Copyedit pipelines-related documentation Closes #59006 See merge request gitlab-org/gitlab-ce!26198
This commit is contained in:
commit
b920457821
|
@ -278,7 +278,7 @@ curl --request DELETE --header "PRIVATE-TOKEN: k5ESFgWY2Qf5xEvDcFxZ" "https://gi
|
|||
}
|
||||
```
|
||||
|
||||
## Pipeline schedule variable
|
||||
## Pipeline schedule variables
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/34518) in GitLab 10.0.
|
||||
|
||||
|
|
|
@ -13,11 +13,11 @@ for merge requests.
|
|||
|
||||
## Configuring pipelines for merge requests
|
||||
|
||||
To configure pipelines for merge request, add the `only: merge_requests` parameter to
|
||||
the jobs that you want it to run only for merge requests.
|
||||
To configure pipelines for merge requests, add the `only: merge_requests` parameter to
|
||||
the jobs that you want to run only for merge requests.
|
||||
|
||||
Then, when developers create or update merge requests, a pipeline runs on
|
||||
their new commits at every push to GitLab.
|
||||
Then, when developers create or update merge requests, a pipeline runs
|
||||
every time a commit is pushed to GitLab.
|
||||
|
||||
NOTE: **Note**:
|
||||
If you use this feature with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md),
|
||||
|
@ -51,10 +51,10 @@ After the merge request is updated with new commits:
|
|||
- The pipeline fetches the latest code from the source branch and run tests against it.
|
||||
|
||||
In the above example, the pipeline contains only `build` and `test` jobs.
|
||||
Since the `deploy` job doesn't have the `only: merge_requests` rule,
|
||||
Since the `deploy` job doesn't have the `only: merge_requests` parameter,
|
||||
deployment jobs will not happen in the merge request.
|
||||
|
||||
Pipelines tagged with **merge request** badge indicate that they were triggered
|
||||
Pipelines tagged with the **merge request** badge indicate that they were triggered
|
||||
when a merge request was created or updated. For example:
|
||||
|
||||
![Merge request page](img/merge_request.png)
|
||||
|
@ -65,16 +65,16 @@ The same tag is shown on the pipeline's details:
|
|||
|
||||
## Excluding certain jobs
|
||||
|
||||
The behavior of the `only: merge_requests` rule is such that _only_ jobs with
|
||||
that rule are run in the context of a merge request; no other jobs will be run.
|
||||
The behavior of the `only: merge_requests` parameter is such that _only_ jobs with
|
||||
that parameter are run in the context of a merge request; no other jobs will be run.
|
||||
|
||||
However, you may want to reverse this behaviour, having all of your jobs to run _except_
|
||||
However, you may want to reverse this behavior, having all of your jobs to run _except_
|
||||
for one or two.
|
||||
|
||||
Consider the following pipeline, with jobs `A`, `B`, and `C`. Imagine you want:
|
||||
|
||||
- All pipelines to always run `A` and `B`
|
||||
- Only want `C` to run for a merge request,
|
||||
- All pipelines to always run `A` and `B`.
|
||||
- `C` to run only for merge requests.
|
||||
|
||||
To achieve this, you can configure your `.gitlab-ci.yml` file as follows:
|
||||
|
||||
|
@ -102,10 +102,10 @@ C:
|
|||
- merge_requests
|
||||
```
|
||||
|
||||
Because:
|
||||
Therefore:
|
||||
|
||||
- `A` and `B` are getting the `only:` rule to execute in all cases, they will always run.
|
||||
- `C` specifies that it should only run for merge requests, it will not run for any pipeline
|
||||
- Since `A` and `B` are getting the `only:` rule to execute in all cases, they will always run.
|
||||
- Since `C` specifies that it should only run for merge requests, it will not run for any pipeline
|
||||
except a merge request pipeline.
|
||||
|
||||
As you can see, this will help you avoid a lot of boilerplate where you'd need
|
||||
|
|
|
@ -4,26 +4,26 @@
|
|||
|
||||
## Introduction
|
||||
|
||||
Pipelines are the top-level component of continuous integration, deployment, and delivery.
|
||||
Pipelines are the top-level component of continuous integration, delivery, and deployment.
|
||||
|
||||
Pipelines comprise:
|
||||
|
||||
- Jobs that define what to run. For example, code compilation or test runs.
|
||||
- Stages that define when and how to run. For example, that test run after code compilation.
|
||||
- Stages that define when and how to run. For example, that tests run only after code compilation.
|
||||
|
||||
Jobs in a stage are executed by [Runners](runners/README.md) in parallel, if there are enough concurrent [Runners](runners/README.md).
|
||||
Multiple jobs in the same stage are executed by [Runners](runners/README.md) in parallel, if there are enough concurrent [Runners](runners/README.md).
|
||||
|
||||
If the jobs in a stage:
|
||||
If all the jobs in a stage:
|
||||
|
||||
- Succeed, the pipeline moves on to the next stage.
|
||||
- Fail, the next stage is not (usually) executed.
|
||||
- Fail, the next stage is not (usually) executed and the pipeline ends early.
|
||||
|
||||
NOTE: **Note:**
|
||||
If you have a [mirrored repository where GitLab pulls from](https://docs.gitlab.com/ee/workflow/repository_mirroring.html#pulling-from-a-remote-repository-starter),
|
||||
If you have a [mirrored repository that GitLab pulls from](https://docs.gitlab.com/ee/workflow/repository_mirroring.html#pulling-from-a-remote-repository-starter),
|
||||
you may need to enable pipeline triggering in your project's
|
||||
**Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates**.
|
||||
|
||||
### Simple example
|
||||
### Simple pipeline example
|
||||
|
||||
As an example, imagine a pipeline consisting of four stages, executed in the following order:
|
||||
|
||||
|
@ -38,26 +38,26 @@ As an example, imagine a pipeline consisting of four stages, executed in the fol
|
|||
|
||||
Pipelines can be complex structures with many sequential and parallel jobs.
|
||||
|
||||
To make it easier to understand the flow of a pipeline, GitLab has pipeline graphs for viewing pipeline
|
||||
To make it easier to understand the flow of a pipeline, GitLab has pipeline graphs for viewing pipelines
|
||||
and their statuses.
|
||||
|
||||
Pipeline graphs can be displayed in two different ways, depending on what page you
|
||||
access the graph.
|
||||
Pipeline graphs can be displayed in two different ways, depending on the page you
|
||||
access the graph from.
|
||||
|
||||
NOTE: **Note:**
|
||||
GitLab capitalizes the stages' names when shown in the [pipeline graphs](#pipeline-graphs).
|
||||
|
||||
### Regular pipeline graphs
|
||||
|
||||
Regular pipeline graphs that show the names of the jobs of each stage. Regular pipeline graphs can
|
||||
Regular pipeline graphs show the names of the jobs of each stage. Regular pipeline graphs can
|
||||
be found when you are on a [single pipeline page](#seeing-pipeline-status). For example:
|
||||
|
||||
![Pipelines example](img/pipelines.png)
|
||||
|
||||
### Pipeline mini graphs
|
||||
|
||||
Pipeline mini graphs takes less space and can give you a
|
||||
quick glance if all jobs pass or something failed. The pipeline mini graph can
|
||||
Pipeline mini graphs take less space and can tell you at a
|
||||
quick glance if all jobs passed or something failed. The pipeline mini graph can
|
||||
be found when you navigate to:
|
||||
|
||||
- The pipelines index page.
|
||||
|
@ -101,7 +101,7 @@ For example:
|
|||
### How pipeline duration is calculated
|
||||
|
||||
Total running time for a given pipeline excludes retries and pending
|
||||
(queue) time.
|
||||
(queued) time.
|
||||
|
||||
Each job is represented as a `Period`, which consists of:
|
||||
|
||||
|
@ -120,7 +120,7 @@ In the example:
|
|||
- B begins at 2 and ends at 4.
|
||||
- C begins at 6 and ends at 7.
|
||||
|
||||
Visually it can be viewed as:
|
||||
Visually, it can be viewed as:
|
||||
|
||||
```text
|
||||
0 1 2 3 4 5 6 7
|
||||
|
@ -144,7 +144,7 @@ In particular:
|
|||
- Jobs are the [basic configuration](yaml/README.html#introduction) component.
|
||||
- Stages are defined using the [`stages`](yaml/README.html#stages) keyword.
|
||||
|
||||
For all available configuration options, see [GitLab CI/CD Pipeline Configuration Reference](yaml/README.md).
|
||||
For all available configuration options, see the [GitLab CI/CD Pipeline Configuration Reference](yaml/README.md).
|
||||
|
||||
### Settings and schedules
|
||||
|
||||
|
@ -214,7 +214,7 @@ GitLab supports configuring pipelines that run only for merge requests. For more
|
|||
|
||||
Pipeline status and test coverage report badges are available and configurable for each project.
|
||||
|
||||
For information on adding pipeline badges to project, see [Pipeline badges](../user/project/pipelines/settings.md#pipeline-badges).
|
||||
For information on adding pipeline badges to projects, see [Pipeline badges](../user/project/pipelines/settings.md#pipeline-badges).
|
||||
|
||||
## Multi-project pipelines **[PREMIUM]**
|
||||
|
||||
|
@ -224,7 +224,7 @@ For more information, see [Multi-project pipelines](https://docs.gitlab.com/ee/c
|
|||
|
||||
## Working with pipelines
|
||||
|
||||
Generally, pipelines are executed automatically and require no intervention once created.
|
||||
In general, pipelines are executed automatically and require no intervention once created.
|
||||
|
||||
However, there are instances where you'll need to interact with pipelines. These are documented below.
|
||||
|
||||
|
@ -277,7 +277,7 @@ can quickly check the reason it failed:
|
|||
- In the pipeline widgets, in the merge requests and commit pages.
|
||||
- In the job views, in the global and detailed views of a job.
|
||||
|
||||
In any case, if you hover over the failed job you can see the reason it failed.
|
||||
In each place, if you hover over the failed job you can see the reason it failed.
|
||||
|
||||
![Pipeline detail](img/job_failure_reason.png)
|
||||
|
||||
|
@ -294,8 +294,8 @@ allow you to require manual interaction before moving forward in the pipeline.
|
|||
You can do this straight from the pipeline graph. Just click on the play button
|
||||
to execute that particular job.
|
||||
|
||||
For example, your entire pipeline could run automatically, but require manual action to
|
||||
[deploy to production](environments.md#manually-deploying-to-environments). Below, the `production`
|
||||
For example, your pipeline start automatically, but require manual action to
|
||||
[deploy to production](environments.md#manually-deploying-to-environments). In the example below, the `production`
|
||||
stage has a job with a manual action.
|
||||
|
||||
![Pipelines example](img/pipelines.png)
|
||||
|
@ -309,11 +309,11 @@ delay a job's execution for a certain period.
|
|||
|
||||
This is especially useful for timed incremental rollout where new code is rolled out gradually.
|
||||
|
||||
For example, if you start rolling out new code and users:
|
||||
For example, if you start rolling out new code and:
|
||||
|
||||
- Do not experience trouble, GitLab can automatically complete the deployment from 0% to 100%.
|
||||
- Experience trouble with the new code, you can stop the timed incremental rollout by canceling the pipeline
|
||||
and [rolling](environments.md#rolling-back-changes) back to last stable version.
|
||||
- Users do not experience trouble, GitLab can automatically complete the deployment from 0% to 100%.
|
||||
- Users experience trouble with the new code, you can stop the timed incremental rollout by canceling the pipeline
|
||||
and [rolling](environments.md#rolling-back-changes) back to the last stable version.
|
||||
|
||||
![Pipelines example](img/pipeline_incremental_rollout.png)
|
||||
|
||||
|
@ -336,14 +336,14 @@ The following actions are allowed on protected branches only if the user is
|
|||
[allowed to merge or push](../user/project/protected_branches.md#using-the-allowed-to-merge-and-allowed-to-push-settings)
|
||||
on that specific branch:
|
||||
|
||||
- Run manual pipelines (using [Web UI](#manually-executing-pipelines) or pipelines API).
|
||||
- Run manual pipelines (using the [Web UI](#manually-executing-pipelines) or pipelines API).
|
||||
- Run scheduled pipelines.
|
||||
- Run pipelines using triggers.
|
||||
- Trigger manual actions on existing pipelines.
|
||||
- Retry/cancel existing jobs (using Web UI or pipelines API).
|
||||
- Retry or cancel existing jobs (using the Web UI or pipelines API).
|
||||
|
||||
**Variables** marked as **protected** are accessible only to jobs that
|
||||
run on protected branches, avoiding untrusted users to get unintended access to
|
||||
run on protected branches, preventing untrusted users getting unintended access to
|
||||
sensitive information like deployment credentials and tokens.
|
||||
|
||||
**Runners** marked as **protected** can run jobs only on protected
|
||||
|
|
Loading…
Reference in New Issue