Follow-up from "Refactor and restructure pipelines landing page"

The following discussions from !26079 (merged) should be addressed:

@Ravlen started a discussion:
```
## Pipeline schedule variables
```

To configure pipelines for merge requests, add the `only: merge_requests` parameter to

@Ravlen started a discussion:

the jobs that you want to run only for merge requests.

@Ravlen started a discussion:

Then, when developers create or update merge requests, a pipeline runs

@Ravlen started a discussion:

every time a commit is pushed to GitLab.

@Ravlen started a discussion:

Not sure, but I wonder if starts a new pipeline or runs a new pipeline would sound slightly better?

@Ravlen started a discussion:

Should this be parameter, as on line 16?
Since the `deploy` job doesn't have the `only: merge_requests` parameter,

@Ravlen started a discussion:

Pipelines tagged with the **merge request** badge indicate that they were triggered

@Ravlen started a discussion:

However, you may want to reverse this behaviour, having all of your jobs run *except*

@Ravlen started a discussion:

- Only want `C` to run for merge requests,

- Want `C` to only run for merge requests,

@Ravlen started a discussion:
```
Therefore:
```

@Ravlen started a discussion:

- Since `A` and `B` are getting the `only:` rule to execute in all cases, they will always run.

@Ravlen started a discussion:

- Since `C` specifies that it should only run for merge requests, it will not run for any pipeline

@Ravlen started a discussion:

Not strictly necessary, but why not...

Pipelines are the top-level component of continuous integration, delivery, and deployment.

@Ravlen started a discussion:

- Stages that define when and how to run. For example, a test that runs only after code successfully compiles.

@Ravlen started a discussion:

Multiple jobs in the same stage are executed by [Runners](runners/README.md) in parallel, if there are enough concurrent [Runners](runners/README.md).

@Ravlen started a discussion:
```
If all the jobs in a stage:
```

@Ravlen started a discussion:

- Fail, the next stage is not (usually) executed, and the pipeline stops.

@Ravlen started a discussion:

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),

@Ravlen started a discussion:

you may want to enable pipeline triggering in your project's

@Ravlen started a discussion:
```
### Simple Pipeline example
```
@Ravlen started a discussion:

Might be good to make these numbered instead of bullets.

@Ravlen started a discussion:

To make it easier to understand the flow of a pipeline, GitLab has pipeline graphs for viewing pipelines

@Ravlen started a discussion:

Pipeline graphs can be displayed in two different ways, depending on which page you

@Ravlen started a discussion:
```
access the graph from.
```

@Ravlen started a discussion:

Regular pipeline graphs show the names of the jobs of each stage. Regular pipeline graphs can

@Ravlen started a discussion:

Pipeline mini graphs take less space and can tell you at a

@Ravlen started a discussion:

quick glance if all jobs passed or if something failed. The pipeline mini graph can

@Ravlen started a discussion:
```
(queued) time.
```
@Ravlen started a discussion:
```
Visually, it can be viewed as:
```

@Ravlen started a discussion:

For all available configuration options, see the [GitLab CI/CD Pipeline Configuration Reference](yaml/README.md).

@Ravlen started a discussion:

If the job names are formatted in [certain ways](#how-grouping-works), they will be collapsed into

@Ravlen started a discussion:

related groups in regular pipeline graphs (not the mini graphs).

@Ravlen started a discussion:

For information on adding pipeline badges to projects, see [Pipeline badges](../user/project/pipelines/settings.md#pipeline-badges).

@Ravlen started a discussion:

In general, pipelines are executed automatically and require no intervention once created.

@Ravlen started a discussion:

In each place, if you hover over the failed job you can see the reason it failed.

@Ravlen started a discussion:

For example, your pipeline could run automatically, but require manual action for the final,

@Ravlen started a discussion:

[deploy to production](environments.md#manually-deploying-to-environments) stage, as shown below.

@Ravlen started a discussion:

@Ravlen started a discussion:

For example, if you start rolling out new code, and:

@Ravlen started a discussion:

- Users do not experience trouble, GitLab can automatically complete the deployment from 0% to 100%.

@Ravlen started a discussion:

- Users experience trouble with the new code, you can stop the timed incremental rollout by canceling the pipeline

@Ravlen started a discussion:

  and [rolling](environments.md#rolling-back-changes) back to the last stable version.

@Ravlen started a discussion:

- Run manual pipelines (using the [Web UI](#manually-executing-pipelines) or pipelines API).

@Ravlen started a discussion:

- Retry/cancel existing jobs (using the Web UI or pipelines API).

@Ravlen started a discussion:

run on protected branches, preventing untrusted users from getting unintended access to

Edited Mar 15, 2019 by Evan Read