Add latest changes from gitlab-org/gitlab@master

6 files changed, 66 insertions, 50 deletions

diff --git a/doc/administration/monitoring/gitlab_instance_administration_project/index.md b/doc/administration/monitoring/gitlab_instance_administration_project/index.md
index 8675521ddb1..1235eb2edec 100644
--- a/doc/administration/monitoring/gitlab_instance_administration_project/index.md
+++ b/doc/administration/monitoring/gitlab_instance_administration_project/index.md
@@ -1,39 +1,5 @@
-# GitLab instance administration project
+---
+redirect_to: '../gitlab_self_monitoring_project/index.md'
+---
 
-NOTE: **Note:**
-This feature is available behind a feature flag called `self_monitoring_project`
-since [12.7](https://gitlab.com/gitlab-org/gitlab/issues/32351). The feature flag
-will be removed once we [add dashboards to display metrics](https://gitlab.com/groups/gitlab-org/-/epics/2367).
-
-GitLab has been adding the ability for administrators to see insights into the health of
-their GitLab instance. In order to surface this experience in a native way, similar to how
-you would interact with an application deployed via GitLab, a base project called
-"GitLab Instance Administration" with
-[internal visibility](../../../public_access/public_access.md#internal-projects) will be
-added under a group called "GitLab Instance Administrators" specifically created for
-visualizing and configuring the monitoring of your GitLab instance.
-
-All administrators at the time of creation of the project and group will be added
-as maintainers of the group and project, and as an admin, you'll be able to add new
-members to the group in order to give them maintainer access to the project.
-
-This project will be used for self-monitoring your GitLab instance.
-
-## Connection to Prometheus
-
-The project will be automatically configured to connect to the
-[internal Prometheus](../prometheus/index.md) instance if the Prometheus
-instance is present (should be the case if GitLab was installed via Omnibus
-and you haven't disabled it).
-
-If that's not the case or if you have an external Prometheus instance or an HA setup,
-you should
-[configure it manually](../../../user/project/integrations/prometheus.md#manual-configuration-of-prometheus).
-
-## Taking action on Prometheus alerts **(ULTIMATE)**
-
-You can [add a webhook](../../../user/project/integrations/prometheus.md#external-prometheus-instances)
-to the Prometheus config in order for GitLab to receive notifications of any alerts.
-
-Once the webhook is setup, you can
-[take action on incoming alerts](../../../user/project/integrations/prometheus.md#taking-action-on-incidents-ultimate).
+This document was moved to [another location](../gitlab_self_monitoring_project/index.md).
diff --git a/doc/administration/monitoring/gitlab_self_monitoring_project/index.md b/doc/administration/monitoring/gitlab_self_monitoring_project/index.md
new file mode 100644
index 00000000000..82944d10d52
--- /dev/null
+++ b/doc/administration/monitoring/gitlab_self_monitoring_project/index.md
@@ -0,0 +1,39 @@
+# GitLab self monitoring project
+
+NOTE: **Note:**
+This feature is available behind a feature flag called `self_monitoring_project`
+since [12.7](https://gitlab.com/gitlab-org/gitlab/issues/32351). The feature flag
+will be removed once we [add dashboards to display metrics](https://gitlab.com/groups/gitlab-org/-/epics/2367).
+
+GitLab has been adding the ability for administrators to see insights into the health of
+their GitLab instance. In order to surface this experience in a native way, similar to how
+you would interact with an application deployed via GitLab, a base project called
+"GitLab self monitoring" with
+[internal visibility](../../../public_access/public_access.md#internal-projects) will be
+added under a group called "GitLab Instance Administrators" specifically created for
+visualizing and configuring the monitoring of your GitLab instance.
+
+All administrators at the time of creation of the project and group will be added
+as maintainers of the group and project, and as an admin, you'll be able to add new
+members to the group in order to give them maintainer access to the project.
+
+This project will be used for self-monitoring your GitLab instance.
+
+## Connection to Prometheus
+
+The project will be automatically configured to connect to the
+[internal Prometheus](../prometheus/index.md) instance if the Prometheus
+instance is present (should be the case if GitLab was installed via Omnibus
+and you haven't disabled it).
+
+If that's not the case or if you have an external Prometheus instance or an HA setup,
+you should
+[configure it manually](../../../user/project/integrations/prometheus.md#manual-configuration-of-prometheus).
+
+## Taking action on Prometheus alerts **(ULTIMATE)**
+
+You can [add a webhook](../../../user/project/integrations/prometheus.md#external-prometheus-instances)
+to the Prometheus config in order for GitLab to receive notifications of any alerts.
+
+Once the webhook is setup, you can
+[take action on incoming alerts](../../../user/project/integrations/prometheus.md#taking-action-on-incidents-ultimate).
diff --git a/doc/administration/monitoring/index.md b/doc/administration/monitoring/index.md
index 80e727f6a5c..1d7c52a198f 100644
--- a/doc/administration/monitoring/index.md
+++ b/doc/administration/monitoring/index.md
@@ -2,7 +2,7 @@
 
 Explore our features to monitor your GitLab instance:
 
-- [GitLab self-monitoring](gitlab_instance_administration_project/index.md): The
+- [GitLab self-monitoring](gitlab_self_monitoring_project/index.md): The
   GitLab instance administration project helps to monitor the GitLab instance and
   take action on alerts.
 - [Performance monitoring](performance/index.md): GitLab Performance Monitoring makes it possible to measure a wide variety of statistics of your instance.
diff --git a/doc/administration/monitoring/prometheus/gitlab_metrics.md b/doc/administration/monitoring/prometheus/gitlab_metrics.md
index f3da5a6dd2f..e06a87b93f2 100644
--- a/doc/administration/monitoring/prometheus/gitlab_metrics.md
+++ b/doc/administration/monitoring/prometheus/gitlab_metrics.md
@@ -32,6 +32,7 @@ The following metrics are available:
 | `gitlab_cache_operations_total`                                | Counter   |                   12.2 | Cache operations by controller/action                                                               | controller, action, operation                       |
 | `gitlab_database_transaction_seconds`                          | Histogram |                   12.1 | Time spent in database transactions, in seconds                                                     |                                                     |
 | `gitlab_method_call_duration_seconds`                          | Histogram |                   10.2 | Method calls real duration                                                                          | controller, action, module, method                  |
+| `gitlab_page_out_of_bounds`                                    | Counter   |                   12.8 | Counter for the PageLimiter pagination limit being hit                                              | controller, action, bot                             |
 | `gitlab_rails_queue_duration_seconds`                          | Histogram |                    9.4 | Measures latency between GitLab Workhorse forwarding a request to Rails                             |                                                     |
 | `gitlab_sql_duration_seconds`                                  | Histogram |                   10.2 | SQL execution time, excluding SCHEMA operations and BEGIN / COMMIT                                  |                                                     |
 | `gitlab_transaction_allocated_memory_bytes`                    | Histogram |                   10.2 | Allocated memory for all transactions (gitlab_transaction_* metrics)                                |                                                     |
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 52b63de9e70..1664815bc7b 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -2681,6 +2681,27 @@ trigger_job:
     strategy: depend
 ```
 
+#### Linking pipelines with `trigger:strategy`
+
+By default, the `trigger` job completes with the `success` status
+as soon as the downstream pipeline is created.
+
+To force the `trigger` job to wait for the downstream (multi-project or child) pipeline to complete, use
+`strategy: depend`. This will make the trigger job wait with a "running" status until the triggered
+pipeline completes. At that point, the `trigger` job will complete and display the same status as
+the downstream job.
+
+```yaml
+trigger_job:
+  trigger:
+    include: path/to/child-pipeline.yml
+    strategy: depend
+```
+
+This can help keep your pipeline execution linear. In the example above, jobs from
+subsequent stages will wait for the triggered pipeline to successfully complete before
+starting, at the cost of reduced parallelization.
+
 ### `interruptible`
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/23464) in GitLab 12.3.
diff --git a/doc/development/rake_tasks.md b/doc/development/rake_tasks.md
index d9b2ace1b5b..ff978ee2899 100644
--- a/doc/development/rake_tasks.md
+++ b/doc/development/rake_tasks.md
@@ -54,17 +54,6 @@ By default, this seeds an average of 10 issues per week for the last 52 weeks
 per project. All issues will also be randomly labeled with team, type, severity,
 and priority.
 
-#### Seeding groups with sub-groups
-
-You can seed groups with sub-groups that contain milestones/projects/issues
-with the `gitlab:seed:group_seed` task:
-
-```shell
-bin/rake "gitlab:seed:group_seed[subgroup_depth, username]"
-```
-
-Group are additionally seeded with epics if GitLab instance has epics feature available.
-
 ### Automation
 
 If you're very sure that you want to **wipe the current database** and refill