Add latest changes from gitlab-org/gitlab@master

11 files changed, 251 insertions, 183 deletions

diff --git a/doc/administration/geo/disaster_recovery/index.md b/doc/administration/geo/disaster_recovery/index.md
index fbecd2571ca..d1ea2978202 100644
--- a/doc/administration/geo/disaster_recovery/index.md
+++ b/doc/administration/geo/disaster_recovery/index.md
@@ -446,6 +446,134 @@ Now we need to make each **secondary** node listen to changes on the new **prima
 to [initiate the replication process](../setup/database.md#step-3-initiate-the-replication-process) again but this time
 for another **primary** node. All the old replication settings will be overwritten.
 
+## Promoting a secondary Geo cluster in GitLab Cloud Native Helm Charts
+
+When updating a Cloud Native Geo deployment, the process for updating any node that is external to the secondary Kubernetes cluster does not differ from the non Cloud Native approach. As such, you can always defer to [Promoting a secondary Geo node in single-secondary configurations](#promoting-a-secondary-geo-node-in-single-secondary-configurations) for more information.
+
+The following sections assume you are using the `gitlab` namespace. If you used a different namespace when setting up your cluster, you should also replace `--namespace gitlab` with your namespace.
+
+WARNING:
+In GitLab 13.2 and 13.3, promoting a secondary site to a primary while the
+secondary is paused fails. Do not pause replication before promoting a
+secondary. If the site is paused, be sure to resume before promoting. This
+issue has been fixed in GitLab 13.4 and later.
+
+### Step 1. Permanently disable the **primary** cluster
+
+WARNING:
+If the **primary** site goes offline, there may be data saved on the **primary** site
+that has not been replicated to the **secondary** site. This data should be treated
+as lost if you proceed.
+
+If an outage on the **primary** site happens, you should do everything possible to
+avoid a split-brain situation where writes can occur in two different GitLab
+instances, complicating recovery efforts. So to prepare for the failover, you
+must disable the **primary** site:
+
+- If you have access to the **primary** Kubernetes cluster, connect to it and disable the GitLab webservice and Sidekiq pods:
+
+  ```shell
+  kubectl --namespace gitlab scale deploy gitlab-geo-webservice-default --replicas=0
+  kubectl --namespace gitlab scale deploy gitlab-geo-sidekiq-all-in-1-v1 --replicas=0
+  ```
+
+- If you do not have access to the **primary** Kubernetes cluster, take the cluster offline and
+  prevent it from coming back online by any means at your disposal.
+  Since there are many ways you may prefer to accomplish this, we will avoid a
+  single recommendation. You may need to:
+
+  - Reconfigure the load balancers.
+  - Change DNS records (for example, point the primary DNS record to the
+    **secondary** site to stop usage of the **primary** site).
+  - Stop the virtual servers.
+  - Block traffic through a firewall.
+  - Revoke object storage permissions from the **primary** site.
+  - Physically disconnect a machine.
+
+### Step 2. Promote all **secondary** nodes external to the cluster
+
+WARNING:
+If the secondary site [has been paused](../../geo/index.md#pausing-and-resuming-replication), this performs
+a point-in-time recovery to the last known state.
+Data that was created on the primary while the secondary was paused will be lost.
+
+1. SSH in to the database node in the **secondary** and trigger PostgreSQL to
+   promote to read-write:
+
+   ```shell
+   sudo gitlab-ctl promote-db
+   ```
+
+   In GitLab 12.8 and earlier, see [Message: `sudo: gitlab-pg-ctl: command not found`](../replication/troubleshooting.md#message-sudo-gitlab-pg-ctl-command-not-found).
+
+1. Edit `/etc/gitlab/gitlab.rb` on the database node in the **secondary** site to
+   reflect its new status as **primary** by removing any lines that enabled the
+   `geo_secondary_role`:
+
+   NOTE:
+   Depending on your architecture these steps will need to be run on any GitLab node that is external to the **secondary** Kubernetes cluster.
+
+   ```ruby
+   ## In pre-11.5 documentation, the role was enabled as follows. Remove this line.
+   geo_secondary_role['enable'] = true
+
+   ## In 11.5+ documentation, the role was enabled as follows. Remove this line.
+   roles ['geo_secondary_role']
+   ```
+
+   After making these changes, [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) on the database node.
+
+### Step 3. Promote the **secondary** cluster
+
+1. Find the task runner pod:
+
+   ```shell
+   kubectl --namespace gitlab get pods -lapp=task-runner
+   ```
+
+1. Promote the secondary:
+
+   ```shell
+   kubectl --namespace gitlab exec -ti gitlab-geo-task-runner-XXX -- gitlab-rake geo:set_secondary_as_primary
+   ```
+
+1. Update the existing cluster configuration.
+
+   You can retrieve the existing config with Helm:
+
+   ```shell
+   helm --namespace gitlab get values gitlab-geo > gitlab.yaml
+   ```
+
+   The existing config will contain a section for Geo that should resemble:
+
+   ```yaml
+   geo:
+      enabled: true
+      role: secondary
+      nodeName: secondary.example.com
+      psql:
+         host: geo-2.db.example.com
+         port: 5431
+         password:
+            secret: geo
+            key: geo-postgresql-password
+   ```
+
+   To promote the **secondary** cluster to a **primary** cluster, update `role: secondary` to `role: primary`.
+
+   You can remove the entire `psql` section if the cluster will remain as a primary site, this refers to the tracking database and will be ignored whilst the cluster is acting as a primary site.
+
+   Update the cluster with the new config:
+
+   ```shell
+   helm upgrade --install --version <current Chart version> gitlab-geo gitlab/gitlab --namespace gitlab -f gitlab.yaml
+   ```
+
+1. Verify you can connect to the newly promoted primary using the URL used previously for the secondary.
+
+1. Success! The secondary has now been promoted to primary.
+
 ## Troubleshooting
 
 This section was moved to [another location](../replication/troubleshooting.md#fixing-errors-during-a-failover-or-when-promoting-a-secondary-to-a-primary-node).
diff --git a/doc/administration/monitoring/prometheus/gitlab_metrics.md b/doc/administration/monitoring/prometheus/gitlab_metrics.md
index f56349fc9e6..4ba1a85babc 100644
--- a/doc/administration/monitoring/prometheus/gitlab_metrics.md
+++ b/doc/administration/monitoring/prometheus/gitlab_metrics.md
@@ -139,6 +139,18 @@ The following metrics can be controlled by feature flags:
 | `gitlab_method_call_duration_seconds`                          | `prometheus_metrics_method_instrumentation`                        |
 | `gitlab_view_rendering_duration_seconds`                       | `prometheus_metrics_view_instrumentation`                          |
 
+## Praefect metrics
+
+You can [configure Praefect to report metrics](../../gitaly/praefect.md#praefect).
+These are some of the Praefect metrics served from the `/metrics` path on the [configured port](index.md#changing-the-port-and-address-prometheus-listens-on)
+(9652 by default).
+
+| Metric | Type | Since | Description | Labels |
+| :----- | :--- | ----: | :---------- | :----- |
+| `gitaly_praefect_replication_latency_bucket` | Histogram | 12.10 | The amount of time it takes for replication to complete once the replication job starts. |  |
+| `gitaly_praefect_replication_delay_bucket` | Histogram | 12.10 | A measure of how much time passes between when the replication job is created and when it starts. |  |
+| `gitaly_praefect_node_latency_bucket` | Histogram | 12.10 | The latency in Gitaly returning health check information to Praefect. This indicates Praefect connection saturation. |  |
+
 ## Sidekiq metrics
 
 Sidekiq jobs may also gather metrics, and these metrics can be accessed if the
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 9fd509d61a8..8abeacd0d0e 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -7525,6 +7525,15 @@ The kind of an approval rule.
 | `REGULAR` | A `regular` approval rule. |
 | `REPORT_APPROVER` | A `report_approver` approval rule. |
 
+### `AssigneeWildcardId`
+
+Assignee ID wildcard values.
+
+| Value | Description |
+| ----- | ----------- |
+| `ANY` | An assignee is assigned. |
+| `NONE` | No assignee is assigned. |
+
 ### `AvailabilityEnum`
 
 User availability status.
diff --git a/doc/development/documentation/site_architecture/release_process.md b/doc/development/documentation/site_architecture/release_process.md
index 4776a41aadb..9329b93bb26 100644
--- a/doc/development/documentation/site_architecture/release_process.md
+++ b/doc/development/documentation/site_architecture/release_process.md
@@ -1,181 +1,8 @@
 ---
-stage: none
-group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+redirect_to: 'https://about.gitlab.com/handbook/engineering/ux/technical-writing/workflow/#monthly-documentation-releases'
 ---
 
-# Monthly release process
+This file was moved to [another location](https://about.gitlab.com/handbook/engineering/ux/technical-writing/workflow/#monthly-documentation-releases).
 
-When a new GitLab version is released on the 22nd, we release version-specific published
-documentation for the new version.
-
-We complete the process as soon as possible after the GitLab version is announced. The result is:
-
-- The [online published documentation](https://docs.gitlab.com) includes:
-  - The three most recent minor releases of the current major version. For example 13.9, 13.8, and
-    13.7.
-  - The most recent minor releases of the last two major versions. For example 12.10, and 11.11.
-- Documentation updates after the 22nd are for the next release. The versions drop down
-  should have the current milestone with `-pre` appended to it, for example `13.10-pre`.
-
-Each documentation release:
-
-- Has a dedicated branch, named in the format `XX.yy`.
-- Has a Docker image that contains a build of that branch.
-
-For example:
-
-- For [GitLab 13.9](https://docs.gitlab.com/13.9/index.html), the
-  [stable branch](https://gitlab.com/gitlab-org/gitlab-docs/-/tree/13.9) and Docker image:
-  [`registry.gitlab.com/gitlab-org/gitlab-docs:13.9`](https://gitlab.com/gitlab-org/gitlab-docs/container_registry/631635).
-- For [GitLab 13.8](https://docs.gitlab.com/13.8/index.html), the
-  [stable branch](https://gitlab.com/gitlab-org/gitlab-docs/-/tree/13.8) and Docker image:
-  [`registry.gitlab.com/gitlab-org/gitlab-docs:13.8`](https://gitlab.com/gitlab-org/gitlab-docs/container_registry/631635).
-
-## Recommended timeline
-
-To minimize problems during the documentation release process, use the following timeline:
-
-- Any time before the 17th of the month:
-
-  [Add the charts version](#add-chart-version), so that the documentation is built using the
-  [version of the charts project that maps to](https://docs.gitlab.com/charts/installation/version_mappings.html)
-  the GitLab release. This step may have been completed already.
-
-- Between the 17th and the 20th of the month:
-
-  1. [Create a stable branch and Docker image](#create-stable-branch-and-docker-image-for-release) for
-     the new version.
-  1. [Create a release merge request](#create-release-merge-request) for the new version, which
-     updates the version dropdown menu for the current documentation and adds the release to the
-     Docker configuration. For example, the
-     [release merge request for 13.9](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/1555).
-  1. [Update the three online versions](#update-dropdown-for-online-versions), so that they display the new release on their
-     version dropdown menus.
-
-- On the 22nd of the month:
-
-  [Merge the release merge requests and run the necessary Docker image builds](#merge-merge-requests-and-run-docker-image-builds).
-
-## Add chart version
-
-To add a new charts version for the release:
-
-1. Make sure you're in the root path of the `gitlab-docs` repository.
-1. Open `content/_data/chart_versions.yaml` and add the new stable branch version using the
-   [version mapping](https://docs.gitlab.com/charts/installation/version_mappings.html). Only the
-   `major.minor` version is needed.
-1. Create a new merge request and merge it.
-
-NOTE:
-If you have time, add anticipated future mappings to `content/_data/chart_versions.yaml`. This saves
-a step for the next GitLab release.
-
-## Create stable branch and Docker image for release
-
-To create a stable branch and Docker image for the release:
-
-1. Make sure you're in the root path of the `gitlab-docs` repository.
-1. Run the Rake task to create the single version. For example, to create the 13.9 release branch
-   and perform others tasks:
-
-   ```shell
-   ./bin/rake "release:single[13.9]"
-   ```
-
-    A branch for the release is created, a new `Dockerfile.13.9` is created, and `.gitlab-ci.yml`
-    has branches variables updated into a new branch. These files are automatically committed.
-
-1. Push the newly created branch, but **don't create a merge request**. After you push, the
-   `image:docs-single` job creates a new Docker image tagged with the name of the branch you created
-   earlier. You can see the Docker image in the `registry` environment at
-   <https://gitlab.com/gitlab-org/gitlab-docs/-/environments/folders/registry>.
-
-For example, see [the 13.9 release pipeline](https://gitlab.com/gitlab-org/gitlab-docs/-/pipelines/260288747).
-
-Optionally, you can test locally by:
-
-1. Building the image and running it. For example, for GitLab 13.9 documentation:
-
-   ```shell
-   docker build -t docs:13.9 -f Dockerfile.13.9 .
-   docker run -it --rm -p 4000:4000 docs:13.9
-   ```
-
-1. Visiting <http://localhost:4000/13.9/> to see if everything works correctly.
-
-## Create release merge request
-
-NOTE:
-An [epic is open](https://gitlab.com/groups/gitlab-org/-/epics/4361) to automate this step.
-
-To create the release merge request for the release:
-
-1. Make sure you're in the root path of the `gitlab-docs` repository.
-1. Create a branch `release-X-Y`. For example:
-
-   ```shell
-   git checkout master
-   git checkout -b release-13-9
-   ```
-
-1. Edit `content/_data/versions.yaml` and update the lists of versions to reflect the new release:
-
-   - Add the latest version to the `online:` section.
-   - Move the oldest version in `online:` to the `offline:` section. There should now be three
-     versions in `online:`.
-
-1. Update these Dockerfiles:
-
-   - `dockerfiles/Dockerfile.archives`: Add the latest version to the top of the list.
-   - `Dockerfile.master`: Remove the oldest version, and add the newest version to the
-     top of the list.
-
-1. Commit and push to create the merge request. For example:
-
-   ```shell
-   git add content/ Dockerfile.master dockerfiles/Dockerfile.archives
-   git commit -m "Release 13.9"
-   git push origin release-13-9
-   ```
-
-Do not merge the release merge request yet.
-
-## Update dropdown for online versions
-
-To update `content/_data/versions.yaml` for all online versions (stable branches `X.Y` of the
-`gitlab-docs` project). For example:
-
-- The merge request to [update the 13.9 version dropdown menu for the 13.9 release](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/1556).
-- The merge request to [update the 13.8 version dropdown menu for the 13.9 release](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/1557).
-- The merge request to [update the 13.7 version dropdown menu for the 13.9 release](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/1558).
-
-1. Run the Rake task that creates all of the necessary merge requests to update the dropdowns. For
-   example, for the 13.9 release:
-
-   ```shell
-   git checkout release-13-9
-   ./bin/rake release:dropdowns
-   ```
-
-1. [Visit the merge requests page](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests?label_name%5B%5D=release)
-   to check that their pipelines pass.
-
-Do not merge these merge requests yet.
-
-## Merge merge requests and run Docker image builds
-
-The merge requests for the dropdowns should now all be merged into their respective stable branches.
-Each merge triggers a new pipeline for each stable branch. Wait for the stable branch pipelines to
-complete, then:
-
-1. Check the [pipelines page](https://gitlab.com/gitlab-org/gitlab-docs/pipelines)
-   and make sure all stable branches have green pipelines.
-1. After all the pipelines succeed:
-   1. Merge all of the [dropdown merge requests](#update-dropdown-for-online-versions).
-   1. Merge the [release merge request](#create-release-merge-request).
-1. Finally, run the
-   [`Build docker images weekly` pipeline](https://gitlab.com/gitlab-org/gitlab-docs/pipeline_schedules)
-   that builds the `:latest` and `:archives` Docker images.
-
-As the last step in the scheduled pipeline, the documentation site deploys with all new versions.
+<!-- This redirect file can be deleted after <2021-07-12>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index 81014b7624c..35e7824721a 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -23,6 +23,8 @@ when no license is active. So EE features always should be guarded by
 `project.feature_available?` or `group.feature_available?` (or
 `License.feature_available?` if it is a system-wide feature).
 
+Frontend features should be guarded by pushing a flag from the backend by [using `push_licensed_feature`](licensed_feature_availability.md#restricting-frontend-features), and checked using `this.glFeatures.someFeature` in the frontend.
+
 CE specs should remain untouched as much as possible and extra specs
 should be added for EE. Licensed features can be stubbed using the
 spec helper `stub_licensed_features` in `EE::LicenseHelpers`.
diff --git a/doc/development/feature_flags/index.md b/doc/development/feature_flags/index.md
index f6e398f1074..560e4f8cb90 100644
--- a/doc/development/feature_flags/index.md
+++ b/doc/development/feature_flags/index.md
@@ -292,8 +292,7 @@ end
 
 ### Frontend
 
-Use the `push_frontend_feature_flag` method for frontend code, which is
-available to all controllers that inherit from `ApplicationController`. You can use
+Use the `push_frontend_feature_flag` method which is available to all controllers that inherit from `ApplicationController`. You can use
 this method to expose the state of a feature flag, for example:
 
 ```ruby
diff --git a/doc/development/licensed_feature_availability.md b/doc/development/licensed_feature_availability.md
index a9fc0414297..10e6d717a18 100644
--- a/doc/development/licensed_feature_availability.md
+++ b/doc/development/licensed_feature_availability.md
@@ -41,3 +41,16 @@ the instance license.
 ```ruby
 License.feature_available?(:feature_symbol)
 ```
+
+## Restricting frontend features
+
+To restrict frontend features based on the license, use `push_licensed_feature`.
+The frontend can then access this via `this.glFeatures`:
+
+```ruby
+before_action do
+  push_licensed_feature(:feature_symbol)
+  # or by project/namespace
+  push_licensed_feature(:feature_symbol, project)
+end
+```
diff --git a/doc/integration/oauth_provider.md b/doc/integration/oauth_provider.md
index faf6f9e6f48..490397cdf1b 100644
--- a/doc/integration/oauth_provider.md
+++ b/doc/integration/oauth_provider.md
@@ -58,6 +58,8 @@ To add a new application for your user:
 
 ## Group owned applications
 
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/16227) in GitLab 13.11.
+
 To add a new application for a group:
 
 1. Navigate to the desired group.
diff --git a/doc/user/admin_area/geo_nodes.md b/doc/user/admin_area/geo_nodes.md
index f41170da975..e5132ef4e96 100644
--- a/doc/user/admin_area/geo_nodes.md
+++ b/doc/user/admin_area/geo_nodes.md
@@ -70,6 +70,12 @@ breaking communication between **primary** and **secondary** nodes when using
 HTTPS, customize your Internal URL to point to a load balancer with TLS
 terminated at the load balancer.
 
+WARNING:
+Starting with GitLab 13.3 and [until 13.11](https://gitlab.com/gitlab-org/gitlab/-/issues/325522),
+using an internal URL that is not accessible to the users will result in the
+OAuth authorization flow not working properly, as the users will get redirected
+to the internal URL instead of the external one.
+
 ## Multiple secondary nodes behind a load balancer
 
 In GitLab 11.11, **secondary** nodes can use identical external URLs as long as
diff --git a/doc/user/project/description_templates.md b/doc/user/project/description_templates.md
index c45ce7a02d9..3acef242cef 100644
--- a/doc/user/project/description_templates.md
+++ b/doc/user/project/description_templates.md
@@ -51,8 +51,10 @@ directory in your repository. Commit and push to your default branch.
 
 To create a Markdown file:
 
-1. Click the `+` button next to `master` and click **New file**.
-1. Add the name of your issue template to the **File name** text field next to `master`.
+1. In a project, go to **Repository**.
+1. Next to the default branch, select the **{plus}** button.
+1. Select **New file**.
+1. Next to the default branch, in the **File name** field, add the name of your issue template.
    Make sure that your file has the `.md` extension, for
    example `feature_request.md` or `Feature Request.md`.
 1. Commit and push to your default branch.
@@ -61,9 +63,12 @@ If you don't have a `.gitlab/issue_templates` directory in your repository, you
 
 To create the `.gitlab/issue_templates` directory:
 
-1. Click the `+` button next to `master` and select **New directory**.
+1. In a project, go to **Repository**.
+1. Next to the default branch, select the **{plus}** button.
+1. Select **New directory**.
 1. Name this new directory `.gitlab` and commit to your default branch.
-1. Click the `+` button next to `master` again and select **New directory**.
+1. Next to the default branch, select the **{plus}** button.
+1. Select **New directory**.
 1. Name your directory `issue_templates` and commit to your default branch.
 
 To check if this has worked correctly, [create a new issue](issues/managing_issues.md#create-a-new-issue)
diff --git a/doc/user/project/settings/index.md b/doc/user/project/settings/index.md
index 62f61c01e19..bcfd7f5e5d9 100644
--- a/doc/user/project/settings/index.md
+++ b/doc/user/project/settings/index.md
@@ -65,6 +65,71 @@ can now create their own.
 
 New compliance framework labels can be created and updated using GraphQL.
 
+#### Compliance pipeline configuration **(ULTIMATE)**
+
+> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3156) in GitLab 13.9.
+> - [Deployed behind a feature flag](../../feature_flags.md).
+> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/300324) in GitLab 13.11.
+> - Enabled on GitLab.com.
+> - Recommended for production use.
+
+WARNING:
+This feature might not be available to you. Check the **version history** note above for details.
+
+Group owners can use the compliance pipeline configuration to define compliance requirements
+such as scans or tests, and enforce them in individual projects.
+
+The [custom compliance framework](#custom-compliance-frameworks) feature allows group owners to specify the location
+of a compliance pipeline configuration stored and managed in a dedicated project, distinct from a developer's project.
+
+When you set up the compliance pipeline configuration field, use the
+`file@group/project` format. For example, you can configure
+`.compliance-gitlab-ci.yml@compliance-group/compliance-project`.
+This field is inherited by projects where the compliance framework label is applied. The result
+forces the project to run the compliance configurations.
+
+When a project with a custom label executes a pipeline, it begins by evaluating the compliance pipeline configuration.
+The custom pipeline configuration can then execute any included individual project configuration.
+
+The user running the pipeline in the project should at least have Reporter access to the compliance project.
+
+Example `.compliance-gitlab-ci.yml`
+
+```yaml
+stages: # Allows compliance team to control the ordering and interweaving of stages/jobs
+- pre-compliance
+- build
+- test
+- pre-deploy-compliance
+- deploy
+- post-compliance
+
+variables: # can be overriden by a developer's local .gitlab-ci.yml
+  FOO: sast
+
+sast: # none of these attributes can be overriden by a developer's local .gitlab-ci.yml
+  variables:
+    FOO: sast
+  stage: pre-compliance
+  script:
+  - echo "running $FOO"
+
+sanity check:
+  stage: pre-deploy-compliance
+  script:
+  - echo "running $FOO"
+
+
+audit trail:
+  stage: post-compliance
+  script:
+  - echo "running $FOO"
+
+include: # Execute individual project's configuration
+  project: '$CI_PROJECT_PATH'
+  file: '$CI_PROJECT_CONFIG_PATH'
+```
+
 ### Sharing and permissions
 
 For your repository, you can set up features such as public access, repository features,