Add latest changes from gitlab-org/gitlab@master

changelogs/unreleased/33101-add-deployments-api-updated-after-param.yml

+---
+title: Allow order_by updated_at in Deployments API
+merge_request: 19658
+author:
+type: added

db/migrate/20191105193652_add_index_on_deployments_updated_at.rb

+# frozen_string_literal: true
+
+class AddIndexOnDeploymentsUpdatedAt < ActiveRecord::Migration[5.2]
+  include Gitlab::Database::MigrationHelpers
+
+  DOWNTIME = false
+  INDEX_COLUMNS = [:project_id, :updated_at]
+
+  disable_ddl_transaction!
+
+  def up
+    add_concurrent_index(:deployments, INDEX_COLUMNS)
+  end
+
+  def down
+    remove_concurrent_index(:deployments, INDEX_COLUMNS)
+  end
+end

db/schema.rb

@@ -1307,6 +1307,7 @@ ActiveRecord::Schema.define(version: 2019_11_14_173624) do
     t.index ["project_id", "iid"], name: "index_deployments_on_project_id_and_iid", unique: true
     t.index ["project_id", "status", "created_at"], name: "index_deployments_on_project_id_and_status_and_created_at"
     t.index ["project_id", "status"], name: "index_deployments_on_project_id_and_status"
+    t.index ["project_id", "updated_at"], name: "index_deployments_on_project_id_and_updated_at"
   end
 
   create_table "description_versions", force: :cascade do |t|

doc/administration/high_availability/README.md

@@ -224,20 +224,20 @@ users are, how much automation you use, mirroring, and repo/change size.
   were discovered. For details, see the related issues list in
   [this issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/64335).
 
-| Service                       | Configuration           | GCP type       |
-| ------------------------------|-------------------------|----------------|
-| 3 GitLab Rails <br> - Puma workers on each node set to 90% of available CPUs with 16 threads | 32 vCPU, 28.8GB Memory | n1-highcpu-32 |
-| 3 PostgreSQL                  | 4 vCPU, 15GB Memory     | n1-standard-4  |
-| 1 PgBouncer                   | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
-| X Gitaly[^1] <br> - Gitaly Ruby workers on each node set to 20% of available CPUs | 16 vCPU, 60GB Memory   | n1-standard-16 |
-| 3 Redis Cache + Sentinel <br> - Cache maxmemory set to 90% of available memory | 4 vCPU, 15GB Memory | n1-standard-4 |
-| 3 Redis Persistent + Sentinel | 4 vCPU, 15GB Memory     | n1-standard-4  |
-| 4 Sidekiq                     | 4 vCPU, 15GB Memory     | n1-standard-4  |
-| 3 Consul                      | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
-| 1 NFS Server                  | 4 CPU, 3.6GB Memory     | n1-highcpu-4   |
-| X S3 Object Storage[^3]       | -                       | -              |
-| 1 Monitoring node             | 4 CPU, 3.6GB Memory     | n1-highcpu-4   |
-| 1 Load Balancing node[^2]     | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
+| Service                     | Nodes | Configuration         | GCP type      |
+| ----------------------------|-------|-----------------------|---------------|
+| GitLab Rails <br> - Puma workers on each node set to 90% of available CPUs with 16 threads | 3 | 32 vCPU, 28.8GB Memory | n1-highcpu-32 |
+| PostgreSQL                  | 3     | 4 vCPU, 15GB Memory   | n1-standard-4 |
+| PgBouncer                   | 1     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
+| Gitaly <br> - Gitaly Ruby workers on each node set to 20% of available CPUs | X[^1] . | 16 vCPU, 60GB Memory   | n1-standard-16 |
+| Redis Cache + Sentinel <br> - Cache maxmemory set to 90% of available memory | 3 | 4 vCPU, 15GB Memory | n1-standard-4 |
+| Redis Persistent + Sentinel | 3     | 4 vCPU, 15GB Memory   | n1-standard-4 |
+| Sidekiq                     | 4     | 4 vCPU, 15GB Memory   | n1-standard-4 |
+| Consul                      | 3     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
+| NFS Server[^4] .            | 1     | 4 CPU, 3.6GB Memory   | n1-highcpu-4  |
+| S3 Object Storage[^3] .     | -     | -                     | -             |
+| Monitoring node             | 1     | 4 CPU, 3.6GB Memory   | n1-highcpu-4  |
+| Load Balancing node[^2] .   | 1     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
 
 NOTE: **Note:** Memory values are given directly by GCP machine sizes. On different cloud
 vendors a best effort like for like can be used.
@@ -251,20 +251,20 @@ vendors a best effort like for like can be used.
   details, see the related issues list in
   [this issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/64335).
 
-| Service                       | Configuration           | GCP type       |
-| ------------------------------|-------------------------|----------------|
-| 7 GitLab Rails <br> - Puma workers on each node set to 90% of available CPUs with 16 threads | 32 vCPU, 28.8GB Memory | n1-highcpu-32 |
-| 3 PostgreSQL                  | 8 vCPU, 30GB Memory     | n1-standard-8  |
-| 1 PgBouncer                   | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
-| X Gitaly[^1] <br> - Gitaly Ruby workers on each node set to 20% of available CPUs | 32 vCPU, 120GB Memory   | n1-standard-32 |
-| 3 Redis Cache + Sentinel <br> - Cache maxmemory set to 90% of available memory | 4 vCPU, 15GB Memory | n1-standard-4 |
-| 3 Redis Persistent + Sentinel | 4 vCPU, 15GB Memory     | n1-standard-4  |
-| 4 Sidekiq                     | 4 vCPU, 15GB Memory     | n1-standard-4  |
-| 3 Consul                      | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
-| 1 NFS Server                  | 4 CPU, 3.6GB Memory     | n1-highcpu-4   |
-| X S3 Object Storage[^4]       | -                       | -              |
-| 1 Monitoring node             | 4 CPU, 3.6GB Memory     | n1-highcpu-4   |
-| 1 Load Balancing node[^2]     | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
+| Service                     | Nodes | Configuration         | GCP type      |
+| ----------------------------|-------|-----------------------|---------------|
+| GitLab Rails <br> - Puma workers on each node set to 90% of available CPUs with 16 threads | 7 | 32 vCPU, 28.8GB Memory | n1-highcpu-32 |
+| PostgreSQL                  | 3     | 8 vCPU, 30GB Memory   | n1-standard-8 |
+| PgBouncer                   | 1     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
+| Gitaly <br> - Gitaly Ruby workers on each node set to 20% of available CPUs | X[^1] . | 32 vCPU, 120GB Memory | n1-standard-32 |
+| Redis Cache + Sentinel <br> - Cache maxmemory set to 90% of available memory | 3 | 4 vCPU, 15GB Memory | n1-standard-4 |
+| Redis Persistent + Sentinel | 3     | 4 vCPU, 15GB Memory   | n1-standard-4 |
+| Sidekiq                     | 4     | 4 vCPU, 15GB Memory   | n1-standard-4 |
+| Consul                      | 3     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
+| NFS Server[^4] .            | 1     | 4 CPU, 3.6GB Memory   | n1-highcpu-4  |
+| S3 Object Storage[^3] .     | -     | -                     | -             |
+| Monitoring node             | 1     | 4 CPU, 3.6GB Memory   | n1-highcpu-4  |
+| Load Balancing node[^2] .   | 1     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
 
 NOTE: **Note:** Memory values are given directly by GCP machine sizes. On different cloud
 vendors a best effort like for like can be used.
@@ -280,20 +280,20 @@ NOTE: **Note:**  This architecture is a work-in-progress of the work so far. The
 Quality team will be certifying this environment in late 2019. The specifications
 may be adjusted prior to certification based on performance testing.
 
-| Service                       | Configuration           | GCP type       |
-| ------------------------------|-------------------------|----------------|
-| 15 GitLab Rails <br> - Puma workers on each node set to 90% of available CPUs with 16 threads | 32 vCPU, 28.8GB Memory | n1-highcpu-32 |
-| 3 PostgreSQL                  | 8 vCPU, 30GB Memory     | n1-standard-8  |
-| 1 PgBouncer                   | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
-| X Gitaly[^1] <br> - Gitaly Ruby workers on each node set to 20% of available CPUs | 64 vCPU, 240GB Memory   | n1-standard-64 |
-| 3 Redis Cache + Sentinel <br> - Cache maxmemory set to 90% of available memory | 4 vCPU, 15GB Memory | n1-standard-4 |
-| 3 Redis Persistent + Sentinel | 4 vCPU, 15GB Memory     | n1-standard-4  |
-| 4 Sidekiq                     | 4 vCPU, 15GB Memory     | n1-standard-4  |
-| 3 Consul                      | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
-| 1 NFS Server                  | 4 CPU, 3.6GB Memory     | n1-highcpu-4   |
-| X S3 Object Storage[^3]       | -                       | -              |
-| 1 Monitoring node             | 4 CPU, 3.6GB Memory     | n1-highcpu-4   |
-| 1 Load Balancing node[^2]     | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
+| Service                     | Nodes | Configuration         | GCP type      |
+| ----------------------------|-------|-----------------------|---------------|
+| GitLab Rails <br> - Puma workers on each node set to 90% of available CPUs with 16 threads | 15 | 32 vCPU, 28.8GB Memory | n1-highcpu-32 |
+| PostgreSQL                  | 3     | 8 vCPU, 30GB Memory   | n1-standard-8 |
+| PgBouncer                   | 1     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
+| Gitaly <br> - Gitaly Ruby workers on each node set to 20% of available CPUs | X[^1] . | 64 vCPU, 240GB Memory   | n1-standard-64 |
+| Redis Cache + Sentinel <br> - Cache maxmemory set to 90% of available memory | 3 | 4 vCPU, 15GB Memory | n1-standard-4 |
+| Redis Persistent + Sentinel | 3     | 4 vCPU, 15GB Memory   | n1-standard-4 |
+| Sidekiq                     | 4     | 4 vCPU, 15GB Memory   | n1-standard-4 |
+| Consul                      | 3     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
+| NFS Server[^4] .            | 1     | 4 CPU, 3.6GB Memory   | n1-highcpu-4  |
+| S3 Object Storage[^3] .     | -     | -                     | -             |
+| Monitoring node             | 1     | 4 CPU, 3.6GB Memory   | n1-highcpu-4  |
+| Load Balancing node[^2] .   | 1     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
 
 NOTE: **Note:** Memory values are given directly by GCP machine sizes. On different cloud
 vendors a best effort like for like can be used.

doc/api/deployments.md

@@ -11,7 +11,7 @@ GET /projects/:id/deployments
 | Attribute | Type    | Required | Description         |
 |-----------|---------|----------|---------------------|
 | `id`      | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
-| `order_by`| string  | no       | Return deployments ordered by `id` or `iid` or `created_at` or `ref` fields. Default is `id` |
+| `order_by`| string  | no       | Return deployments ordered by `id` or `iid` or `created_at` or `updated_at` or `ref` fields. Default is `id` |
 | `sort`    | string  | no       | Return deployments sorted in `asc` or `desc` order. Default is `asc` |
 
 ```bash

doc/development/gotchas.md

@@ -168,3 +168,73 @@ in an initializer._
 ### Further reading
 
 - Stack Overflow: [Why you should not write inline JavaScript](https://softwareengineering.stackexchange.com/questions/86589/why-should-i-avoid-inline-scripting)
+
+## Auto loading
+
+Rails auto-loading on `development` differs from the load policy in the `production` environment.
+In development mode, `config.eager_load` is set to `false`, which means classes
+are loaded as needed. With the classic Rails autoloader, it is known that this can lead to
+[Rails resolving the wrong class](https://guides.rubyonrails.org/v5.2/autoloading_and_reloading_constants.html#when-constants-aren-t-missed-relative-references)
+if the class name is ambiguous. This can be fixed by specifying the complete namespace to the class.
+
+### Error prone example
+
+```ruby
+# app/controllers/application_controller.rb
+class ApplicationController < ActionController::Base
+  ...
+end
+
+# app/controllers/projects/application_controller.rb
+class Projects::ApplicationController < ApplicationController
+  ...
+  private
+
+  def project
+    ...
+  end
+end
+
+# app/controllers/projects/submodule/some_controller.rb
+module Projects
+  module Submodule
+    class SomeController < ApplicationController
+      def index
+        @some_id = project.id
+      end
+    end
+  end
+end
+```
+
+In this case, if for any reason the top level `ApplicationController`
+is loaded but `Projects::ApplicationController` is not, `ApplicationController`
+would be resolved to `::ApplicationController` and then the `project` method will
+be undefined and we will get an error.
+
+#### Solution
+
+```ruby
+# app/controllers/projects/submodule/some_controller.rb
+module Projects
+  module Submodule
+    class SomeController < Projects::ApplicationController
+      def index
+        @some_id = project.id
+      end
+    end
+  end
+end
+```
+
+By specifying `Projects::`, we tell Rails exactly what class we are referring
+to and we would avoid the issue.
+
+NOTE: **Note:**
+This problem will disappear as soon as we upgrade to Rails 6 and use the Zeitwerk autoloader.
+
+### Further reading
+
+- Rails Guides: [Autoloading and Reloading Constants (Classic Mode)](https://guides.rubyonrails.org/autoloading_and_reloading_constants_classic_mode.html)
+- Ruby Constant lookup: [Everything you ever wanted to know about constant lookup in Ruby](http://cirw.in/blog/constant-lookup)
+- Rails 6 and Zeitwerk autoloader: [Understanding Zeitwerk in Rails 6](https://medium.com/cedarcode/understanding-zeitwerk-in-rails-6-f168a9f09a1f)

doc/user/project/issues/design_management.md

@@ -114,12 +114,16 @@ viewed by browsing previous versions.
 
 ## Adding annotations to designs
 
-When a design image is displayed, you can add annotations to it by clicking on
-the image. A badge is added to the image and a form is displayed to start a new
-discussion. For example:
+When a design is uploaded, you can add annotations by clicking on
+the image on the exact location you'd like to add the note to.
+A badge is added to the image identifying the annotation, from
+which you can start a new discussion:
 
 ![Starting a new discussion on design](img/adding_note_to_design_1.png)
 
-When submitted, the form saves a badge linked to the discussion on the image. Different discussions have different badge numbers. For example:
+Different discussions have different badge numbers:
 
 ![Discussions on design annotations](img/adding_note_to_design_2.png)
+
+From GitLab 12.5 on, new annotations will be outputted to the issue activity,
+so that everyone involved can participate in the discussion.

lib/api/deployments.rb

@@ -17,7 +17,7 @@ module API
       end
       params do
         use :pagination
-        optional :order_by, type: String, values: %w[id iid created_at ref], default: 'id', desc: 'Return deployments ordered by `id` or `iid` or `created_at` or `ref`'
+        optional :order_by, type: String, values: %w[id iid created_at updated_at ref], default: 'id', desc: 'Return deployments ordered by `id` or `iid` or `created_at` or `updated_at` or `ref`'
         optional :sort, type: String, values: %w[asc desc], default: 'asc', desc: 'Sort by asc (ascending) or desc (descending)'
       end
       # rubocop: disable CodeReuse/ActiveRecord

spec/requests/api/deployments_spec.rb

@@ -12,9 +12,9 @@ describe API::Deployments do
 
   describe 'GET /projects/:id/deployments' do
     let(:project) { create(:project) }
-    let!(:deployment_1) { create(:deployment, :success, project: project, iid: 11, ref: 'master', created_at: Time.now) }
-    let!(:deployment_2) { create(:deployment, :success, project: project, iid: 12, ref: 'feature', created_at: 1.day.ago) }
-    let!(:deployment_3) { create(:deployment, :success, project: project, iid: 8, ref: 'patch', created_at: 2.days.ago) }
+    let!(:deployment_1) { create(:deployment, :success, project: project, iid: 11, ref: 'master', created_at: Time.now, updated_at: Time.now) }
+    let!(:deployment_2) { create(:deployment, :success, project: project, iid: 12, ref: 'feature', created_at: 1.day.ago, updated_at: 2.hours.ago) }
+    let!(:deployment_3) { create(:deployment, :success, project: project, iid: 8, ref: 'patch', created_at: 2.days.ago, updated_at: 1.hour.ago) }
 
     context 'as member of the project' do
       it 'returns projects deployments sorted by id asc' do
@@ -57,6 +57,8 @@ describe API::Deployments do
           'iid'        | 'desc' | [:deployment_2, :deployment_1, :deployment_3]
           'ref'        | 'asc'  | [:deployment_2, :deployment_1, :deployment_3]
           'ref'        | 'desc' | [:deployment_3, :deployment_1, :deployment_2]
+          'updated_at' | 'asc'  | [:deployment_2, :deployment_3, :deployment_1]
+          'updated_at' | 'desc' | [:deployment_1, :deployment_3, :deployment_2]
         end
 
         with_them do