Add latest changes from gitlab-org/gitlab@master

changelogs/unreleased/35709-update-squash-commit-sha-only-on-successful-merge.yml

+---
+title: Update squash_commit_sha only on successful merge
+merge_request: 19688
+author:
+type: fixed

changelogs/unreleased/add-dead-jobs-to-api-sidekiq-metrics.yml

+---
+title: Add dead jobs to Sidekiq metrics API
+merge_request: 19350
+author: Marco Peterseil
+type: added

changelogs/unreleased/georgekoltsov-fix-group-export-descendants.yml

+---
+title: Fix sub group export to export direct children
+merge_request: 20172
+author:
+type: fixed

changelogs/unreleased/jej-group-saml-test-button-shows-response.yml

+---
+title: Users can verify SAML configuration and view SamlResponse XML
+merge_request: 18362
+author:
+type: added

db/migrate/20191115091425_create_vulnerability_issue_links.rb

+# frozen_string_literal: true
+
+class CreateVulnerabilityIssueLinks < ActiveRecord::Migration[5.2]
+  DOWNTIME = false
+
+  def change
+    create_table :vulnerability_issue_links do |t|
+      # index: false because idx_vulnerability_issue_links_on_vulnerability_id_and_issue_id refers the same column
+      t.references :vulnerability, null: false, index: false, foreign_key: { on_delete: :cascade }
+      # index: true is implied
+      t.references :issue, null: false, foreign_key: { on_delete: :cascade }
+      t.integer 'link_type', limit: 2, null: false, default: 1 # 'related'
+      t.index %i[vulnerability_id issue_id],
+              name: 'idx_vulnerability_issue_links_on_vulnerability_id_and_issue_id',
+              unique: true # only one link (and of only one type) is allowed
+      t.index %i[vulnerability_id link_type],
+              name: 'idx_vulnerability_issue_links_on_vulnerability_id_and_link_type',
+              where: 'link_type = 2',
+              unique: true # only one 'created' link per vulnerability is allowed
+      t.timestamps_with_timezone
+    end
+  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: 2019_11_14_173624) do
+ActiveRecord::Schema.define(version: 2019_11_15_091425) do
   # These are extensions that must be enabled in order to support this database
   enable_extension "pg_trgm"
@@ -4018,6 +4018,17 @@ ActiveRecord::Schema.define(version: 2019_11_14_173624) do
     t.index ["project_id", "fingerprint"], name: "index_vulnerability_identifiers_on_project_id_and_fingerprint", unique: true
   end
+  create_table "vulnerability_issue_links", force: :cascade do |t|
+    t.bigint "vulnerability_id", null: false
+    t.bigint "issue_id", null: false
+    t.integer "link_type", limit: 2, default: 1, null: false
+    t.datetime_with_timezone "created_at", null: false
+    t.datetime_with_timezone "updated_at", null: false
+    t.index ["issue_id"], name: "index_vulnerability_issue_links_on_issue_id"
+    t.index ["vulnerability_id", "issue_id"], name: "idx_vulnerability_issue_links_on_vulnerability_id_and_issue_id", unique: true
+    t.index ["vulnerability_id", "link_type"], name: "idx_vulnerability_issue_links_on_vulnerability_id_and_link_type", unique: true, where: "(link_type = 2)"
+  end
+
   create_table "vulnerability_occurrence_identifiers", force: :cascade do |t|
     t.datetime_with_timezone "created_at", null: false
     t.datetime_with_timezone "updated_at", null: false
@@ -4547,6 +4558,8 @@ ActiveRecord::Schema.define(version: 2019_11_14_173624) do
   add_foreign_key "vulnerability_feedback", "users", column: "author_id", on_delete: :cascade
   add_foreign_key "vulnerability_feedback", "users", column: "comment_author_id", name: "fk_94f7c8a81e", on_delete: :nullify
   add_foreign_key "vulnerability_identifiers", "projects", on_delete: :cascade
+  add_foreign_key "vulnerability_issue_links", "issues", on_delete: :cascade
+  add_foreign_key "vulnerability_issue_links", "vulnerabilities", on_delete: :cascade
   add_foreign_key "vulnerability_occurrence_identifiers", "vulnerability_identifiers", column: "identifier_id", on_delete: :cascade
   add_foreign_key "vulnerability_occurrence_identifiers", "vulnerability_occurrences", column: "occurrence_id", on_delete: :cascade
   add_foreign_key "vulnerability_occurrence_pipelines", "ci_pipelines", column: "pipeline_id", on_delete: :cascade

doc/api/sidekiq_metrics.md

@@ -92,7 +92,8 @@ Example response:
   "jobs": {
     "processed": 2,
     "failed": 0,
-    "enqueued": 0
+    "enqueued": 0,
+    "dead": 0
   }
 }
 ```
@@ -145,7 +146,8 @@ Example response:
   "jobs": {
     "processed": 2,
     "failed": 0,
-    "enqueued": 0
+    "enqueued": 0,
+    "dead": 0
   }
 }
 ```

doc/ci/yaml/README.md

@@ -1539,9 +1539,9 @@ cache:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/18986) in GitLab v12.5.
-If `cache:key:files` is added, the cache `key` will use the SHA of the most recent commit
-that changed either of the given files. If neither file was changed in any commits, the key will be `default`.
-A maximum of two files are allowed.
+If `cache:key:files` is added, one or two files must be defined with it. The cache `key`
+will be a SHA computed from the most recent commits (one or two) that changed the
+given files. If neither file was changed in any commits, the key will be `default`.
 ```yaml
 cache:
@@ -1559,8 +1559,8 @@ cache:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/18986) in GitLab v12.5.
 The `prefix` parameter adds extra functionality to `key:files` by allowing the key to
-be composed of the given `prefix` combined with the SHA of the most recent commit
-that changed either of the files. For example, adding a `prefix` of `rspec`, will
+be composed of the given `prefix` combined with the SHA computed for `cache:key:files`.
+For example, adding a `prefix` of `rspec`, will
 cause keys to look like: `rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5`. If neither
 file was changed in any commits, the prefix is added to `default`, so the key in the
 example would be `rspec-default`.

doc/development/policies.md

@@ -157,3 +157,18 @@ end
 ```
 will include all rules from `ProjectPolicy`. The delegated conditions will be evaluated with the correct delegated subject, and will be sorted along with the regular rules in the policy. Note that only the relevant rules for a particular ability will actually be considered.
+
+## Specifying Policy Class
+
+You can also override the Policy used for a given subject:
+
+```ruby
+class Foo
+
+  def self.declarative_policy_class
+    'SomeOtherPolicy'
+  end
+end
+```
+
+This will use & check permissions on the `SomeOtherPolicy` class rather than the usual calculated `FooPolicy` class.

doc/update/README.md

@@ -69,7 +69,13 @@ before continuing the upgrading procedure. While this won't require downtime
 between upgrading major/minor releases, allowing the background migrations to
 finish. The time necessary to complete these migrations can be reduced by
 increasing the number of Sidekiq workers that can process jobs in the
-`background_migration` queue.
+`background_migration` queue. To check the size of this queue,
+[start a Rails console session](https://docs.gitlab.com/omnibus/maintenance/#starting-a-rails-console-session)
+and run the command below:
+
+```ruby
+Sidekiq::Queue.new('background_migration').size
+```
 As a rule of thumb, any database smaller than 10 GB won't take too much time to
 upgrade; perhaps an hour at most per minor release. Larger databases however may

doc/user/incident_management/index.md

@@ -75,7 +75,7 @@ Learn how to embed [GitLab hosted metric charts](../project/integrations/prometh
 ### Grafana metrics
-Learn how to embed [Grafana hosted metric charts](../project/integrations/prometheus.md#embedding-live-grafana-charts).
+Learn how to embed [Grafana hosted metric charts](../project/integrations/prometheus.md#embedding-grafana-charts).
 ## Slack integration

doc/user/permissions.md

@@ -121,6 +121,7 @@ The following table depicts the various user permission levels in a project.
 | Manage GitLab Pages domains and certificates      |         |            |             | ✓        | ✓      |
 | Remove GitLab Pages                               |         |            |             | ✓        | ✓      |
 | Manage clusters                                   |         |            |             | ✓        | ✓      |
+| View Pods logs **(ULTIMATE)**                     |         |            |             | ✓        | ✓      |
 | Manage license policy **(ULTIMATE)**              |         |            |             | ✓        | ✓      |
 | Edit comments (posted by any user)                |         |            |             | ✓        | ✓      |
 | Manage Error Tracking                             |         |            |             | ✓        | ✓      |

doc/user/project/clusters/kubernetes_pod_logs.md

@@ -11,7 +11,31 @@ Everything you need to build, test, deploy, and run your app at scale.
 ## Overview
-[Kubernetes](https://kubernetes.io) pod logs can be viewed directly within GitLab. Logs can be displayed by clicking on a specific pod from [Deploy Boards](../deploy_boards.md):
+[Kubernetes](https://kubernetes.io) pod logs can be viewed directly within GitLab.
+
+![Pod logs](img/kubernetes_pod_logs_v12_5.png)
+
+## Requirements
+
+[Deploying to a Kubernetes environment](../deploy_boards.md#enabling-deploy-boards) is required in order to be able to use Pod Logs.
+
+## Usage
+
+To access pod logs, you must have the right [permissions](../../permissions.md#project-members-permissions).
+
+You can access them in two ways.
+
+### From the project sidebar
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/22011) in GitLab 12.5.
+
+Go to **Operations > Pod logs** on the sidebar menu.
+
+![Sidebar menu](img/sidebar_menu_pod_logs_v12_5.png)
+
+### From Deploy Boards
+
+Logs can be displayed by clicking on a specific pod from [Deploy Boards](../deploy_boards.md):
 1. Go to **Operations > Environments** and find the environment which contains the desired pod, like `production`.
 1. On the **Environments** page, you should see the status of the environment's pods with [Deploy Boards](../deploy_boards.md).
@@ -23,9 +47,3 @@ Everything you need to build, test, deploy, and run your app at scale.
    - [From GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/issues/5769), environments.
    Support for pods with multiple containers is coming [in a future release](https://gitlab.com/gitlab-org/gitlab/issues/6502).
-
-   ![Deploy Boards pod list](img/kubernetes_pod_logs_v12_4.png)
-
-## Requirements
-
-[Enabling Deploy Boards](../deploy_boards.md#enabling-deploy-boards) is required in order to be able to use Pod Logs.