Add latest changes from gitlab-org/gitlab@master

changelogs/unreleased/rs-keep-divergent-refs-column.yml

+---
+title: Add keep_divergent_refs to remote_mirrors table
+merge_request:
+author:
+type: other

db/migrate/20200220180944_add_keep_divergent_refs.rb

+# frozen_string_literal: true
+
+class AddKeepDivergentRefs < ActiveRecord::Migration[6.0]
+  include Gitlab::Database::MigrationHelpers
+
+  DOWNTIME = false
+
+  def change
+    add_column :remote_mirrors, :keep_divergent_refs, :boolean
+  end
+end

db/schema.rb

@@ -10,7 +10,7 @@
 #
 # It's strongly recommended that you check this file into your version control system.
 
-ActiveRecord::Schema.define(version: 2020_02_14_034836) do
+ActiveRecord::Schema.define(version: 2020_02_20_180944) do
 
   # These are extensions that must be enabled in order to support this database
   enable_extension "pg_trgm"
@@ -3689,6 +3689,7 @@ ActiveRecord::Schema.define(version: 2020_02_14_034836) do
     t.boolean "only_protected_branches", default: false, null: false
     t.string "remote_name"
     t.boolean "error_notification_sent"
+    t.boolean "keep_divergent_refs"
     t.index ["last_successful_update_at"], name: "index_remote_mirrors_on_last_successful_update_at"
     t.index ["project_id"], name: "index_remote_mirrors_on_project_id"
   end

doc/development/sidekiq_style_guide.md

@@ -167,7 +167,7 @@ Most workers tend to spend most of their time blocked, wait on network responses
 from other services such as Redis, Postgres and Gitaly. Since Sidekiq is a
 multithreaded environment, these jobs can be scheduled with high concurrency.
 
-Some workers, however, spend large amounts of time _on-cpu_ running logic in
+Some workers, however, spend large amounts of time _on-CPU_ running logic in
 Ruby. Ruby MRI does not support true multithreading - it relies on the
 [GIL](https://thoughtbot.com/blog/untangling-ruby-threads#the-global-interpreter-lock)
 to greatly simplify application development by only allowing one section of Ruby
@@ -187,13 +187,17 @@ performance.
 Likewise, if a worker uses large amounts of memory, we can run these on a
 bespoke low concurrency, high memory fleet.
 
-Note that Memory-bound workers create heavy GC workloads, with pauses of
+Note that memory-bound workers create heavy GC workloads, with pauses of
 10-50ms. This will have an impact on the latency requirements for the
 worker. For this reason, `memory` bound, `latency_sensitive` jobs are not
 permitted and will fail CI. In general, `memory` bound workers are
 discouraged, and alternative approaches to processing the work should be
 considered.
 
+If a worker needs large amounts of both memory and CPU time, it should be marked as
+memory-bound, due to the above restrction on latency-sensitive memory-bound
+workers.
+
 ## Declaring a Job as CPU-bound
 
 This example shows how to declare a job as being CPU-bound.