Add latest changes from gitlab-org/gitlab@master

13 files changed, 74 insertions, 34 deletions

diff --git a/doc/administration/file_hooks.md b/doc/administration/file_hooks.md
index c60f0040496..f6bbd2338be 100644
--- a/doc/administration/file_hooks.md
+++ b/doc/administration/file_hooks.md
@@ -79,7 +79,7 @@ require 'json'
 require 'mail'
 
 # The incoming variables are in JSON format so we need to parse it first.
-ARGS = JSON.parse(STDIN.read)
+ARGS = JSON.parse($stdin.read)
 
 # We only want to trigger this file hook on the event project_create
 return unless ARGS['event_name'] == 'project_create'
diff --git a/doc/administration/troubleshooting/debug.md b/doc/administration/troubleshooting/debug.md
index 7be51cae847..c1e51001961 100644
--- a/doc/administration/troubleshooting/debug.md
+++ b/doc/administration/troubleshooting/debug.md
@@ -26,7 +26,7 @@ You can enable output of Active Record debug logging in the Rails console
 session by running:
 
 ```ruby
-ActiveRecord::Base.logger = Logger.new(STDOUT)
+ActiveRecord::Base.logger = Logger.new($stdout)
 ```
 
 This will show information about database queries triggered by any Ruby code
diff --git a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
index 70249a161e0..815c4be3bf2 100644
--- a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
+++ b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
@@ -100,7 +100,7 @@ Rails.cache.instance_variable_get(:@data).keys
 
 ```ruby
 # Before 11.6.0
-logger = Logger.new(STDOUT)
+logger = Logger.new($stdout)
 admin_token = User.find_by_username('ADMIN_USERNAME').personal_access_tokens.first.token
 app.get("URL/?private_token=#{admin_token}")
 
@@ -113,7 +113,7 @@ Gitlab::Profiler.with_user(admin) { app.get(url) }
 ## Using the GitLab profiler inside console (used as of 10.5)
 
 ```ruby
-logger = Logger.new(STDOUT)
+logger = Logger.new($stdout)
 admin = User.find_by_username('ADMIN_USERNAME')
 Gitlab::Profiler.profile('URL', logger: logger, user: admin)
 ```
diff --git a/doc/administration/troubleshooting/navigating_gitlab_via_rails_console.md b/doc/administration/troubleshooting/navigating_gitlab_via_rails_console.md
index 7c0a1c1b397..e55118d7309 100644
--- a/doc/administration/troubleshooting/navigating_gitlab_via_rails_console.md
+++ b/doc/administration/troubleshooting/navigating_gitlab_via_rails_console.md
@@ -46,7 +46,7 @@ Let's enable debug logging for Active Record so we can see the underlying
 database queries made:
 
 ```ruby
-ActiveRecord::Base.logger = Logger.new(STDOUT)
+ActiveRecord::Base.logger = Logger.new($stdout)
 ```
 
 Now, let's try retrieving a user from the database:
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 6fab96fe9ba..724446912aa 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -8570,6 +8570,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
+| <a id="epicboardlistsepicfilters"></a>`epicFilters` | [`EpicFilters`](#epicfilters) | Filters applied when getting epic metadata in the epic board list. |
 | <a id="epicboardlistsid"></a>`id` | [`BoardsEpicListID`](#boardsepiclistid) | Find an epic board list by ID. |
 
 ### `EpicDescendantCount`
diff --git a/doc/development/background_migrations.md b/doc/development/background_migrations.md
index a96606719d0..fb1e61642d7 100644
--- a/doc/development/background_migrations.md
+++ b/doc/development/background_migrations.md
@@ -255,12 +255,8 @@ batches instead of doing this one by one:
 class ScheduleExtractServicesUrl < ActiveRecord::Migration[4.2]
   disable_ddl_transaction!
 
-  class Service < ActiveRecord::Base
-    self.table_name = 'services'
-  end
-
   def up
-    Service.select(:id).in_batches do |relation|
+    define_batchable_model('services').select(:id).in_batches do |relation|
       jobs = relation.pluck(:id).map do |id|
         ['ExtractServicesUrl', [id]]
       end
@@ -286,18 +282,12 @@ this:
 class ConsumeRemainingExtractServicesUrlJobs < ActiveRecord::Migration[4.2]
   disable_ddl_transaction!
 
-  class Service < ActiveRecord::Base
-    include ::EachBatch
-
-    self.table_name = 'services'
-  end
-
   def up
     # This must be included
     Gitlab::BackgroundMigration.steal('ExtractServicesUrl')
 
     # This should be included, but can be skipped - see below
-    Service.where(url: nil).each_batch(of: 50) do |batch|
+    define_batchable_model('services').where(url: nil).each_batch(of: 50) do |batch|
       range = batch.pluck('MIN(id)', 'MAX(id)').first
 
       Gitlab::BackgroundMigration::ExtractServicesUrl.new.perform(*range)
diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md
index 6b829faf74d..177b8bf7238 100644
--- a/doc/development/elasticsearch.md
+++ b/doc/development/elasticsearch.md
@@ -308,12 +308,15 @@ We choose to use GitLab major version upgrades as a safe time to remove
 backwards compatibility for indices that have not been fully migrated. We
 [document this in our upgrade
 documentation](../update/index.md#upgrading-to-a-new-major-version). We also
-choose to remove the migration code and tests so that:
+choose to replace the migration code with the halted migration
+and remove tests so that:
 
 - We don't need to maintain any code that is called from our Advanced Search
   migrations.
 - We don't waste CI time running tests for migrations that we don't support
   anymore.
+- Operators who have not run this migration and who upgrade directly to the
+  target version will see a message prompting them to reindex from scratch.
 
 To be extra safe, we will not delete migrations that were created in the last
 minor version before the major upgrade. So, if we are upgrading to `%14.0`,
@@ -334,18 +337,10 @@ For every migration that was created 2 minor versions before the major version
 being upgraded to, we do the following:
 
 1. Confirm the migration has actually completed successfully for GitLab.com.
-1. Replace the content of `migrate` and `completed?` methods as follows:
+1. Replace the content of the migration with:
 
    ```ruby
-   def migrate
-     log_raise "Migration has been deleted in the last major version upgrade." \
-       "Migrations are supposed to be finished before upgrading major version https://docs.gitlab.com/ee/update/#upgrading-to-a-new-major-version ." \
-       "To correct this issue, recreate your index from scratch: https://docs.gitlab.com/ee/integration/elasticsearch.html#last-resort-to-recreate-an-index."
-   end
-
-   def completed?
-     false
-   end
+   include Elastic::MigrationObsolete
    ```
 
 1. Delete any spec files to support this migration.
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 62a81e21da6..ba2c8abd48c 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -976,6 +976,9 @@ If using a model in the migrations, you should first
 [clear the column cache](https://api.rubyonrails.org/classes/ActiveRecord/ModelSchema/ClassMethods.html#method-i-reset_column_information)
 using `reset_column_information`.
 
+If using a model that leverages single table inheritance (STI), there are [special
+considerations](single_table_inheritance.md#in-migrations).
+
 This avoids problems where a column that you are using was altered and cached
 in a previous migration.
 
diff --git a/doc/development/profiling.md b/doc/development/profiling.md
index 81881a4d490..781138a6ade 100644
--- a/doc/development/profiling.md
+++ b/doc/development/profiling.md
@@ -49,7 +49,7 @@ ActiveRecord and ActionController log output to that logger. Further options are
 documented with the method source.
 
 ```ruby
-Gitlab::Profiler.profile('/gitlab-org/gitlab-test', user: User.first, logger: Logger.new(STDOUT))
+Gitlab::Profiler.profile('/gitlab-org/gitlab-test', user: User.first, logger: Logger.new($stdout))
 ```
 
 There is also a RubyProf printer available:
diff --git a/doc/development/single_table_inheritance.md b/doc/development/single_table_inheritance.md
index 6b35d9f71da..aa4fe540b0d 100644
--- a/doc/development/single_table_inheritance.md
+++ b/doc/development/single_table_inheritance.md
@@ -22,3 +22,42 @@ The solution is very simple: just use a separate table for every type you'd
 otherwise store in the same table. For example, instead of having a `keys` table
 with `type` set to either `Key` or `DeployKey` you'd have two separate tables:
 `keys` and `deploy_keys`.
+
+## In migrations
+
+Whenever a model is used in a migration, single table inheritance should be disabled.
+Due to the way Rails loads associations (even in migrations), failing to disable STI
+could result in loading unexpected code or associations which may cause unintended
+side effects or failures during upgrades.
+
+```ruby
+class SomeMigration < ActiveRecord::Migration[6.0]
+  class Services < ActiveRecord::Base
+    self.table_name = 'services'
+    self.inheritance_column = :_type_disabled
+  end
+
+  def up
+  ...
+```
+
+If nothing needs to be added to the model other than disabling STI or `EachBatch`,
+use the helper `define_batchable_model` instead of defining the class.
+This ensures that the migration loads the columns for the migration in isolation,
+and the helper disables STI by default.
+
+```ruby
+class EnqueueSomeBackgroundMigration < ActiveRecord::Migration[6.0]
+  disable_ddl_transaction!
+
+  def up
+    define_batchable_model('services').select(:id).in_batches do |relation|
+      jobs = relation.pluck(:id).map do |id|
+        ['ExtractServicesUrl', [id]]
+      end
+
+      BackgroundMigrationWorker.bulk_perform_async(jobs)
+    end
+  end
+  ...
+```
diff --git a/doc/development/testing_guide/testing_rake_tasks.md b/doc/development/testing_guide/testing_rake_tasks.md
index dc754721e24..30d193de2f2 100644
--- a/doc/development/testing_guide/testing_rake_tasks.md
+++ b/doc/development/testing_guide/testing_rake_tasks.md
@@ -11,19 +11,21 @@ in lieu of the standard Spec helper. Instead of `require 'spec_helper'`, use
 `require 'rake_helper'`. The helper includes `spec_helper` for you, and configures
 a few other things to make testing Rake tasks easier.
 
-At a minimum, requiring the Rake helper redirects `stdout`, include the
-runtime task helpers, and include the `RakeHelpers` Spec support module.
+At a minimum, requiring the Rake helper includes the runtime task helpers, and
+includes the `RakeHelpers` Spec support module.
 
 The `RakeHelpers` module exposes a `run_rake_task(<task>)` method to make
 executing tasks simple. See `spec/support/helpers/rake_helpers.rb` for all available
 methods.
 
+`$stdout` can be redirected by adding `:silence_stdout`.
+
 Example:
 
 ```ruby
 require 'rake_helper'
 
-describe 'gitlab:shell rake tasks' do
+describe 'gitlab:shell rake tasks', :silence_stdout do
   before do
     Rake.application.rake_require 'tasks/gitlab/shell'
 
diff --git a/doc/development/usage_ping/dictionary.md b/doc/development/usage_ping/dictionary.md
index 70c34d490bc..04f5ae3df7a 100644
--- a/doc/development/usage_ping/dictionary.md
+++ b/doc/development/usage_ping/dictionary.md
@@ -15580,11 +15580,11 @@ Whether incoming email is setup
 
 [YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/settings/20210204124916_reply_by_email_enabled.yml)
 
-Group: `group::product intelligence`
+Group: `group::certify`
 
 Status: `data_available`
 
-Tiers: `free`
+Tiers: `free`, `premium`, `ultimate`
 
 ### `search_unique_visits.i_search_advanced`
 
diff --git a/doc/update/index.md b/doc/update/index.md
index 693e5be38ed..c2d0a233e4e 100644
--- a/doc/update/index.md
+++ b/doc/update/index.md
@@ -369,6 +369,16 @@ NOTE:
 Specific information that follow related to Ruby and Git versions do not apply to [Omnibus installations](https://docs.gitlab.com/omnibus/)
 and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with appropriate Ruby and Git versions and are not using system binaries for Ruby and Git. There is no need to install Ruby or Git when utilizing these two approaches.
 
+### 14.0.0
+
+In GitLab 13.3 some [pipeline processing methods were deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/218536)
+and this code was completely removed in GitLab 14.0. If you plan to upgrade from
+**GitLab 13.2 or older** directly to 14.0, you should not have any pipelines running
+when you upgrade. The pipelines might report the wrong status when the upgrade completes.
+You should shut down GitLab and wait for all pipelines on runners to complete, then upgrade
+GitLab to 14.0. Alternatively, you can first upgrade GitLab to a version between 13.3 and
+13.12, then upgrade to 14.0.
+
 ### 13.11.0
 
 Git 2.31.x and later is required. We recommend you use the