Refactor and restructure pipelines landing page
- Also has other minor improvements.
This commit is contained in:
parent
11c8b5a18b
commit
6e4108b7ba
7 changed files with 301 additions and 245 deletions
|
@ -1,4 +1,4 @@
|
|||
# Pipeline schedules
|
||||
# Pipeline schedules API
|
||||
|
||||
You can read more about [pipeline schedules](../user/project/pipelines/schedules.md).
|
||||
|
||||
|
@ -280,7 +280,7 @@ curl --request DELETE --header "PRIVATE-TOKEN: k5ESFgWY2Qf5xEvDcFxZ" "https://gi
|
|||
|
||||
## Pipeline schedule variable
|
||||
|
||||
> [Introduced][ce-34518] in GitLab 10.0.
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/34518) in GitLab 10.0.
|
||||
|
||||
## Create a new pipeline schedule variable
|
||||
|
||||
|
@ -358,5 +358,3 @@ curl --request DELETE --header "PRIVATE-TOKEN: k5ESFgWY2Qf5xEvDcFxZ" "https://gi
|
|||
"value": "updated value"
|
||||
}
|
||||
```
|
||||
|
||||
[ce-34518]: https://gitlab.com/gitlab-org/gitlab-ce/issues/34518
|
|
@ -45,7 +45,7 @@ into more features:
|
|||
|
||||
| Topic | Description |
|
||||
|:--------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Introduction to pipelines and jobs](pipelines.md) | Provides an overview of GitLab CI/CD and jobs. |
|
||||
| [Creating and using CI/CD pipelines](pipelines.md) | Understand, visualize, create, and use CI/CD pipelines. |
|
||||
| [CI/CD Variables](variables/README.md) | How environment variables can be configured and made available in pipelines. |
|
||||
| [Where variables can be used](variables/where_variables_can_be_used.md) | A deeper look into where and how CI/CD variables can be used. |
|
||||
| [User](../user/permissions.md#gitlab-cicd-permissions) and [job](../user/permissions.md#job-permissions) permissions | Learn about the access levels a user can have for performing certain CI actions. |
|
||||
|
|
Binary file not shown.
Before Width: | Height: | Size: 15 KiB |
Binary file not shown.
Before Width: | Height: | Size: 12 KiB |
|
@ -9,13 +9,18 @@ For example, unit tests, lint checks, and [Review Apps](../review_apps/index.md)
|
|||
are often used in this cycle.
|
||||
|
||||
With pipelines for merge requests, you can design a specific pipeline structure
|
||||
for merge requests. All you need to do is just adding `only: [merge_requests]` to
|
||||
the jobs that you want it to run for only merge requests.
|
||||
Every time, when developers create or update merge requests, a pipeline runs on
|
||||
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.
|
||||
|
||||
Then, when developers create or update merge requests, a pipeline runs on
|
||||
their new commits at every push to GitLab.
|
||||
|
||||
NOTE: **Note**:
|
||||
If you use both this feature and [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),
|
||||
pipelines for merge requests take precedence over the other regular pipelines.
|
||||
|
||||
For example, consider the following [`.gitlab-ci.yml`](../yaml/README.md):
|
||||
|
@ -40,15 +45,17 @@ deploy:
|
|||
script: ./deploy
|
||||
```
|
||||
|
||||
After the merge request is updated with new commits, GitLab detects that changes
|
||||
have occurred and creates a new pipeline for the merge request.
|
||||
The pipeline fetches the latest code from the source branch and run tests against it.
|
||||
After the merge request is updated with new commits:
|
||||
|
||||
- GitLab detects that changes have occurred and creates a new pipeline for the merge request.
|
||||
- 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` rule,
|
||||
deployment jobs will not happen in the merge request.
|
||||
|
||||
Pipelines tagged as **merge request** indicate that they were triggered
|
||||
when a merge request was created or updated.
|
||||
Pipelines tagged with **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)
|
||||
|
||||
|
@ -62,9 +69,14 @@ 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.
|
||||
|
||||
However, you may want to reverse this behaviour, having all of your jobs to run _except_
|
||||
for one or two. Consider the following pipeline, with jobs `A`, `B`, and `C`. If you want
|
||||
all pipelines to always run `A` and `B`, but only want `C` to run for a merge request,
|
||||
you can configure your `.gitlab-ci.yml` file as follows:
|
||||
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,
|
||||
|
||||
To achieve this, you can configure your `.gitlab-ci.yml` file as follows:
|
||||
|
||||
``` yaml
|
||||
.only-default: &only-default
|
||||
|
@ -90,9 +102,11 @@ C:
|
|||
- merge_requests
|
||||
```
|
||||
|
||||
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, so for any
|
||||
pipeline except a merge request pipeline, it will not run.
|
||||
Because:
|
||||
|
||||
- `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
|
||||
except a merge request pipeline.
|
||||
|
||||
As you can see, this will help you avoid a lot of boilerplate where you'd need
|
||||
to add that `only:` rule to all of your jobs in order to make them always run. You
|
||||
|
|
|
@ -1,222 +1,87 @@
|
|||
# Introduction to pipelines and jobs
|
||||
# Creating and using CI/CD pipelines
|
||||
|
||||
> Introduced in GitLab 8.8.
|
||||
|
||||
## Introduction
|
||||
|
||||
Pipelines are the top-level component of continuous integration, deployment, and delivery.
|
||||
|
||||
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.
|
||||
|
||||
Jobs in a 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:
|
||||
|
||||
- Succeed, the pipeline moves on to the next stage.
|
||||
- Fail, the next stage is not (usually) executed.
|
||||
|
||||
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),
|
||||
you may need to enable pipeline triggering in your project's
|
||||
**Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates**.
|
||||
|
||||
## Pipelines
|
||||
### Simple example
|
||||
|
||||
A pipeline is a group of [jobs] that get executed in [stages].
|
||||
All of the jobs in a stage are executed in parallel (if there are enough
|
||||
concurrent [Runners]), and if they all succeed, the pipeline moves on to the
|
||||
next stage. If one of the jobs fails, the next stage is not (usually)
|
||||
executed. You can access the pipelines page in your project's **Pipelines** tab.
|
||||
As an example, imagine a pipeline consisting of four stages, executed in the following order:
|
||||
|
||||
In the following image you can see that the pipeline consists of four stages
|
||||
(`build`, `test`, `staging`, `production`) each one having one or more jobs.
|
||||
- `build`, with a job called `compile`.
|
||||
- `test`, with two jobs called `test` and `test2`.
|
||||
- `staging`, with a job called `deploy-to-stage`.
|
||||
- `production`, with a job called `deploy-to-prod`.
|
||||
|
||||
>**Note:**
|
||||
GitLab capitalizes the stages' names when shown in the [pipeline graphs](#pipeline-graphs).
|
||||
## Visualizing pipelines
|
||||
|
||||
![Pipelines example](img/pipelines.png)
|
||||
|
||||
## Types of pipelines
|
||||
|
||||
There are three types of pipelines that often use the single shorthand of "pipeline". People often talk about them as if each one is "the" pipeline, but really, they're just pieces of a single, comprehensive pipeline.
|
||||
|
||||
![Types of Pipelines](img/types-of-pipelines.png)
|
||||
|
||||
1. **CI Pipeline**: Build and test stages defined in `.gitlab-ci.yml`.
|
||||
1. **Deploy Pipeline**: Deploy stage(s) defined in `.gitlab-ci.yml` The flow of deploying code to servers through various stages: e.g. development to staging to production.
|
||||
1. **Project Pipeline**: Cross-project CI dependencies [triggered via API][triggers], particularly for micro-services, but also for complicated build dependencies: e.g. api -> front-end, ce/ee -> omnibus.
|
||||
|
||||
## Development workflows
|
||||
|
||||
Pipelines accommodate several development workflows:
|
||||
|
||||
1. **Branch Flow** (e.g. different branch for dev, qa, staging, production).
|
||||
1. **Trunk-based Flow** (e.g. feature branches and single master branch, possibly with tags for releases).
|
||||
1. **Fork-based Flow** (e.g. merge requests come from forks).
|
||||
|
||||
Example continuous delivery flow:
|
||||
|
||||
![CD Flow](img/pipelines-goal.png)
|
||||
|
||||
## Jobs
|
||||
|
||||
Jobs can be defined in the [`.gitlab-ci.yml`][jobs-yaml] file. Not to be
|
||||
confused with a `build` job or `build` stage.
|
||||
|
||||
## Defining pipelines
|
||||
|
||||
Pipelines are defined in `.gitlab-ci.yml` by specifying [jobs] that run in
|
||||
[stages].
|
||||
|
||||
See the reference [documentation for jobs](yaml/README.md#jobs).
|
||||
|
||||
## Manually executing pipelines
|
||||
|
||||
Pipelines can be manually executed, with predefined or manually-specified [variables](variables/README.md).
|
||||
|
||||
To execute a pipeline manually:
|
||||
|
||||
1. Navigate to your project's **CI/CD > Pipelines**.
|
||||
1. Click on the **Run Pipeline** button.
|
||||
1. Select the branch to run the pipeline for and enter any environment variables required for the pipeline run.
|
||||
|
||||
## Seeing pipeline status
|
||||
|
||||
You can find the current and historical pipeline runs under your project's
|
||||
**Pipelines** tab. Clicking on a pipeline will show the jobs that were run for
|
||||
that pipeline.
|
||||
|
||||
![Pipelines index page](img/pipelines_index.png)
|
||||
|
||||
## Seeing job status
|
||||
|
||||
When you visit a single pipeline you can see the related jobs for that pipeline.
|
||||
Clicking on an individual job will show you its job trace, and allow you to
|
||||
cancel the job, retry it, or erase the job trace.
|
||||
|
||||
![Pipelines example](img/pipelines.png)
|
||||
|
||||
## Seeing the failure reason for jobs
|
||||
|
||||
> [Introduced][ce-17782] in GitLab 10.7.
|
||||
|
||||
When a pipeline fails or is allowed to fail, there are several places where you
|
||||
can quickly check the reason it failed:
|
||||
|
||||
- **In the pipeline graph** present on the pipeline detail view.
|
||||
- **In the pipeline widgets** present in the merge requests and commit pages.
|
||||
- **In the job views** present 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.
|
||||
|
||||
![Pipeline detail](img/job_failure_reason.png)
|
||||
|
||||
From [GitLab 10.8][ce-17814] you can also see the reason it failed on the Job detail page.
|
||||
|
||||
## Pipeline graphs
|
||||
|
||||
> [Introduced][ce-5742] in GitLab 8.11.
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5742) in GitLab 8.11.
|
||||
|
||||
Pipelines can be complex structures with many sequential and parallel jobs.
|
||||
To make it a little easier to see what is going on, you can view a graph
|
||||
of a single pipeline and its status.
|
||||
|
||||
A pipeline graph can be shown in two different ways depending on what page you
|
||||
are on.
|
||||
To make it easier to understand the flow of a pipeline, GitLab has pipeline graphs for viewing pipeline
|
||||
and their statuses.
|
||||
|
||||
---
|
||||
Pipeline graphs can be displayed in two different ways, depending on what page you
|
||||
access the graph.
|
||||
|
||||
The regular pipeline graph that shows the names of the jobs of each stage can
|
||||
be found when you are on a [single pipeline page](#seeing-pipeline-status).
|
||||
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
|
||||
be found when you are on a [single pipeline page](#seeing-pipeline-status). For example:
|
||||
|
||||
![Pipelines example](img/pipelines.png)
|
||||
|
||||
Then, there is the pipeline mini graph which takes less space and can give you a
|
||||
### 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
|
||||
be found when you visit:
|
||||
be found when you navigate to:
|
||||
|
||||
- The pipelines index page.
|
||||
- A single commit page.
|
||||
- A merge request page.
|
||||
|
||||
That way, you can see all related jobs for a single commit and the net result
|
||||
Pipeline mini graphs allow you to see all related jobs for a single commit and the net result
|
||||
of each stage of your pipeline. This allows you to quickly see what failed and
|
||||
fix it. Stages in pipeline mini graphs are collapsible. Hover your mouse over
|
||||
them and click to expand their jobs.
|
||||
fix it.
|
||||
|
||||
| **Mini graph** | **Mini graph expanded** |
|
||||
| :------------: | :---------------------: |
|
||||
Stages in pipeline mini graphs are collapsible. Hover your mouse over them and click to expand their jobs.
|
||||
|
||||
| Mini graph | Mini graph expanded |
|
||||
|:-------------------------------------------------------------|:---------------------------------------------------------------|
|
||||
| ![Pipelines mini graph](img/pipelines_mini_graph_simple.png) | ![Pipelines mini graph extended](img/pipelines_mini_graph.png) |
|
||||
|
||||
### Grouping similar jobs in the pipeline graph
|
||||
### Job ordering in pipeline graphs
|
||||
|
||||
> [Introduced][ce-6242] in GitLab 8.12.
|
||||
Job ordering depends on the type of pipeline graph. For [regular pipeline graphs](#regular-pipeline-graphs), jobs are sorted by name.
|
||||
|
||||
If you have many similar jobs, your pipeline graph becomes very long and hard
|
||||
to read. For that reason, similar jobs can automatically be grouped together.
|
||||
If the job names are formatted in certain ways, they will be collapsed into
|
||||
a single group in regular pipeline graphs (not the mini graphs).
|
||||
You'll know when a pipeline has grouped jobs if you don't see the retry or
|
||||
cancel button inside them. Hovering over them will show the number of grouped
|
||||
jobs. Click to expand them.
|
||||
For [pipeline mini graphs](#pipeline-mini-graphs) ([introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9760)
|
||||
in GitLab 9.0), jobs are sorted by severity and then by name.
|
||||
|
||||
![Grouped pipelines](img/pipelines_grouped.png)
|
||||
|
||||
The basic requirements is that there are two numbers separated with one of
|
||||
the following (you can even use them interchangeably):
|
||||
|
||||
- A space (` `)
|
||||
- A slash (`/`)
|
||||
- A colon (`:`)
|
||||
|
||||
>**Note:**
|
||||
More specifically, [it uses][regexp] this regular expression: `\d+[\s:\/\\]+\d+\s*`.
|
||||
|
||||
The jobs will be ordered by comparing those two numbers from left to right. You
|
||||
usually want the first to be the index and the second the total.
|
||||
|
||||
For example, the following jobs will be grouped under a job named `test`:
|
||||
|
||||
- `test 0 3` => `test`
|
||||
- `test 1 3` => `test`
|
||||
- `test 2 3` => `test`
|
||||
|
||||
The following jobs will be grouped under a job named `test ruby`:
|
||||
|
||||
- `test 1:2 ruby` => `test ruby`
|
||||
- `test 2:2 ruby` => `test ruby`
|
||||
|
||||
The following jobs will be grouped under a job named `test ruby` as well:
|
||||
|
||||
- `1/3 test ruby` => `test ruby`
|
||||
- `2/3 test ruby` => `test ruby`
|
||||
- `3/3 test ruby` => `test ruby`
|
||||
|
||||
### Manual actions from the pipeline graph
|
||||
|
||||
> [Introduced][ce-7931] in GitLab 8.15.
|
||||
|
||||
[Manual actions][manual] allow you to require manual interaction before moving
|
||||
forward with a particular job in CI. Your entire pipeline can run automatically,
|
||||
but the actual [deploy to production][env-manual] will require a click.
|
||||
|
||||
You can do this straight from the pipeline graph. Just click on the play button
|
||||
to execute that particular job. For example, in the image below, the `production`
|
||||
stage has a job with a manual action.
|
||||
|
||||
![Pipelines example](img/pipelines.png)
|
||||
|
||||
### Delay a particular job in the pipeline graph
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21767) in GitLab 11.4.
|
||||
|
||||
When you do not want to run a job immediately, you can [delay the job to run after a certain period](yaml/README.md#whendelayed).
|
||||
This is especially useful for timed incremental rollout that new code is rolled out gradually.
|
||||
For example, if you start rolling out new code and users do not experience trouble, GitLab automatically completes the deployment from 0% to 100%.
|
||||
Alternatively, if you start rolling out and you noticed that a few users experience trouble with the version,
|
||||
you can stop the timed incremental rollout by canceling the pipeline, and [rolling](environments.md#rolling-back-changes) it back to the stable version.
|
||||
|
||||
![Pipelines example](img/pipeline_incremental_rollout.png)
|
||||
|
||||
### Ordering of jobs in pipeline graphs
|
||||
|
||||
**Regular pipeline graph**
|
||||
|
||||
In the single pipeline page, jobs are sorted by name.
|
||||
|
||||
**Mini pipeline graph**
|
||||
|
||||
> [Introduced][ce-9760] in GitLab 9.0.
|
||||
|
||||
In the pipeline mini graphs, the jobs are sorted first by severity and then
|
||||
by name. The order of severity is:
|
||||
The order of severity is:
|
||||
|
||||
- failed
|
||||
- warning
|
||||
|
@ -229,43 +94,238 @@ by name. The order of severity is:
|
|||
- skipped
|
||||
- created
|
||||
|
||||
For example:
|
||||
|
||||
![Pipeline mini graph sorting](img/pipelines_mini_graph_sorting.png)
|
||||
|
||||
## How the pipeline duration is calculated
|
||||
### How pipeline duration is calculated
|
||||
|
||||
Total running time for a given pipeline would exclude retries and pending
|
||||
(queue) time. We could reduce this problem down to finding the union of
|
||||
periods.
|
||||
Total running time for a given pipeline excludes retries and pending
|
||||
(queue) time.
|
||||
|
||||
So each job would be represented as a `Period`, which consists of
|
||||
`Period#first` as when the job started and `Period#last` as when the
|
||||
job was finished. A simple example here would be:
|
||||
Each job is represented as a `Period`, which consists of:
|
||||
|
||||
- `Period#first` (when the job started).
|
||||
- `Period#last` (when the job finished).
|
||||
|
||||
A simple example is:
|
||||
|
||||
- A (1, 3)
|
||||
- B (2, 4)
|
||||
- C (6, 7)
|
||||
|
||||
Here A begins from 1, and ends to 3. B begins from 2, and ends to 4.
|
||||
C begins from 6, and ends to 7. Visually it could be viewed as:
|
||||
In the example:
|
||||
|
||||
```
|
||||
- A begins at 1 and ends at 3.
|
||||
- B begins at 2 and ends at 4.
|
||||
- C begins at 6 and ends at 7.
|
||||
|
||||
Visually it can be viewed as:
|
||||
|
||||
```text
|
||||
0 1 2 3 4 5 6 7
|
||||
AAAAAAA
|
||||
BBBBBBB
|
||||
CCCC
|
||||
```
|
||||
|
||||
The union of A, B, and C would be (1, 4) and (6, 7), therefore the
|
||||
total running time should be:
|
||||
The union of A, B, and C is (1, 4) and (6, 7). Therefore, the total running time is:
|
||||
|
||||
```
|
||||
```text
|
||||
(4 - 1) + (7 - 6) => 4
|
||||
```
|
||||
|
||||
## Badges
|
||||
## Configuring pipelines
|
||||
|
||||
Pipeline status and test coverage report badges are available. You can find their
|
||||
respective link in the [Pipelines settings] page.
|
||||
Pipelines, and their component jobs and stages, are defined in the [`.gitlab-ci.yml`](yaml/README.md) file for each project.
|
||||
|
||||
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).
|
||||
|
||||
### Settings and schedules
|
||||
|
||||
In addition to configuring jobs through `.gitlab-ci.yml`, additional configuration options are available
|
||||
through the GitLab UI:
|
||||
|
||||
- Pipeline settings for each project. For more information, see [Pipeline settings](../user/project/pipelines/settings.md).
|
||||
- Schedules for pipelines. For more information, see [Pipeline schedules](../user/project/pipelines/schedules.md).
|
||||
|
||||
### Grouping jobs
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6242) in GitLab 8.12.
|
||||
|
||||
If you have many similar jobs, your [pipeline graph](#visualizing-pipelines) becomes long and hard
|
||||
to read.
|
||||
|
||||
For that reason, similar jobs can automatically be grouped together.
|
||||
If the job names are formatted in certain ways, they will be collapsed into
|
||||
a single group in regular pipeline graphs (not the mini graphs).
|
||||
|
||||
You'll know when a pipeline has grouped jobs if you don't see the retry or
|
||||
cancel button inside them. Hovering over them will show the number of grouped
|
||||
jobs. Click to expand them.
|
||||
|
||||
![Grouped pipelines](img/pipelines_grouped.png)
|
||||
|
||||
#### Configuring grouping
|
||||
|
||||
In the pipeline [configuration file](yaml/README.md), job names must include two numbers separated with one of
|
||||
the following (you can even use them interchangeably):
|
||||
|
||||
- A space.
|
||||
- A slash (`/`).
|
||||
- A colon (`:`).
|
||||
|
||||
NOTE: **Note:**
|
||||
More specifically, it uses [this](https://gitlab.com/gitlab-org/gitlab-ce/blob/2f3dc314f42dbd79813e6251792853bc231e69dd/app/models/commit_status.rb#L99) regular expression: `\d+[\s:\/\\]+\d+\s*`.
|
||||
|
||||
#### How grouping works
|
||||
|
||||
The jobs will be ordered by comparing those two numbers from left to right. You
|
||||
usually want the first to be the index and the second the total.
|
||||
|
||||
For example, the following jobs will be grouped under a job named `test`:
|
||||
|
||||
- `test 0 3`
|
||||
- `test 1 3`
|
||||
- `test 2 3`
|
||||
|
||||
The following jobs will be grouped under a job named `test ruby`:
|
||||
|
||||
- `test 1:2 ruby`
|
||||
- `test 2:2 ruby`
|
||||
|
||||
The following jobs will be grouped under a job named `test ruby` as well:
|
||||
|
||||
- `1/3 test ruby`
|
||||
- `2/3 test ruby`
|
||||
- `3/3 test ruby`
|
||||
|
||||
### Pipelines for merge requests
|
||||
|
||||
GitLab supports configuring pipelines that run only for merge requests. For more information, see
|
||||
[Pipelines for merge requests](merge_request_pipelines/index.md).
|
||||
|
||||
### Badges
|
||||
|
||||
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).
|
||||
|
||||
## Multi-project pipelines **[PREMIUM]**
|
||||
|
||||
Pipelines for different projects can be combined and visualized together.
|
||||
|
||||
For more information, see [Multi-project pipelines](https://docs.gitlab.com/ee/ci/multi_project_pipelines.html).
|
||||
|
||||
## Working with pipelines
|
||||
|
||||
Generally, 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.
|
||||
|
||||
### Manually executing pipelines
|
||||
|
||||
Pipelines can be manually executed, with predefined or manually-specified [variables](variables/README.md).
|
||||
|
||||
You might do this if the results of a pipeline (for example, a code build) is required outside the normal
|
||||
operation of the pipeline.
|
||||
|
||||
To execute a pipeline manually:
|
||||
|
||||
1. Navigate to your project's **CI/CD > Pipelines**.
|
||||
1. Click on the **Run Pipeline** button.
|
||||
1. On the **Run Pipeline** page:
|
||||
1. Select the branch to run the pipeline for in the **Create for** field.
|
||||
1. Enter any [environment variables](variables/README.md) required for the pipeline run.
|
||||
1. Click the **Create pipeline** button.
|
||||
|
||||
The pipeline will execute the jobs as configured.
|
||||
|
||||
### Accessing pipelines
|
||||
|
||||
You can find the current and historical pipeline runs under your project's
|
||||
**CI/CD > Pipelines** page. Clicking on a pipeline will show the jobs that were run for
|
||||
that pipeline.
|
||||
|
||||
![Pipelines index page](img/pipelines_index.png)
|
||||
|
||||
You can also access pipelines for a merge request by navigating to its **Pipelines** tab.
|
||||
|
||||
### Accessing individual jobs
|
||||
|
||||
When you access a pipeline, you can see the related jobs for that pipeline.
|
||||
|
||||
Clicking on an individual job will show you its job trace, and allow you to:
|
||||
|
||||
- Cancel the job.
|
||||
- Retry the job.
|
||||
- Erase the job trace.
|
||||
|
||||
### Seeing the failure reason for jobs
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17782) in GitLab 10.7.
|
||||
|
||||
When a pipeline fails or is allowed to fail, there are several places where you
|
||||
can quickly check the reason it failed:
|
||||
|
||||
- In the pipeline graph, on the pipeline detail view.
|
||||
- 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.
|
||||
|
||||
![Pipeline detail](img/job_failure_reason.png)
|
||||
|
||||
From [GitLab 10.8](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17814),
|
||||
you can also see the reason it failed on the Job detail page.
|
||||
|
||||
### Manual actions from pipeline graphs
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7931) in GitLab 8.15.
|
||||
|
||||
Manual actions, configured using the [`when:manual`](yaml/README.md#whenmanual) parameter,
|
||||
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`
|
||||
stage has a job with a manual action.
|
||||
|
||||
![Pipelines example](img/pipelines.png)
|
||||
|
||||
### Delay a job in a pipeline graph
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21767) in GitLab 11.4.
|
||||
|
||||
When you do not want to run a job immediately, you can use the [`when:deplayed`](yaml/README.md#whendelayed) parameter to
|
||||
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:
|
||||
|
||||
- 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.
|
||||
|
||||
![Pipelines example](img/pipeline_incremental_rollout.png)
|
||||
|
||||
### Using the API
|
||||
|
||||
GitLab provides API endpoints to:
|
||||
|
||||
- Perform basic functions. For more information, see [Pipelines API](../api/pipelines.md).
|
||||
- Maintain pipeline schedules. For more information, see [Pipeline schedules API](../api/pipeline_schedules.md).
|
||||
- Trigger pipeline runs. For more information, see:
|
||||
- [Triggering pipelines through the API](triggers/README.md).
|
||||
- [Pipeline triggers API](../api/pipeline_triggers.md).
|
||||
|
||||
## Security on protected branches
|
||||
|
||||
|
@ -276,11 +336,11 @@ 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 **scheduled pipelines**.
|
||||
- Run pipelines using **triggers**.
|
||||
- Trigger **manual actions** on existing pipelines.
|
||||
- **Retry/cancel** existing jobs (using Web UI or Pipelines API).
|
||||
- Run manual pipelines (using [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).
|
||||
|
||||
**Variables** marked as **protected** are accessible only to jobs that
|
||||
run on protected branches, avoiding untrusted users to get unintended access to
|
||||
|
@ -291,19 +351,3 @@ branches, avoiding untrusted code to be executed on the protected runner and
|
|||
preserving deployment keys and other credentials from being unintentionally
|
||||
accessed. In order to ensure that jobs intended to be executed on protected
|
||||
runners will not use regular runners, they must be tagged accordingly.
|
||||
|
||||
[jobs]: #jobs
|
||||
[jobs-yaml]: yaml/README.md#jobs
|
||||
[manual]: yaml/README.md#whenmanual
|
||||
[env-manual]: environments.md#manually-deploying-to-environments
|
||||
[stages]: yaml/README.md#stages
|
||||
[runners]: runners/README.html
|
||||
[pipelines settings]: ../user/project/pipelines/settings.md
|
||||
[triggers]: triggers/README.md
|
||||
[ce-5742]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5742
|
||||
[ce-6242]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6242
|
||||
[ce-7931]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7931
|
||||
[ce-9760]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9760
|
||||
[ce-17782]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17782
|
||||
[ce-17814]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17814
|
||||
[regexp]: https://gitlab.com/gitlab-org/gitlab-ce/blob/2f3dc314f42dbd79813e6251792853bc231e69dd/app/models/commit_status.rb#L99
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
# Merge When Pipeline Succeeds
|
||||
# Merge when pipeline succeeds
|
||||
|
||||
When reviewing a merge request that looks ready to merge but still has one or
|
||||
more CI jobs running, you can set it to be merged automatically when the
|
||||
|
|
Loading…
Reference in a new issue