Add latest changes from gitlab-org/gitlab@master

10 files changed, 60 insertions, 47 deletions

diff --git a/app/assets/javascripts/vue_merge_request_widget/components/states/commits_header.vue b/app/assets/javascripts/vue_merge_request_widget/components/states/commits_header.vue
index a55dba92e16..e57f9938011 100644
--- a/app/assets/javascripts/vue_merge_request_widget/components/states/commits_header.vue
+++ b/app/assets/javascripts/vue_merge_request_widget/components/states/commits_header.vue
@@ -1,12 +1,16 @@
 <script>
 /* eslint-disable @gitlab/require-string-literal-i18n-helpers */
-import { GlButton } from '@gitlab/ui';
+import { GlButton, GlSprintf } from '@gitlab/ui';
 import { escape } from 'lodash';
-import { __, n__, sprintf, s__ } from '~/locale';
+import { __, n__, s__ } from '~/locale';
+
+const mergeCommitCount = s__('mrWidgetCommitsAdded|1 merge commit');
 
 export default {
+  mergeCommitCount,
   components: {
     GlButton,
+    GlSprintf,
   },
   props: {
     isSquashEnabled: {
@@ -47,22 +51,15 @@ export default {
     ariaLabel() {
       return this.expanded ? __('Collapse') : __('Expand');
     },
+    targetBranchEscaped() {
+      return escape(this.targetBranch);
+    },
     message() {
-      const message = this.isFastForwardEnabled
+      return this.isFastForwardEnabled
         ? s__('mrWidgetCommitsAdded|%{commitCount} will be added to %{targetBranch}.')
         : s__(
             'mrWidgetCommitsAdded|%{commitCount} and %{mergeCommitCount} will be added to %{targetBranch}.',
           );
-
-      return sprintf(
-        message,
-        {
-          commitCount: `<strong class="commits-count-message">${this.commitsCountMessage}</strong>`,
-          mergeCommitCount: `<strong>${s__('mrWidgetCommitsAdded|1 merge commit')}</strong>`,
-          targetBranch: `<span class="label-branch">${escape(this.targetBranch)}</span>`,
-        },
-        false,
-      );
     },
   },
   methods: {
@@ -89,10 +86,19 @@ export default {
       />
       <span v-if="expanded">{{ __('Collapse') }}</span>
       <span v-else>
-        <span
-          class="vertical-align-middle"
-          v-html="message /* eslint-disable-line vue/no-v-html */"
-        ></span>
+        <span class="vertical-align-middle">
+          <gl-sprintf :message="message">
+            <template #commitCount>
+              <strong class="commits-count-message">{{ commitsCountMessage }}</strong>
+            </template>
+            <template #mergeCommitCount>
+              <strong>{{ $options.mergeCommitCount }}</strong>
+            </template>
+            <template #targetBranch>
+              <span class="label-branch">{{ targetBranchEscaped }}</span>
+            </template>
+          </gl-sprintf>
+        </span>
         <gl-button variant="link" class="modify-message-button">
           {{ modifyLinkMessage }}
         </gl-button>
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index eb666f1caf4..81eb36d38ab 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -1309,12 +1309,7 @@ To minimize data loss in GitLab 13.0 to 14.0, Gitaly Cluster:
 new primary. If the failed primary contained unreplicated writes, [data loss can occur](#check-for-data-loss).
 > - Removed in GitLab 14.1. Instead, repositories [become unavailable](#unavailable-repositories).
 
-In GitLab 13.0 to 14.0, when Gitaly Cluster switches to a new primary, repositories enter
-read-only mode if they are out of date. This can happen after failing over to an outdated
-secondary. Read-only mode eases data recovery efforts by preventing writes that may conflict
-with the unreplicated writes on other nodes.
-
-When Gitaly Cluster switches to a new primary In GitLab 13.0 to 14.0, repositories enter
+When Gitaly Cluster switches to a new primary in GitLab 13.0 to 14.0, repositories enter
 read-only mode if they are out of date. This can happen after failing over to an outdated
 secondary. Read-only mode eases data recovery efforts by preventing writes that may conflict
 with the unreplicated writes on other nodes.
diff --git a/doc/api/applications.md b/doc/api/applications.md
index 2b5eff68010..22d858bd68a 100644
--- a/doc/api/applications.md
+++ b/doc/api/applications.md
@@ -34,14 +34,14 @@ Parameters:
 |:---------------|:--------|:---------|:---------------------------------|
 | `name`         | string  | yes      | Name of the application.         |
 | `redirect_uri` | string  | yes      | Redirect URI of the application. |
-| `scopes`       | string  | yes      | Scopes of the application.       |
+| `scopes`       | string  | yes      | Scopes of the application. You can specify multiple scopes by separating each scope using a space. |
 | `confidential` | boolean | no       | The application is used where the client secret can be kept confidential. Native mobile apps and Single Page Apps are considered non-confidential. Defaults to `true` if not supplied |
 
 Example request:
 
 ```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
-     --data "name=MyApplication&redirect_uri=http://redirect.uri&scopes=" \
+     --data "name=MyApplication&redirect_uri=http://redirect.uri&scopes=api read_user email" \
      "https://gitlab.example.com/api/v4/applications"
 ```
 
diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md
index d5adedc611c..9a4290ead4c 100644
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@@ -572,7 +572,7 @@ The configuration is picked up by the `dind` service.
 ## Authenticate with registry in Docker-in-Docker
 
 When you use Docker-in-Docker, the
-[standard authentication methods](using_docker_images.md#define-an-image-from-a-private-container-registry)
+[standard authentication methods](using_docker_images.md#access-an-image-from-a-private-container-registry)
 don't work because a fresh Docker daemon is started with the service.
 
 ### Option 1: Run `docker login`
diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md
index c2991ce66f9..79c23d73a68 100644
--- a/doc/ci/docker/using_docker_images.md
+++ b/doc/ci/docker/using_docker_images.md
@@ -214,7 +214,7 @@ Look for the `[runners.docker]` section:
 The image and services defined this way are added to all jobs run by
 that runner.
 
-## Define an image from a private Container Registry
+## Access an image from a private Container Registry
 
 To access private container registries, the GitLab Runner process can use:
 
@@ -224,19 +224,12 @@ To access private container registries, the GitLab Runner process can use:
 
 To define which option should be used, the runner process reads the configuration in this order:
 
-- A `DOCKER_AUTH_CONFIG` variable provided as either:
-  - A [CI/CD variable](../variables/index.md) in the `.gitlab-ci.yml` file.
-  - A project's variables stored on the project's **Settings > CI/CD** page.
-- A `DOCKER_AUTH_CONFIG` variable provided as environment variable in the runner's `config.toml` file.
+- A `DOCKER_AUTH_CONFIG` [CI/CD variable](../variables/index.md).
+- A `DOCKER_AUTH_CONFIG` environment variable set in the runner's `config.toml` file.
 - A `config.json` file in `$HOME/.docker` directory of the user running the process.
   If the `--user` flag is provided to run the child processes as unprivileged user,
   the home directory of the main runner process user is used.
 
-The runner reads this configuration **only** from the `config.toml` file and ignores it if
-it's provided as a CI/CD variable. This is because the runner uses **only**
-`config.toml` configuration and does not interpolate **any** CI/CD variables at
-runtime.
-
 ### Requirements and limitations
 
 - Available for [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes.html)
@@ -253,9 +246,9 @@ private registry. Both require setting the CI/CD variable
 `DOCKER_AUTH_CONFIG` with appropriate authentication information.
 
 1. Per-job: To configure one job to access a private registry, add
-   `DOCKER_AUTH_CONFIG` as a job variable.
+   `DOCKER_AUTH_CONFIG` as a [CI/CD variable](../variables/index.md).
 1. Per-runner: To configure a runner so all its jobs can access a
-   private registry, add `DOCKER_AUTH_CONFIG` to the environment in the
+   private registry, add `DOCKER_AUTH_CONFIG` as an environment variable in the
    runner's configuration.
 
 See below for examples of each.
@@ -274,7 +267,7 @@ Let's also assume that these are the sign-in credentials:
 | username | `my_username`               |
 | password | `my_password`               |
 
-Use one of the following methods to determine the value of `DOCKER_AUTH_CONFIG`:
+Use one of the following methods to determine the value for `DOCKER_AUTH_CONFIG`:
 
 - Do a `docker login` on your local machine:
 
diff --git a/doc/development/filtering_by_label.md b/doc/development/filtering_by_label.md
index 2b9c7efc087..6f9811f7e05 100644
--- a/doc/development/filtering_by_label.md
+++ b/doc/development/filtering_by_label.md
@@ -82,6 +82,19 @@ AND (EXISTS (
 While this worked without schema changes, and did improve readability somewhat,
 it did not improve query performance.
 
+### Attempt A2: use label IDs in the WHERE EXISTS clause
+
+In [merge request #34503](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/34503), we followed a similar approach to A1. But this time, we
+did a separate query to fetch the IDs of the labels used in the filter so that we avoid the `JOIN` in the `EXISTS` clause and filter directly by
+`label_links.label_id`. We also added a new index on `label_links` for the `target_id`, `label_id`, and `target_type` columns to speed up this query.
+
+Finding the label IDs wasn't straightforward because there could be multiple labels with the same title within a single root namespace. We solved
+this by grouping the label IDs by title and then using the array of IDs in the `EXISTS` clauses.
+
+This resulted in a significant performance improvement. However, this optimization could not be applied to the dashboard pages
+where we do not have a project or group context. We could not easily search for the label IDs here because that would mean searching across all
+projects and groups that the user has access to.
+
 ## Attempt B: Denormalize using an array column
 
 Having [removed MySQL support in GitLab 12.1](https://about.gitlab.com/blog/2019/06/27/removing-mysql-support/),
@@ -159,9 +172,8 @@ However, at present, the disadvantages outweigh the advantages.
 
 ## Conclusion
 
-We have yet to find a method that is demonstrably better than the current
-method, when considering:
+We found a method A2 that does not need denormalization and improves the query performance significantly. This
+did not apply to all cases, but we were able to apply method A1 to the rest of the cases so that we remove the
+`GROUP BY` and `HAVING` clauses in all scenarios.
 
-1. Query performance.
-1. Readability.
-1. Ease of maintaining schema consistency.
+This simplified the query and improved the performance in the most common cases.
diff --git a/doc/development/service_ping/implement.md b/doc/development/service_ping/implement.md
index d86b06a6965..d9e5e0cda90 100644
--- a/doc/development/service_ping/implement.md
+++ b/doc/development/service_ping/implement.md
@@ -340,6 +340,9 @@ WARNING:
 HyperLogLog (HLL) is a probabilistic algorithm and its **results always includes some small error**. According to [Redis documentation](https://redis.io/commands/pfcount), data from
 used HLL implementation is "approximated with a standard error of 0.81%".
 
+NOTE:
+ A user's consent for usage_stats (`User.single_user&.requires_usage_stats_consent?`) is not checked during the data tracking stage due to performance reasons. Keys corresponding to those counters are present in Redis even if `usage_stats_consent` is still required. However, no metric is collected from Redis and reported back to GitLab as long as `usage_stats_consent` is required.
+
 With `Gitlab::UsageDataCounters::HLLRedisCounter` we have available data structures used to count unique values.
 
 Implemented using Redis methods [PFADD](https://redis.io/commands/pfadd) and [PFCOUNT](https://redis.io/commands/pfcount).
diff --git a/doc/user/packages/dependency_proxy/index.md b/doc/user/packages/dependency_proxy/index.md
index 5b6fd3d1e9b..45227638317 100644
--- a/doc/user/packages/dependency_proxy/index.md
+++ b/doc/user/packages/dependency_proxy/index.md
@@ -66,7 +66,7 @@ has disrupted your existing Dependency Proxy usage.
 Because the Dependency Proxy is storing Docker images in a space associated with your group,
 you must authenticate against the Dependency Proxy.
 
-Follow the [instructions for using images from a private registry](../../../ci/docker/using_docker_images.md#define-an-image-from-a-private-container-registry),
+Follow the [instructions for using images from a private registry](../../../ci/docker/using_docker_images.md#access-an-image-from-a-private-container-registry),
 but instead of using `registry.example.com:5000`, use your GitLab domain with no port `gitlab.example.com`.
 
 For example, to manually log in:
diff --git a/doc/user/permissions.md b/doc/user/permissions.md
index 7ad6ffd2980..4bedf7a3ad9 100644
--- a/doc/user/permissions.md
+++ b/doc/user/permissions.md
@@ -534,8 +534,8 @@ users:
 | Push container images to other projects     |                 |             |          |         |
 | Push source and LFS                         |                 |             |          |         |
 
-1. Only if the user is not an external one
-1. Only if the user is a member of the project
+1. Only if the triggering user is not an external one
+1. Only if the triggering user is a member of the project
 
 ## Running pipelines on protected branches
 
diff --git a/spec/frontend/vue_mr_widget/components/states/mr_widget_commits_header_spec.js b/spec/frontend/vue_mr_widget/components/states/mr_widget_commits_header_spec.js
index b31a75f30d3..2ff94a547f4 100644
--- a/spec/frontend/vue_mr_widget/components/states/mr_widget_commits_header_spec.js
+++ b/spec/frontend/vue_mr_widget/components/states/mr_widget_commits_header_spec.js
@@ -1,4 +1,5 @@
 import { shallowMount } from '@vue/test-utils';
+import { GlSprintf } from '@gitlab/ui';
 import CommitsHeader from '~/vue_merge_request_widget/components/states/commits_header.vue';
 
 describe('Commits header component', () => {
@@ -6,6 +7,9 @@ describe('Commits header component', () => {
 
   const createComponent = (props) => {
     wrapper = shallowMount(CommitsHeader, {
+      stubs: {
+        GlSprintf,
+      },
       propsData: {
         isSquashEnabled: false,
         targetBranch: 'main',