Add latest changes from gitlab-org/gitlab@master

.rubocop_todo/rails/pluck.yml

@@ -297,6 +297,7 @@ Rails/Pluck:
     - 'spec/support/shared_examples/graphql/mutation_shared_examples.rb'
     - 'spec/support/shared_examples/requests/api/container_repositories_shared_examples.rb'
     - 'spec/support/shared_examples/requests/api/custom_attributes_shared_examples.rb'
+    - 'spec/support/shared_examples/requests/api/graphql/issue_list_shared_examples.rb'
     - 'spec/support/shared_examples/requests/api/graphql/packages/group_and_project_packages_list_shared_examples.rb'
     - 'spec/support/shared_examples/requests/api/graphql/packages/package_details_shared_examples.rb'
     - 'spec/support/shared_examples/requests/api/labels_api_shared_examples.rb'

app/finders/repositories/tree_finder.rb

@@ -1,15 +1,13 @@
 # frozen_string_literal: true
 
 module Repositories
-  class TreeFinder < GitRefsFinder
-    attr_reader :user_project
-
+  class TreeFinder
     CommitMissingError = Class.new(StandardError)
 
-    def initialize(user_project, params = {})
-      super(user_project.repository, params)
-
-      @user_project = user_project
+    def initialize(project, params = {})
+      @project = project
+      @repository = project.repository
+      @params = params
     end
 
     def execute(gitaly_pagination: false)
@@ -17,15 +15,15 @@ module Repositories
 
       request_params = { recursive: recursive }
       request_params[:pagination_params] = pagination_params if gitaly_pagination
-      tree = user_project.repository.tree(commit.id, path, **request_params)
 
-      tree.sorted_entries
+      repository.tree(commit.id, path, **request_params).sorted_entries
     end
 
     def total
       # This is inefficient and we'll look at replacing this implementation
-      Gitlab::Cache.fetch_once([user_project, repository.commit, :tree_size, commit.id, path, recursive]) do
-        user_project.repository.tree(commit.id, path, recursive: recursive).entries.size
+      cache_key = [project, repository.commit, :tree_size, commit.id, path, recursive]
+      Gitlab::Cache.fetch_once(cache_key) do
+        repository.tree(commit.id, path, recursive: recursive).entries.size
       end
     end
 
@@ -35,12 +33,14 @@ module Repositories
 
     private
 
+    attr_reader :project, :repository, :params
+
     def commit
-      @commit ||= user_project.commit(ref)
+      @commit ||= project.commit(ref)
     end
 
     def ref
-      params[:ref] || user_project.default_branch
+      params[:ref] || project.default_branch
     end
 
     def path

doc/architecture/blueprints/pods/index.md

@@ -326,6 +326,15 @@ This is the list of known affected features with the proposed solutions.
 - [Pods: Router Endpoints Classification](pods-feature-router-endpoints-classification.md)
 - [Pods: Schema changes (Postgres and Elasticsearch migrations)](pods-feature-schema-changes.md)
 - [Pods: Global Search](pods-feature-global-search.md)
+- [Pods: CI Runners](pods-feature-ci-runners.md)
+- [Pods: Admin Area](pods-feature-admin-area.md)
+- [Pods: Container Registry](pods-feature-container-registry.md)
+- [Pods: Contributions: Forks](pods-feature-contributions-forks.md)
+- [Pods: Personal Namespaces](pods-feature-personal-namespaces.md)
+- [Pods: Dashboard: Projects, Todos, Issues, Merge Requests, Activity, ...](pods-feature-dashboard.md)
+- [Pods: Snippets](pods-feature-snippets.md)
+- [Pods: Uploads](pods-feature-uploads.md)
+- [Pods: GitLab Pages](pods-feature-gitlab-pages.md)
 
 ## Links
 

doc/architecture/blueprints/pods/pods-feature-admin-area.md

@@ -0,0 +1,29 @@
+---
+stage: enablement
+group: pods
+comments: false
+description: 'Pods: Admin Area'
+---
+
+This document is a work-in-progress and represents a very early state of the
+Pods design. Significant aspects are not documented, though we expect to add
+them in the future. This is one possible architecture for Pods, and we intend to
+contrast this with alternatives before deciding which approach to implement.
+This documentation will be kept even if we decide not to implement this so that
+we can document the reasons for not choosing this approach.
+
+# Pods: Admin Area
+
+> TL;DR
+
+## 1. Definition
+
+## 2. Data flow
+
+## 3. Proposal
+
+## 4. Evaluation
+
+## 4.1. Pros
+
+## 4.2. Cons

doc/architecture/blueprints/pods/pods-feature-ci-runners.md

@@ -0,0 +1,29 @@
+---
+stage: enablement
+group: pods
+comments: false
+description: 'Pods: CI Runners'
+---
+
+This document is a work-in-progress and represents a very early state of the
+Pods design. Significant aspects are not documented, though we expect to add
+them in the future. This is one possible architecture for Pods, and we intend to
+contrast this with alternatives before deciding which approach to implement.
+This documentation will be kept even if we decide not to implement this so that
+we can document the reasons for not choosing this approach.
+
+# Pods: CI Runners
+
+> TL;DR
+
+## 1. Definition
+
+## 2. Data flow
+
+## 3. Proposal
+
+## 4. Evaluation
+
+## 4.1. Pros
+
+## 4.2. Cons

doc/architecture/blueprints/pods/pods-feature-container-registry.md

@@ -0,0 +1,29 @@
+---
+stage: enablement
+group: pods
+comments: false
+description: 'Pods: Container Registry'
+---
+
+This document is a work-in-progress and represents a very early state of the
+Pods design. Significant aspects are not documented, though we expect to add
+them in the future. This is one possible architecture for Pods, and we intend to
+contrast this with alternatives before deciding which approach to implement.
+This documentation will be kept even if we decide not to implement this so that
+we can document the reasons for not choosing this approach.
+
+# Pods: Container Registry
+
+> TL;DR
+
+## 1. Definition
+
+## 2. Data flow
+
+## 3. Proposal
+
+## 4. Evaluation
+
+## 4.1. Pros
+
+## 4.2. Cons

doc/architecture/blueprints/pods/pods-feature-contributions-forks.md

@@ -0,0 +1,29 @@
+---
+stage: enablement
+group: pods
+comments: false
+description: 'Pods: Contributions: Forks'
+---
+
+This document is a work-in-progress and represents a very early state of the
+Pods design. Significant aspects are not documented, though we expect to add
+them in the future. This is one possible architecture for Pods, and we intend to
+contrast this with alternatives before deciding which approach to implement.
+This documentation will be kept even if we decide not to implement this so that
+we can document the reasons for not choosing this approach.
+
+# Pods: Contributions: Forks
+
+> TL;DR
+
+## 1. Definition
+
+## 2. Data flow
+
+## 3. Proposal
+
+## 4. Evaluation
+
+## 4.1. Pros
+
+## 4.2. Cons

doc/architecture/blueprints/pods/pods-feature-dashboard.md

@@ -0,0 +1,29 @@
+---
+stage: enablement
+group: pods
+comments: false
+description: 'Pods: Dashboard'
+---
+
+This document is a work-in-progress and represents a very early state of the
+Pods design. Significant aspects are not documented, though we expect to add
+them in the future. This is one possible architecture for Pods, and we intend to
+contrast this with alternatives before deciding which approach to implement.
+This documentation will be kept even if we decide not to implement this so that
+we can document the reasons for not choosing this approach.
+
+# Pods: Dashboard
+
+> TL;DR
+
+## 1. Definition
+
+## 2. Data flow
+
+## 3. Proposal
+
+## 4. Evaluation
+
+## 4.1. Pros
+
+## 4.2. Cons

doc/architecture/blueprints/pods/pods-feature-gitlab-pages.md

@@ -0,0 +1,29 @@
+---
+stage: enablement
+group: pods
+comments: false
+description: 'Pods: GitLab Pages'
+---
+
+This document is a work-in-progress and represents a very early state of the
+Pods design. Significant aspects are not documented, though we expect to add
+them in the future. This is one possible architecture for Pods, and we intend to
+contrast this with alternatives before deciding which approach to implement.
+This documentation will be kept even if we decide not to implement this so that
+we can document the reasons for not choosing this approach.
+
+# Pods: GitLab Pages
+
+> TL;DR
+
+## 1. Definition
+
+## 2. Data flow
+
+## 3. Proposal
+
+## 4. Evaluation
+
+## 4.1. Pros
+
+## 4.2. Cons

doc/architecture/blueprints/pods/pods-feature-personal-namespaces.md

@@ -0,0 +1,29 @@
+---
+stage: enablement
+group: pods
+comments: false
+description: 'Pods: Personal Namespaces'
+---
+
+This document is a work-in-progress and represents a very early state of the
+Pods design. Significant aspects are not documented, though we expect to add
+them in the future. This is one possible architecture for Pods, and we intend to
+contrast this with alternatives before deciding which approach to implement.
+This documentation will be kept even if we decide not to implement this so that
+we can document the reasons for not choosing this approach.
+
+# Pods: Personal Namespaces
+
+> TL;DR
+
+## 1. Definition
+
+## 2. Data flow
+
+## 3. Proposal
+
+## 4. Evaluation
+
+## 4.1. Pros
+
+## 4.2. Cons

doc/architecture/blueprints/pods/pods-feature-snippets.md

@@ -0,0 +1,29 @@
+---
+stage: enablement
+group: pods
+comments: false
+description: 'Pods: Snippets'
+---
+
+This document is a work-in-progress and represents a very early state of the
+Pods design. Significant aspects are not documented, though we expect to add
+them in the future. This is one possible architecture for Pods, and we intend to
+contrast this with alternatives before deciding which approach to implement.
+This documentation will be kept even if we decide not to implement this so that
+we can document the reasons for not choosing this approach.
+
+# Pods: Snippets
+
+> TL;DR
+
+## 1. Definition
+
+## 2. Data flow
+
+## 3. Proposal
+
+## 4. Evaluation
+
+## 4.1. Pros
+
+## 4.2. Cons

doc/architecture/blueprints/pods/pods-feature-uploads.md

@@ -0,0 +1,29 @@
+---
+stage: enablement
+group: pods
+comments: false
+description: 'Pods: Uploads'
+---
+
+This document is a work-in-progress and represents a very early state of the
+Pods design. Significant aspects are not documented, though we expect to add
+them in the future. This is one possible architecture for Pods, and we intend to
+contrast this with alternatives before deciding which approach to implement.
+This documentation will be kept even if we decide not to implement this so that
+we can document the reasons for not choosing this approach.
+
+# Pods: Uploads
+
+> TL;DR
+
+## 1. Definition
+
+## 2. Data flow
+
+## 3. Proposal
+
+## 4. Evaluation
+
+## 4.1. Pros
+
+## 4.2. Cons

doc/ci/yaml/artifacts_reports.md

@@ -107,19 +107,17 @@ GitLab can display the results of coverage report in the merge request
 
 ## `artifacts:reports:codequality`
 
-> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/212499) to GitLab Free in 13.2.
+> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/212499) to GitLab Free in 13.2.
+> - [Added support for multiple reports in diff annotations and full pipeline report](https://gitlab.com/gitlab-org/gitlab/-/issues/9014) in 15.7.
 
 The `codequality` report collects [code quality issues](../testing/code_quality.md). The
 collected code quality report uploads to GitLab as an artifact.
 
-GitLab can display the results of:
+GitLab can display the results of one or more reports in:
 
-- One or more reports in the merge request [code quality widget](../testing/code_quality.md#code-quality-widget).
-- Only one report in:
-  - The merge request [diff annotations](../testing/code_quality.md#code-quality-in-diff-view).
-    Track progress on adding support for multiple reports in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/328257).
-  - The [full report](../testing/metrics_reports.md). Track progress on adding support for multiple reports in
-    [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/9014).
+- The merge request [code quality widget](../testing/code_quality.md#code-quality-widget).
+- The merge request [diff annotations](../testing/code_quality.md#code-quality-in-diff-view).
+- The [full report](../testing/metrics_reports.md).
 
 ## `artifacts:reports:container_scanning` **(ULTIMATE)**
 

spec/features/projects/settings/repository_settings_spec.rb

@@ -165,7 +165,12 @@ RSpec.describe 'Projects > Settings > Repository settings' do
 
         project.reload
 
-        expect(page).to have_content('Mirroring settings were successfully updated')
+        # TODO: The following line is skipped because a toast with
+        # "An error occurred while loading branch rules. Please try again."
+        # shows up right after which hides the below message. It is causing flakiness.
+        # https://gitlab.com/gitlab-org/gitlab/-/issues/383717#note_1185091998
+
+        # expect(page).to have_content('Mirroring settings were successfully updated')
         expect(project.remote_mirrors.first.only_protected_branches).to eq(false)
       end
 
@@ -186,7 +191,12 @@ RSpec.describe 'Projects > Settings > Repository settings' do
 
         project.reload
 
-        expect(page).to have_content('Mirroring settings were successfully updated')
+        # TODO: The following line is skipped because a toast with
+        # "An error occurred while loading branch rules. Please try again."
+        # shows up right after which hides the below message. It is causing flakiness.
+        # https://gitlab.com/gitlab-org/gitlab/-/issues/383717#note_1185091998
+
+        # expect(page).to have_content('Mirroring settings were successfully updated')
         expect(project.remote_mirrors.first.only_protected_branches).to eq(true)
       end