Add latest changes from gitlab-org/gitlab@master

6 files changed, 69 insertions, 33 deletions

diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md
index 5037e5034c8..50db86a8e2c 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -142,11 +142,6 @@ the Gitaly server. The easiest way to accomplish this is to copy `/etc/gitlab/gi
 from an existing GitLab server to the Gitaly server. Without this shared secret,
 Git operations in GitLab will result in an API error.
 
-NOTE: **Note:**
-In most or all cases, the storage paths below end in `/repositories` which is
-not the case with `path` in `git_data_dirs` of Omnibus GitLab installations.
-Check the directory layout on your Gitaly server to be sure.
-
 **For Omnibus GitLab**
 
 1. Edit `/etc/gitlab/gitlab.rb`:
@@ -193,24 +188,26 @@ Check the directory layout on your Gitaly server to be sure.
    On `gitaly1.internal`:
 
    ```
-   gitaly['storage'] = [
-     { 'name' => 'default' },
-     { 'name' => 'storage1' },
-   ]
+   git_data_dirs({
+     'default' => {
+       'path' => '/var/opt/gitlab/git-data'
+     },
+     'storage1' => {
+       'path' => '/mnt/gitlab/git-data'
+     },
+   })
    ```
 
    On `gitaly2.internal`:
 
    ```
-   gitaly['storage'] = [
-     { 'name' => 'storage2' },
-   ]
+   git_data_dirs({
+     'storage2' => {
+       'path' => '/srv/gitlab/git-data'
+     },
+   })
    ```
 
-   NOTE: **Note:**
-   In some cases, you'll have to set `path` for `gitaly['storage']` in the
-   format `'path' => '/mnt/gitlab/<storage name>/repositories'`.
-
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 
 **For installations from source**
@@ -236,9 +233,11 @@ Check the directory layout on your Gitaly server to be sure.
    ```toml
    [[storage]]
    name = 'default'
+   path = '/var/opt/gitlab/git-data/repositories'
 
    [[storage]]
    name = 'storage1'
+   path = '/mnt/gitlab/git-data/repositories'
    ```
 
    On `gitaly2.internal`:
@@ -246,12 +245,9 @@ Check the directory layout on your Gitaly server to be sure.
    ```toml
    [[storage]]
    name = 'storage2'
+   path = '/srv/gitlab/git-data/repositories'
    ```
 
-   NOTE: **Note:**
-   In some cases, you'll have to set `path` for each `[[storage]]` in the
-   format `path = '/mnt/gitlab/<storage name>/repositories'`.
-
 1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
 
 ### 4. Converting clients to use the Gitaly server
diff --git a/doc/administration/high_availability/consul.md b/doc/administration/high_availability/consul.md
index b01419200cc..392b9b76c31 100644
--- a/doc/administration/high_availability/consul.md
+++ b/doc/administration/high_availability/consul.md
@@ -102,6 +102,23 @@ To be safe, we recommend you only restart one server agent at a time to ensure t
 
 For larger clusters, it is possible to restart multiple agents at a time. See the [Consul consensus document](https://www.consul.io/docs/internals/consensus.html#deployment-table) for how many failures it can tolerate. This will be the number of simulateneous restarts it can sustain.
 
+## Upgrades for bundled Consul
+
+Nodes running GitLab-bundled Consul should be:
+
+- Members of a healthy cluster prior to upgrading the GitLab Omnibus package.
+- Upgraded one node at a time.
+
+NOTE: **NOTE:**
+Running `curl http://127.0.0.1:8500/v1/health/state/critical` from any Consul node will identify existing health issues in the cluster. The command will return an empty array if the cluster is healthy.
+
+Consul clusters communicate using the raft protocol. If the current leader goes offline, there needs to be a leader election. A leader node must exist to facilitate synchronization across the cluster. If too many nodes go offline at the same time, the cluster will lose quorum and not elect a leader due to [broken consensus](https://www.consul.io/docs/internals/consensus.html).
+
+Consult the [troubleshooting section](#troubleshooting) if the cluster is not able to recover after the upgrade. The [outage recovery](#outage-recovery) may be of particular interest.
+
+NOTE: **NOTE:**
+GitLab only uses Consul to store transient data that is easily regenerated. If the bundled Consul was not used by any process other than GitLab itself, then [rebuilding the cluster from scratch](#recreate-from-scratch) is fine.
+
 ## Troubleshooting
 
 ### Consul server agents unable to communicate
diff --git a/doc/development/chatops_on_gitlabcom.md b/doc/development/chatops_on_gitlabcom.md
index 8a313a120f1..456dd1d4b4b 100644
--- a/doc/development/chatops_on_gitlabcom.md
+++ b/doc/development/chatops_on_gitlabcom.md
@@ -14,7 +14,7 @@ tasks such as:
 To request access to Chatops on GitLab.com:
 
 1. Log into <https://ops.gitlab.net/users/sign_in> **using the same username** as for GitLab.com (you may have to rename it).
-1. Ask [an owner/maintainer in the `chatops` project](https://gitlab.com/gitlab-com/chatops/-/project_members?search=&sort=access_level_desc) to add you by running `/chatops run member add <username> gitlab-com/chatops --ops`.
+1. Ask [a project member in the `chatops` project](https://ops.gitlab.net/gitlab-com/chatops/-/project_members) to add you by running `/chatops run member add <username> gitlab-com/chatops --ops`.
 
 ## See also
 
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index 32e079f915c..70945cdaacb 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -357,9 +357,16 @@ However, if a spec makes direct Redis calls, it should mark itself with the
 `:clean_gitlab_redis_queues` traits as appropriate.
 
 Sidekiq jobs are typically not run in specs, but this behaviour can be altered
-in each spec through the use of `perform_enqueued_jobs` blocks. Any spec that
-causes Sidekiq jobs to be pushed to Redis should use the `:sidekiq` trait, to
-ensure that they are removed once the spec completes.
+in each spec through the use of `perform_enqueued_jobs` blocks.
+Any spec that causes Sidekiq jobs to be pushed to Redis should use the
+`:sidekiq_inline` trait, to ensure that they are removed once the spec completes.
+
+The `:sidekiq_might_not_need_inline` trait was added when [Sidekiq inline mode was
+changed to fake mode](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31662)
+to all the examples that needed Sidekiq to actually process jobs. Examples with
+this trait should be either fixed to not rely on Sidekiq processing jobs, or their
+`:sidekiq_might_not_need_inline` trait should be updated to `:sidekiq_inline` if the
+processing of background jobs is needed/expected.
 
 #### Filesystem
 
diff --git a/doc/security/webhooks.md b/doc/security/webhooks.md
index b9af1ac108f..cb9ad2b694c 100644
--- a/doc/security/webhooks.md
+++ b/doc/security/webhooks.md
@@ -9,19 +9,24 @@ local network, these may be vulnerable to exploitation via Webhooks.
 
 With [Webhooks](../user/project/integrations/webhooks.md), you and your project
 maintainers and owners can set up URLs to be triggered when specific changes
-occur in your projects. Normally, these requests are sent to external web services
-specifically set up for this purpose, that process the request and its attached
-data in some appropriate way.
+occur in your projects. Normally, these requests are sent to external web
+services specifically set up for this purpose, that process the request and its
+attached data in some appropriate way.
 
 Things get hairy, however, when a Webhook is set up with a URL that doesn't
 point to an external, but to an internal service, that may do something
 completely unintended when the webhook is triggered and the POST request is
 sent.
 
-Because Webhook requests are made by the GitLab server itself, these have
-complete access to everything running on the server (`http://localhost:123`) or
-within the server's local network (`http://192.168.1.12:345`), even if these
-services are otherwise protected and inaccessible from the outside world.
+Webhook requests are made by the GitLab server itself and use a single
+(optional) secret token per hook for authorization (instead of a user or
+repo-specific token). As a result, these may have broader access than
+intended to everything running on the server hosting the webhook (which
+may include the GitLab server or API itself, e.g., `http://localhost:123`).
+Depending on the called webhook, this may also result in network access
+to other servers within that webhook server's local network (e.g.,
+`http://192.168.1.12:345`), even if these services are otherwise protected
+and inaccessible from the outside world.
 
 If a web service does not require authentication, Webhooks can be used to
 trigger destructive commands by getting the GitLab server to make POST requests
diff --git a/doc/user/application_security/license_compliance/index.md b/doc/user/application_security/license_compliance/index.md
index 75a3b33e32e..c67e66dae5d 100644
--- a/doc/user/application_security/license_compliance/index.md
+++ b/doc/user/application_security/license_compliance/index.md
@@ -94,8 +94,19 @@ always take the latest License Compliance artifact available. Behind the scenes,
 [GitLab License Compliance Docker image](https://gitlab.com/gitlab-org/security-products/license-management)
 is used to detect the languages/frameworks and in turn analyzes the licenses.
 
-The License Compliance settings can be changed through environment variables by using the
-[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`. These variables are documented in the [License Compliance documentation](https://gitlab.com/gitlab-org/security-products/license-management#settings).
+The License Compliance settings can be changed through [environment variables](#available-variables) by using the
+[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`.
+
+### Available variables
+
+License Compliance can be configured using environment variables.
+
+| Environment variable  | Required | Description |
+|-----------------------|----------|-------------|
+| `MAVEN_CLI_OPTS`       | no | Additional arguments for the mvn executable. If not supplied, defaults to `-DskipTests`. |
+| `LM_JAVA_VERSION`      | no | Version of Java. If set to `11`, Maven and Gradle use Java 11 instead of Java 8. |
+| `LM_PYTHON_VERSION`    | no | Version of Python. If set to `3`, dependencies are installed using Python 3 instead of Python 2.7. |
+| `SETUP_CMD`            | no | Custom setup for the dependency installation. (experimental) |
 
 ### Installing custom dependencies