Add latest changes from gitlab-org/gitlab@master

9 files changed, 52 insertions, 12 deletions

diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index 1138ead46da..c583c4035ae 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -1091,6 +1091,9 @@ To enable the read-only mode:
 
 1. Next, trigger one of the garbage collect commands:
 
+   WARNING:
+   You must use `/opt/gitlab/embedded/bin/registry` to recycle unused tags. If you use `gitlab-ctl registry-garbage-collect`, you **will bring the container registry down**.
+
    ```shell
    # Recycling unused tags
    sudo /opt/gitlab/embedded/bin/registry garbage-collect /var/opt/gitlab/registry/config.yml
diff --git a/doc/development/database/database_dictionary.md b/doc/development/database/database_dictionary.md
index afbd9a5aba8..d74d7e77edb 100644
--- a/doc/development/database/database_dictionary.md
+++ b/doc/development/database/database_dictionary.md
@@ -38,6 +38,7 @@ milestone: '13.0'
 | `description`              | String        | no       | Text description of the information stored in the table or view, and its purpose. |
 | `introduced_by_url`        | URL           | no       | URL to the merge request or commit which introduced this table or view.           |
 | `milestone`                | String        | no       | The milestone that introduced this table or view.                                 |
+| `gitlab_schema`            | String        | yes      | GitLab schema name.                                                               |
 
 ## Adding tables
 
diff --git a/doc/development/database/query_performance.md b/doc/development/database/query_performance.md
index 61fd80338fe..73a6a40f801 100644
--- a/doc/development/database/query_performance.md
+++ b/doc/development/database/query_performance.md
@@ -15,13 +15,14 @@ When you are optimizing your SQL queries, there are two dimensions to pay attent
 
 ## Timing guidelines for queries
 
-| Query Type | Maximum Query Time | Notes |
-|----|----|---|
-| General queries | `100ms` | This is not a hard limit, but if a query is getting above it, it is important to spend time understanding why it can or cannot be optimized. |
-| Queries in a migration | `100ms` | This is different than the total [migration time](../migration_style_guide.md#how-long-a-migration-should-take). |
-| Concurrent operations in a migration | `5min` | Concurrent operations do not block the database, but they block the GitLab update. This includes operations such as `add_concurrent_index` and `add_concurrent_foreign_key`. |
-| Background migrations | `1s` |  |
-| Service Ping | `1s` | See the [Service Ping docs](../service_ping/implement.md) for more details. |
+| Query Type                                | Maximum Query Time | Notes                                                                                                                                                                                                                                                                                                                      |
+|-------------------------------------------|--------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| General queries                           | `100ms`            | This is not a hard limit, but if a query is getting above it, it is important to spend time understanding why it can or cannot be optimized.                                                                                                                                                                               |
+| Queries in a migration                    | `100ms`            | This is different than the total [migration time](../migration_style_guide.md#how-long-a-migration-should-take).                                                                                                                                                                                                           |
+| Concurrent operations in a migration      | `5min`             | Concurrent operations do not block the database, but they block the GitLab update. This includes operations such as `add_concurrent_index` and `add_concurrent_foreign_key`.                                                                                                                                               |
+| Concurrent operations in a post migration | `20min`            | Concurrent operations do not block the database, but they block the GitLab post update process. This includes operations such as `add_concurrent_index` and `add_concurrent_foreign_key`. If index creation exceeds 20 minutes, consider [async index creation](adding_database_indexes.md#create-indexes-asynchronously). |
+| Background migrations                     | `1s`               |                                                                                                                                                                                                                                                                                                                            |
+| Service Ping                              | `1s`               | See the [Service Ping docs](../service_ping/implement.md) for more details.                                                                                                                                                                                                                                                |
 
 - When analyzing your query's performance, pay attention to if the time you are seeing is on a [cold or warm cache](#cold-and-warm-cache). These guidelines apply for both cache types.
 - When working with batched queries, change the range and batch size to see how it effects the query timing and caching.
diff --git a/doc/development/documentation/topic_types/index.md b/doc/development/documentation/topic_types/index.md
index 9648fc8fe0f..964b41303cb 100644
--- a/doc/development/documentation/topic_types/index.md
+++ b/doc/development/documentation/topic_types/index.md
@@ -6,20 +6,19 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Documentation topic types (CTRT)
 
-At GitLab, we have not traditionally used types for our content. However, we are starting to
-move in this direction, and we now use four primary topic types:
+Each topic on a page should be one of the following topic types:
 
 - [Concept](concept.md)
 - [Task](task.md)
 - [Reference](reference.md)
 - [Troubleshooting](troubleshooting.md)
 
+Even if a page is short, the page usually starts with a concept and then
+includes a task or reference topic.
+
 The tech writing team sometimes uses the acronym `CTRT` to refer to our topic types.
 The acronym refers to the first letter of each topic type.
 
-In general, each page in the GitLab documentation contains multiple topics.
-Each topic on a page should be recognizable as a specific topic type.
-
 In addition to the four primary topic types, we also have a page type for
 [Tutorials](tutorial.md) and [Get started](#get-started).
 
diff --git a/doc/development/pipelines/index.md b/doc/development/pipelines/index.md
index 78d07bb804f..05e9332b40f 100644
--- a/doc/development/pipelines/index.md
+++ b/doc/development/pipelines/index.md
@@ -148,6 +148,34 @@ merge request. This prevents `rspec fail-fast` duration from exceeding the avera
 
 This number can be overridden by setting a CI/CD variable named `RSPEC_FAIL_FAST_TEST_FILE_COUNT_THRESHOLD`.
 
+## Re-run previously failed tests in merge request pipelines
+
+In order to reduce the feedback time after resolving failed tests for a merge request, the `rspec rspec-pg12-rerun-previous-failed-tests`
+and `rspec rspec-ee-pg12-rerun-previous-failed-tests` jobs run the failed tests from the previous MR pipeline.
+
+This was introduced on August 25th 2021, with <https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69053>.
+
+### How it works?
+
+1. The `detect-previous-failed-tests` job (`prepare` stage) detects the test files associated with failed RSpec
+   jobs from the previous MR pipeline.
+1. The `rspec rspec-pg12-rerun-previous-failed-tests` and `rspec rspec-ee-pg12-rerun-previous-failed-tests` jobs
+   will run the test files gathered by the `detect-previous-failed-tests` job.
+
+```mermaid
+graph LR
+    subgraph "prepare stage";
+        A["detect-previous-failed-tests"]
+    end
+
+    subgraph "test stage";
+        B["rspec rspec-pg12-rerun-previous-failed-tests"];
+        C["rspec rspec-ee-pg12-rerun-previous-failed-tests"];
+    end
+
+    A --"artifact: list of test files"--> B & C
+```
+
 ## Faster feedback for merge requests that fix a broken `master`
 
 When you need to [fix a broken `master`](https://about.gitlab.com/handbook/engineering/workflow/#resolution-of-broken-master), you can add the `pipeline:expedite-master-fixing` label to expedite the pipelines that run on the merge request.
diff --git a/doc/user/admin_area/settings/external_authorization.md b/doc/user/admin_area/settings/external_authorization.md
index a34ceac0d95..09ac477b062 100644
--- a/doc/user/admin_area/settings/external_authorization.md
+++ b/doc/user/admin_area/settings/external_authorization.md
@@ -43,6 +43,9 @@ using Omnibus, learn to install a custom CA in the
 Alternatively, learn where to install custom certificates by using
 `openssl version -d`.
 
+When external authorization is enabled, [deploy tokens](../../project/deploy_tokens/index.md)
+ and [deploy keys](../../project/deploy_keys/index.md) can't be used for Git operations.
+
 ## Configuration
 
 The external authorization service can be enabled by an administrator:
diff --git a/doc/user/packages/package_registry/index.md b/doc/user/packages/package_registry/index.md
index 5e7f3e6ae79..75e23fe371a 100644
--- a/doc/user/packages/package_registry/index.md
+++ b/doc/user/packages/package_registry/index.md
@@ -62,6 +62,7 @@ For most package types, the following credential types are valid:
 
 NOTE:
 If you have not activated the "Packages" feature for your project at **Settings > General > Project features**, you will receive a 403 Forbidden response.
+Accessing package registry via deploy token is not available when external authorization is enabled.
 
 ## Use GitLab CI/CD to build packages
 
diff --git a/doc/user/project/deploy_keys/index.md b/doc/user/project/deploy_keys/index.md
index 58f7d3198b2..56bb899c233 100644
--- a/doc/user/project/deploy_keys/index.md
+++ b/doc/user/project/deploy_keys/index.md
@@ -18,6 +18,8 @@ Depending on your needs, you might want to use a [deploy token](../deploy_tokens
 | Validity         | Valid as long as it's registered and enabled. | Can be given an expiration date. |
 | Registry access  | Cannot access a package registry. | Can read from and write to a package registry. |
 
+Deploy keys can't be used for Git operations if [external authorization](../../admin_area/settings/external_authorization.md) is enabled.
+
 ## Scope
 
 A deploy key has a defined scope when it is created:
diff --git a/doc/user/project/deploy_tokens/index.md b/doc/user/project/deploy_tokens/index.md
index cfe7a956bc3..5f279ddda5b 100644
--- a/doc/user/project/deploy_tokens/index.md
+++ b/doc/user/project/deploy_tokens/index.md
@@ -41,6 +41,8 @@ You can create deploy tokens at either the project or group level:
 By default, a deploy token does not expire. You can optionally set an expiry date when you create
 it. Expiry occurs at midnight UTC on that date.
 
+Deploy tokens can't be used for Git operations and Package Registry operations if [external authorization](../../admin_area/settings/external_authorization.md) is enabled.
+
 ## Scope
 
 A deploy token's scope determines the actions it can perform.