Merge branch 'selhorn-pipeline-status' into 'master'

Reordered docs to match UI

See merge request gitlab-org/gitlab!65485

doc/ci/pipelines/settings.md

@@ -6,72 +6,91 @@ disqus_identifier: 'https://docs.gitlab.com/ee/user/project/pipelines/settings.h
 type: reference, howto
 ---
 
-# Pipeline settings **(FREE)**
+# Customize pipeline configuration **(FREE)**
 
-To reach the pipelines settings navigate to your project's
-**Settings > CI/CD**.
-
-The following settings can be configured per project.
+You can customize how pipelines run for your project.
 
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-For an overview, watch the video [GitLab CI Pipeline, Artifacts, and Environments](https://www.youtube.com/watch?v=PCKDICEe10s).
+For an overview of pipelines, watch the video [GitLab CI Pipeline, Artifacts, and Environments](https://www.youtube.com/watch?v=PCKDICEe10s).
 Watch also [GitLab CI pipeline tutorial for beginners](https://www.youtube.com/watch?v=Jav4vbUrqII).
 
-You can use the pipeline status to determine if a merge request can be merged:
+## Visibility of pipelines
 
-- [Merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md).
-- [Only allow merge requests to be merged if the pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds).
+Pipeline visibility is determined by:
 
-## Git strategy
+- Your current [user access level](../../user/permissions.md).
+- The **Public pipelines** project setting under your project's **Settings > CI/CD > General pipelines**.
 
-With Git strategy, you can choose the default way your repository is fetched
-from GitLab in a job.
+NOTE:
+If the project visibility is set to **Private**, the [**Public pipelines** setting has no effect](../enable_or_disable_ci.md#per-project-user-setting).
 
-There are two options. Using:
+This also determines the visibility of these related features:
 
-- `git clone`, which is slower because it clones the repository from scratch
-  for every job, ensuring that the local working copy is always pristine.
-- `git fetch`, which is default in GitLab and faster as it re-uses the local working copy (falling
-  back to clone if it doesn't exist).
-  This is recommended, especially for [large repositories](../large_repositories/index.md#git-strategy).
+- Job output logs
+- Job artifacts
+- The [pipeline security dashboard](../../user/application_security/security_dashboard/index.md#pipeline-security) **(ULTIMATE)**
 
-The configured Git strategy can be overridden by the [`GIT_STRATEGY` variable](../runners/configure_runners.md#git-strategy)
-in `.gitlab-ci.yml`.
+Job logs and artifacts are [not visible for guest users and non-project members](https://gitlab.com/gitlab-org/gitlab/-/issues/25649).
 
-## Git shallow clone
+If **Public pipelines** is enabled (default):
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/28919) in GitLab 12.0.
+- For **public** projects, anyone can view the pipelines and related features.
+- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines
+  and related features.
+- For **private** projects, any project member (Guest or higher) can view the pipelines
+  and related features.
 
-It is possible to limit the number of changes that GitLab CI/CD fetches when cloning
-a repository. Setting a limit to `git depth` can speed up Pipelines execution.
+If **Public pipelines** is disabled:
 
-In GitLab 12.0 and later, newly created projects automatically have a default
-`git depth` value of `50`. The maximum allowed value is `1000`.
+- For **public** projects, anyone can view the pipelines, but only members
+  (Reporter or higher) can access the related features.
+- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines.
+  However, only members (reporter or higher) can access the job related features.
+- For **private** projects, only project members (reporter or higher)
+  can view the pipelines or access the related features.
 
-To disable shallow clone and make GitLab CI/CD fetch all branches and tags each time,
-keep the value empty or set to `0`.
+## Auto-cancel redundant pipelines
 
-This value can also be [overridden by `GIT_DEPTH`](../large_repositories/index.md#shallow-cloning) variable in `.gitlab-ci.yml` file.
+You can set pending or running pipelines to cancel automatically when a new pipeline runs on the same branch. You can enable this in the project settings:
 
-## Timeout
+1. Go to **Settings > CI/CD**.
+1. Expand **General Pipelines**.
+1. Check the **Auto-cancel redundant pipelines** checkbox.
+1. Click **Save changes**.
 
-Timeout defines the maximum amount of time in minutes that a job is able run.
-This is configurable under your project's **Settings > CI/CD > General pipelines settings**.
-The default value is 60 minutes. Decrease the time limit if you want to impose
-a hard limit on your jobs' running time or increase it otherwise. In any case,
-if the job surpasses the threshold, it is marked as failed.
+Use the [`interruptible`](../yaml/index.md#interruptible) keyword to indicate if a
+running job can be cancelled before it completes.
 
-### Timeout overriding for runners
+## Skip outdated deployment jobs
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17221) in GitLab 10.7.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25276) in GitLab 12.9.
 
-Project defined timeout (either specific timeout set by user or the default
-60 minutes timeout) may be [overridden for runners](../runners/configure_runners.md#set-maximum-job-timeout-for-a-runner).
+Your project may have multiple concurrent deployment jobs that are
+scheduled to run in the same time frame.
 
-## Maximum artifacts size **(FREE SELF)**
+This can lead to a situation where an older deployment job runs after a
+newer one, which may not be what you want.
 
-For information about setting a maximum artifact size for a project, see
-[Maximum artifacts size](../../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size).
+To avoid this scenario:
+
+1. Go to **Settings > CI/CD**.
+1. Expand **General pipelines**.
+1. Check the **Skip outdated deployment jobs** checkbox.
+1. Click **Save changes**.
+
+When enabled, any older deployments job are skipped when a new deployment starts.
+
+For more information, see [Deployment safety](../environments/deployment_safety.md).
+
+## Retry outdated jobs
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211339) in GitLab 13.6.
+
+A deployment job can fail because a newer one has run. If you retry the failed deployment job, the
+environment could be overwritten with older source code. If you click **Retry**, a modal warns you
+about this and asks for confirmation.
+
+For more information, see [Deployment safety](../environments/deployment_safety.md).
 
 ## Custom CI/CD configuration file
 
@@ -115,6 +134,52 @@ configuration file. For example:
 Other users and projects can access the configuration file without being
 able to edit it.
 
+## Git strategy
+
+With Git strategy, you can choose the default way your repository is fetched
+from GitLab in a job.
+
+There are two options. Using:
+
+- `git clone`, which is slower because it clones the repository from scratch
+  for every job, ensuring that the local working copy is always pristine.
+- `git fetch`, which is default in GitLab and faster as it re-uses the local working copy (falling
+  back to clone if it doesn't exist).
+  This is recommended, especially for [large repositories](../large_repositories/index.md#git-strategy).
+
+The configured Git strategy can be overridden by the [`GIT_STRATEGY` variable](../runners/configure_runners.md#git-strategy)
+in `.gitlab-ci.yml`.
+
+## Git shallow clone
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/28919) in GitLab 12.0.
+
+It is possible to limit the number of changes that GitLab CI/CD fetches when cloning
+a repository. Setting a limit to `git depth` can speed up Pipelines execution.
+
+In GitLab 12.0 and later, newly created projects automatically have a default
+`git depth` value of `50`. The maximum allowed value is `1000`.
+
+To disable shallow clone and make GitLab CI/CD fetch all branches and tags each time,
+keep the value empty or set to `0`.
+
+This value can also be [overridden by `GIT_DEPTH`](../large_repositories/index.md#shallow-cloning) variable in `.gitlab-ci.yml` file.
+
+## Timeout
+
+Timeout defines the maximum amount of time in minutes that a job is able run.
+This is configurable under your project's **Settings > CI/CD > General pipelines settings**.
+The default value is 60 minutes. Decrease the time limit if you want to impose
+a hard limit on your jobs' running time or increase it otherwise. In any case,
+if the job surpasses the threshold, it is marked as failed.
+
+### Timeout overriding for runners
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17221) in GitLab 10.7.
+
+Project defined timeout (either specific timeout set by user or the default
+60 minutes timeout) may be [overridden for runners](../runners/configure_runners.md#set-maximum-job-timeout-for-a-runner).
+
 ## Test coverage parsing
 
 If you use test coverage in your code, GitLab can capture its output in the
@@ -184,84 +249,6 @@ For example:
 lein cloverage | perl -pe 's/\e\[?.*?[\@-~]//g'
 ```
 
-## Visibility of pipelines
-
-Pipeline visibility is determined by:
-
-- Your current [user access level](../../user/permissions.md).
-- The **Public pipelines** project setting under your project's **Settings > CI/CD > General pipelines**.
-
-NOTE:
-If the project visibility is set to **Private**, the [**Public pipelines** setting has no effect](../enable_or_disable_ci.md#per-project-user-setting).
-
-This also determines the visibility of these related features:
-
-- Job output logs
-- Job artifacts
-- The [pipeline security dashboard](../../user/application_security/security_dashboard/index.md#pipeline-security) **(ULTIMATE)**
-
-Job logs and artifacts are [not visible for guest users and non-project members](https://gitlab.com/gitlab-org/gitlab/-/issues/25649).
-
-If **Public pipelines** is enabled (default):
-
-- For **public** projects, anyone can view the pipelines and related features.
-- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines
-  and related features.
-- For **private** projects, any project member (guest or higher) can view the pipelines
-  and related features.
-
-If **Public pipelines** is disabled:
-
-- For **public** projects, anyone can view the pipelines, but only members
-  (reporter or higher) can access the related features.
-- For **internal** projects, any logged in user except [external users](../../user/permissions.md#external-users) can view the pipelines.
-  However, only members (reporter or higher) can access the job related features.
-- For **private** projects, only project members (reporter or higher)
-  can view the pipelines or access the related features.
-
-## Auto-cancel redundant pipelines
-
-You can set pending or running pipelines to cancel automatically when a new pipeline runs on the same branch. You can enable this in the project settings:
-
-1. Go to **Settings > CI/CD**.
-1. Expand **General Pipelines**.
-1. Check the **Auto-cancel redundant pipelines** checkbox.
-1. Click **Save changes**.
-
-Use the [`interruptible`](../yaml/index.md#interruptible) keyword to indicate if a
-running job can be cancelled before it completes.
-
-## Skip outdated deployment jobs
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25276) in GitLab 12.9.
-
-Your project may have multiple concurrent deployment jobs that are
-scheduled to run in the same time frame.
-
-This can lead to a situation where an older deployment job runs after a
-newer one, which may not be what you want.
-
-To avoid this scenario:
-
-1. Go to **Settings > CI/CD**.
-1. Expand **General pipelines**.
-1. Check the **Skip outdated deployment jobs** checkbox.
-1. Click **Save changes**.
-
-When enabled, any older deployments job are skipped when a new deployment starts.
-
-For more information, see [Deployment safety](../environments/deployment_safety.md).
-
-## Retry outdated jobs
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211339) in GitLab 13.6.
-
-A deployment job can fail because a newer one has run. If you retry the failed deployment job, the
-environment could be overwritten with older source code. If you click **Retry**, a modal warns you
-about this and asks for confirmation.
-
-For more information, see [Deployment safety](../environments/deployment_safety.md).
-
 ## Pipeline Badges
 
 In the pipelines settings page you can find pipeline status and test coverage
@@ -353,6 +340,10 @@ https://gitlab.com/gitlab-org/gitlab/badges/main/coverage.svg?job=karma&key_text
 
 ![Badge with custom text and width](https://gitlab.com/gitlab-org/gitlab/badges/main/coverage.svg?job=karma&key_text=Frontend+Coverage&key_width=130)
 
+## Related topics
+
+- [Maximum artifacts size](../../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size).
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues