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
-
@Ravlen started a discussion: 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
orruns 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