kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Merge branch 'docs/copy-edit-pipelines' into 'master'

Browse source 
Copyedit pipelines-related documentation

Closes #59006

See merge request gitlab-org/gitlab-ce!26198
This commit is contained in:
Achilleas Pipinellis 2019-03-19 08:17:17 +00:00
commit b920457821
3 changed files with 43 additions and 43 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/api/pipeline_schedules.md
View file

@ -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. > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/34518) in GitLab 10.0.

28
doc/ci/merge_request_pipelines/index.md
View file

@ -13,11 +13,11 @@ for merge requests.
## Configuring pipelines for merge requests ## Configuring pipelines for merge requests
To configure pipelines for merge request, add the `only: merge_requests` parameter to To configure pipelines for merge requests, add the `only: merge_requests` parameter to
the jobs that you want it to run only for merge requests. the jobs that you want to run only for merge requests.
Then, when developers create or update merge requests, a pipeline runs on Then, when developers create or update merge requests, a pipeline runs
their new commits at every push to GitLab. every time a commit is pushed to GitLab.
NOTE: **Note**: NOTE: **Note**:
If you use this feature with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md), 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. - 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. 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. 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: when a merge request was created or updated. For example:
![Merge request page](img/merge_request.png) ![Merge request page](img/merge_request.png)
@ -65,16 +65,16 @@ The same tag is shown on the pipeline's details:
## Excluding certain jobs ## Excluding certain jobs
The behavior of the `only: merge_requests` rule is such that _only_ jobs with The behavior of the `only: merge_requests` parameter is such that _only_ jobs with
that rule are run in the context of a merge request; no other jobs will be run. 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. for one or two.
Consider the following pipeline, with jobs `A`, `B`, and `C`. Imagine you want: Consider the following pipeline, with jobs `A`, `B`, and `C`. Imagine you want:
- All pipelines to always run `A` and `B` - All pipelines to always run `A` and `B`.
- Only want `C` to run for a merge request, - `C` to run only for merge requests.
To achieve this, you can configure your `.gitlab-ci.yml` file as follows: To achieve this, you can configure your `.gitlab-ci.yml` file as follows:
@ -102,10 +102,10 @@ C:
- merge_requests - merge_requests
``` ```
Because: Therefore:
- `A` and `B` are getting the `only:` rule to execute in all cases, they will always run. - Since `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 `C` specifies that it should only run for merge requests, it will not run for any pipeline
except a merge request pipeline. except a merge request pipeline.
As you can see, this will help you avoid a lot of boilerplate where you'd need As you can see, this will help you avoid a lot of boilerplate where you'd need

56
doc/ci/pipelines.md
View file

@ -4,26 +4,26 @@
## Introduction ## 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: Pipelines comprise:
- Jobs that define what to run. For example, code compilation or test runs. - 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. - 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:** 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 you may need to enable pipeline triggering in your project's
**Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates**. **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: 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. 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. and their statuses.
Pipeline graphs can be displayed in two different ways, depending on what page you Pipeline graphs can be displayed in two different ways, depending on the page you
access the graph. access the graph from.
NOTE: **Note:** NOTE: **Note:**
GitLab capitalizes the stages' names when shown in the [pipeline graphs](#pipeline-graphs). GitLab capitalizes the stages' names when shown in the [pipeline graphs](#pipeline-graphs).
### Regular 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: be found when you are on a [single pipeline page](#seeing-pipeline-status). For example:
![Pipelines example](img/pipelines.png) ![Pipelines example](img/pipelines.png)
### Pipeline mini graphs ### Pipeline mini graphs
Pipeline mini graphs takes less space and can give you a Pipeline mini graphs take less space and can tell you at a
quick glance if all jobs pass or something failed. The pipeline mini graph can quick glance if all jobs passed or something failed. The pipeline mini graph can
be found when you navigate to: be found when you navigate to:
- The pipelines index page. - The pipelines index page.
@ -101,7 +101,7 @@ For example:
### How pipeline duration is calculated ### How pipeline duration is calculated
Total running time for a given pipeline excludes retries and pending 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: 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. - B begins at 2 and ends at 4.
- C begins at 6 and ends at 7. - C begins at 6 and ends at 7.
Visually it can be viewed as: Visually, it can be viewed as:
```text ```text
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
@ -144,7 +144,7 @@ In particular:
- Jobs are the [basic configuration](yaml/README.html#introduction) component. - Jobs are the [basic configuration](yaml/README.html#introduction) component.
- Stages are defined using the [`stages`](yaml/README.html#stages) keyword. - 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 ### 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. 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]** ## Multi-project pipelines **[PREMIUM]**
@ -224,7 +224,7 @@ For more information, see [Multi-project pipelines](https://docs.gitlab.com/ee/c
## Working with pipelines ## 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. 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 pipeline widgets, in the merge requests and commit pages.
- In the job views, in the global and detailed views of a job. - 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) ![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 You can do this straight from the pipeline graph. Just click on the play button
to execute that particular job. to execute that particular job.
For example, your entire pipeline could run automatically, but require manual action to For example, your pipeline start automatically, but require manual action to
[deploy to production](environments.md#manually-deploying-to-environments). Below, the `production` [deploy to production](environments.md#manually-deploying-to-environments). In the example below, the `production`
stage has a job with a manual action. stage has a job with a manual action.
![Pipelines example](img/pipelines.png) ![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. 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%. - Users 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 - 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 last stable version. and [rolling](environments.md#rolling-back-changes) back to the last stable version.
![Pipelines example](img/pipeline_incremental_rollout.png) ![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) [allowed to merge or push](../user/project/protected_branches.md#using-the-allowed-to-merge-and-allowed-to-push-settings)
on that specific branch: 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 scheduled pipelines.
- Run pipelines using triggers. - Run pipelines using triggers.
- Trigger manual actions on existing pipelines. - 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 **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. sensitive information like deployment credentials and tokens.
**Runners** marked as **protected** can run jobs only on protected **Runners** marked as **protected** can run jobs only on protected