Add latest changes from gitlab-org/gitlab@master

GITALY_SERVER_VERSION

@@ -1 +1 @@
-b5f5b5a9a3ee4ba8f9fb6678a35e400e1087ba04
+ba88310205fe3a79a1f1eade7e5cbff65a904e4d

Gemfile

@@ -74,7 +74,7 @@ gem 'u2f', '~> 0.2.1'
 gem 'validates_hostname', '~> 1.0.11'
 gem 'rubyzip', '~> 2.0.0', require: 'zip'
 # GitLab Pages letsencrypt support
-gem 'acme-client', '~> 2.0', '>= 2.0.6'
+gem 'acme-client', '~> 2.0', '>= 2.0.9'
 
 # Browser detection
 gem 'browser', '~> 4.2'

Gemfile.lock

@@ -9,7 +9,7 @@ GEM
   remote: https://rubygems.org/
   specs:
     RedCloth (4.3.2)
-    acme-client (2.0.6)
+    acme-client (2.0.9)
       faraday (>= 0.17, < 2.0.0)
     actioncable (6.1.4.1)
       actionpack (= 6.1.4.1)
@@ -1388,7 +1388,7 @@ PLATFORMS
 
 DEPENDENCIES
   RedCloth (~> 4.3.2)
-  acme-client (~> 2.0, >= 2.0.6)
+  acme-client (~> 2.0, >= 2.0.9)
   activerecord-explain-analyze (~> 0.1)
   acts-as-taggable-on (~> 8.1)
   addressable (~> 2.8)

app/controllers/search_controller.rb

@@ -143,6 +143,7 @@ class SearchController < ApplicationController
     payload[:metadata]['meta.search.filters.confidential'] = params[:confidential]
     payload[:metadata]['meta.search.filters.state'] = params[:state]
     payload[:metadata]['meta.search.force_search_results'] = params[:force_search_results]
+    payload[:metadata]['meta.search.project_ids'] = params[:project_ids]
 
     if search_service.abuse_detected?
       payload[:metadata]['abuse.confidence'] = Gitlab::Abuse.confidence(:certain)

app/views/projects/deployments/_deployment.html.haml

@@ -27,8 +27,7 @@
             = link_to deployment_path(deployment), class: 'build-link' do
               #{deployment.deployable.name} (##{deployment.deployable.id})
     - else
-      .badge.badge-info.gl-cursor-help{ title: s_('Deployment|This deployment was created using the API') }
+      = gl_badge_tag s_('Deployment|API'), { variant: :info }, { class: 'gl-cursor-help', data: { toggle: 'tooltip' }, title: s_('Deployment|This deployment was created using the API') }
-        = s_('Deployment|API')
 
   .table-section.section-10{ role: 'gridcell' }
     .table-mobile-header{ role: 'rowheader' }= _("Created")

db/post_migrate/20211229023654_add_async_index_ci_job_artifacts_project_id_file_type.rb

@@ -0,0 +1,15 @@
+# frozen_string_literal: true
+
+class AddAsyncIndexCiJobArtifactsProjectIdFileType < Gitlab::Database::Migration[1.0]
+  disable_ddl_transaction!
+
+  INDEX_NAME = 'index_ci_job_artifacts_on_id_project_id_and_file_type'
+
+  def up
+    prepare_async_index :ci_job_artifacts, [:project_id, :file_type, :id], name: INDEX_NAME
+  end
+
+  def down
+    unprepare_async_index_by_name :ci_job_artifacts, INDEX_NAME
+  end
+end

db/schema_migrations/20211229023654

@@ -0,0 +1 @@
+8019915a00f62c137ee48c860c888e9d43f7253a5ea1a684ba2abe8bbe8016df

doc/administration/geo/replication/troubleshooting.md

@@ -689,7 +689,7 @@ Secondaries would regularly try to sync these files again via the "verification"
 
 This can be confusing to troubleshoot, since the registry entries are moved through a logical loop by various background jobs. Also, `last_sync_failure` and `verification_failure` are empty after "sync succeeded" but before verification is retried.
 
-If you see sync failures repeatedly and alternately increase, while successes decrease and vice versa, this is a problem of missing files on the primary site. You can confirm this by searching `geo.log` on secondary sites for `File is not checksummable` affecting the same files over and over.
+If you see sync failures repeatedly and alternately increase, while successes decrease and vice versa, this is likely to be caused by missing files on the primary site. You can confirm this by searching `geo.log` on secondary sites for `File is not checksummable` affecting the same files over and over.
 
 After confirming this is the problem, the files on the primary site need to be fixed. Some possible causes:
 

doc/ci/jobs/job_control.md

@@ -777,7 +777,7 @@ job1:
     - echo
   rules:
     - if: $CI_PIPELINE_SOURCE == "merge_request_event"
-    - if: $CI_PIPELINE_SOURCE == "scheduled"
+    - if: $CI_PIPELINE_SOURCE == "schedule"
     - if: $CI_PIPELINE_SOURCE == "push"
       when: never
 ```

doc/development/documentation/styleguide/index.md

@@ -1626,7 +1626,7 @@ the section. The version information must:
 - Be surrounded by blank lines.
 - Start with `>`. If there are multiple bullets, each line must start with `> -`.
 - The string must include these words in this order (capitalization doesn't matter):
-  - `introduced`, `deprecated`, `changed`, `moved`, `recommended` (as in the
+  - `introduced`, `enabled`, `deprecated`, `changed`, `moved`, `recommended` (as in the
   [feature flag documentation](../feature_flags.md)), `removed`, or `renamed`
   - `in` or `to`
   - `GitLab`

doc/integration/saml.md

@@ -917,8 +917,10 @@ You may also find the [SAML Tracer](https://addons.mozilla.org/en-US/firefox/add
 ### Invalid audience
 
 This error means that the IdP doesn't recognize GitLab as a valid sender and
-receiver of SAML requests. Make sure to add the GitLab callback URL to the approved
+receiver of SAML requests. Make sure to:
-audiences of the IdP server.
+
+- Add the GitLab callback URL to the approved audiences of the IdP server.
+- Avoid trailing whitespace in the `issuer` string.
 
 ### Missing claims, or `Email can't be blank` errors
 

doc/user/project/import/github.md

@@ -165,16 +165,16 @@ your GitHub repositories are listed.
 
 ![GitHub importer page](img/import_projects_from_github_importer_v12_3.png)
 
-## Mirror a repository and share pipeline status
+## Mirror a repository and share pipeline status **(PREMIUM)**
 
 Depending on your GitLab tier, [repository mirroring](../repository/mirror/index.md) can be set up to keep
 your imported repository in sync with its GitHub copy.
 
-Additionally, you can configure GitLab to send pipeline status updates back GitHub with the
+Additionally, you can configure GitLab to send pipeline status updates back to GitHub with the
-[GitHub Project Integration](../integrations/github.md). **(PREMIUM)**
+[GitHub Project Integration](../integrations/github.md).
 
 If you import your project using [CI/CD for external repository](../../../ci/ci_cd_for_external_repos/index.md), then both
-of the above are automatically configured. **(PREMIUM)**
+of the above are automatically configured.
 
 NOTE:
 Mirroring does not sync any new or updated pull requests from your GitHub project.

doc/user/project/import/index.md

@@ -28,7 +28,7 @@ See these documents to migrate to GitLab:
 You can also import any Git repository through HTTP from the **New Project** page. Note that if the
 repository is too large, the import can timeout.
 
-You can also [connect your external repository to get CI/CD benefits](../../../ci/ci_cd_for_external_repos/index.md). **(PREMIUM)**
+You can also [connect your external repository to get CI/CD benefits](../../../ci/ci_cd_for_external_repos/index.md).
 
 ## LFS authentication
 
@@ -90,7 +90,7 @@ to migrate users.
 
 ## Project aliases **(PREMIUM SELF)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3264) in GitLab Premium 12.1.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3264) in GitLab 12.1.
 
 GitLab repositories are usually accessed with a namespace and a project name. When migrating
 frequently accessed repositories to GitLab, however, you can use project aliases to access those

doc/user/project/service_desk.md

@@ -184,9 +184,10 @@ NOTE:
 On GitLab.com a custom mailbox is already configured with `contact-project+%{key}@incoming.gitlab.com` as the email address, you can still configure the
 [custom suffix](#configuring-a-custom-email-address-suffix) in project settings.
 
-Using the `service_desk_email` configuration, you can customize the mailbox
+Service Desk uses the [incoming email](../../administration/incoming_email.md)
-used by Service Desk. This allows you to have a separate email address for
+configuration by default. However, by using the `service_desk_email` configuration,
-Service Desk by also configuring a [custom suffix](#configuring-a-custom-email-address-suffix)
+you can customize the mailbox used by Service Desk. This allows you to have
+a separate email address for Service Desk by also configuring a [custom suffix](#configuring-a-custom-email-address-suffix)
 in project settings.
 
 The `address` must include the `+%{key}` placeholder within the 'user'
@@ -194,10 +195,10 @@ portion of the address, before the `@`. This is used to identify the project
 where the issue should be created.
 
 NOTE:
-The `service_desk_email` and `incoming_email` configurations should
+When configuring a custom mailbox, the `service_desk_email` and `incoming_email`
-always use separate mailboxes. This is important, because emails picked from
+configurations must always use separate mailboxes. This is important, because
-`service_desk_email` mailbox are processed by a different worker and it would
+emails picked from `service_desk_email` mailbox are processed by a different
-not recognize `incoming_email` emails.
+worker and it would not recognize `incoming_email` emails.
 
 To configure a custom mailbox for Service Desk with IMAP, add the following snippets to your configuration file in full:
 

spec/controllers/search_controller_spec.rb

@@ -396,9 +396,10 @@ RSpec.describe SearchController do
           expect(payload[:metadata]['meta.search.force_search_results']).to eq('true')
           expect(payload[:metadata]['meta.search.filters.confidential']).to eq('true')
           expect(payload[:metadata]['meta.search.filters.state']).to eq('true')
+          expect(payload[:metadata]['meta.search.project_ids']).to eq(%w(456 789))
         end
 
-        get :show, params: { scope: 'issues', search: 'hello world', group_id: '123', project_id: '456', confidential: true, state: true, force_search_results: true }
+        get :show, params: { scope: 'issues', search: 'hello world', group_id: '123', project_id: '456', project_ids: %w(456 789), confidential: true, state: true, force_search_results: true }
       end
 
       it 'appends the default scope in meta.search.scope' do