Automatic merge of gitlab-org/gitlab master

.gitlab/ci/rules.gitlab-ci.yml

@@ -1618,8 +1618,10 @@
   rules:
     - if: '$CODE_QUALITY_DISABLED'
       when: never
+    # Run code_quality on master until https://gitlab.com/gitlab-org/gitlab/-/issues/363747 is resolved
+    - <<: *if-default-branch-refs
     - <<: *if-default-refs
-      changes: *code-backstage-patterns
+      changes: *code-backstage-qa-patterns
 
 .reports:rules:brakeman-sast:
   rules:

doc/ci/pipelines/pipeline_architectures.md

@@ -23,6 +23,11 @@ own advantages. These methods can be mixed and matched if needed:
 - [Multi-project pipelines](downstream_pipelines.md#multi-project-pipelines): Good for larger products that require cross-project interdependencies,
   like those with a [microservices architecture](https://about.gitlab.com/blog/2016/08/16/trends-in-version-control-land-microservices/).
 
+  For example, you might deploy your web application from three different GitLab projects.
+  With multi-project pipelines you can trigger a pipeline in each project, where each
+  has its own build, test, and deploy process. You can visualize the connected pipelines
+  in one place, including all cross-project interdependencies.
+
   <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
   For an overview, see the [Multi-project pipelines demo](https://www.youtube.com/watch?v=g_PIwBM1J84).
 

doc/ci/variables/where_variables_can_be_used.md

@@ -41,7 +41,7 @@ There are two places defined variables can be used. On the:
 | [`services:name`](../yaml/index.md#services)                          | yes              | Runner                 | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
 | [`services`](../yaml/index.md#services)                               | yes              | Runner                 | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
 | [`tags`](../yaml/index.md#tags)                                       | yes              | GitLab                 | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35742) in GitLab 14.1. |
-| [`trigger` and `trigger:project`](../yaml/index.md#trigger)           | yes              | GitLab                 | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/367660) in GitLab 15.3. |
+| [`trigger` and `trigger:project`](../yaml/index.md#trigger)           | yes              | GitLab                 | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab. Variable expansion for `trigger:project` [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/367660) in GitLab 15.3. |
 | [`variables`](../yaml/index.md#variables)                             | yes              | GitLab/Runner          | The variable expansion is first made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab, and then any unrecognized or unavailable variables are expanded by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
 
 ### `config.toml` file

ee/spec/services/ci/register_job_service_spec.rb

@@ -240,13 +240,7 @@
     end
   end
 
-  context 'when new pending builds table is used' do
-    before do
-      stub_feature_flags(ci_pending_builds_queue_source: true)
-    end
-
-    include_examples 'namespace minutes quota'
-  end
+  include_examples 'namespace minutes quota'
 
   describe 'ensure plan limitation', :saas do
     let(:allowed_plans) { [] }

qa/qa/specs/features/api/1_manage/import/import_github_repo_spec.rb

@@ -90,6 +90,10 @@ def verify_protected_branches_import
             # code_owner_approval_required: true
           }
         )
+
+        # GitHub branch protection rule "Require signed commits" is mapped to the
+        # "Reject unsigned commits" push rule
+        expect(imported_project.push_rules[:reject_unsigned_commits]).to be_truthy
       end
 
       def verify_commits_import

spec/db/schema_spec.rb

@@ -15,7 +15,7 @@
   }.with_indifferent_access.freeze
 
   # List of columns historically missing a FK, don't add more columns
-  # See: https://docs.gitlab.com/ee/development/foreign_keys.html#naming-foreign-keys
+  # See: https://docs.gitlab.com/ee/development/database/foreign_keys.html#naming-foreign-keys
   IGNORED_FK_COLUMNS = {
     abuse_reports: %w[reporter_id user_id],
     application_settings: %w[performance_bar_allowed_group_id slack_app_id snowplow_app_id eks_account_id eks_access_key_id],