Add latest changes from gitlab-org/gitlab@master

app/views/projects/triggers/edit.html.haml

 - page_title "Trigger"
 .row.prepend-top-default.append-bottom-default
-  .col-lg-3
-    = render "content"
-  .col-lg-9
+  .col-lg-12
     %h4.prepend-top-0
       Update trigger
     = render "form", btn_text: "Save trigger"

changelogs/unreleased/14857-activate-promethus-integration-for-projects.yml

----
-title: Migrate the database to activate projects prometheus service integration for projects with prometheus installed on shared k8s cluster.
-merge_request: 19956
-author:
-type: fixed

changelogs/unreleased/29772-completely-removing-use_legacy_pipeline_triggers.yml

+---
+title: Remove feature flag 'use_legacy_pipeline_triggers' and remove legacy tokens
+merge_request: 21732
+author:
+type: removed

changelogs/unreleased/34867-epics_to_project_import_export.yml

+---
+title: Add epics to project import/export
+merge_request: 19883
+author:
+type: added

changelogs/unreleased/39979-grapql-for-error-details.yml

+---
+title: Use GraphQL to load error tracking detail page content
+merge_request: 22422
+author:
+type: performance

changelogs/unreleased/enable-parent-child-pipelines.yml

+---
+title: Allow a pipeline (parent) to create a child pipeline as downstream pipeline within the same project
+merge_request: 21830
+author:
+type: added

changelogs/unreleased/feature-split-diff-attempt-3.yml

+---
+title: Load MR diff types lazily to reduce initial diff payload size
+merge_request: 19930
+author:
+type: added

changelogs/unreleased/refactor-session-disable-with-post.yml

+---
+title: User signout and admin mode disable use now POST instead of GET
+merge_request: 22113
+author: Diego Louzán
+type: other

config/initializers/8_devise.rb

@@ -203,7 +203,7 @@ Devise.setup do |config|
   config.navigational_formats = [:"*/*", "*/*", :html, :zip]
   # The default HTTP method used to sign out a resource. Default is :delete.
-  config.sign_out_via = :get
+  config.sign_out_via = :post
   # ==> OmniAuth
   # To configure a new OmniAuth provider copy and edit omniauth.rb.sample

config/routes/admin.rb

@@ -24,7 +24,7 @@ namespace :admin do
   end
   resource :session, only: [:new, :create] do
-    get 'destroy', action: :destroy, as: :destroy
+    post 'destroy', action: :destroy, as: :destroy
   end
   resource :impersonation, only: :destroy

db/post_migrate/20191204114127_delete_legacy_triggers.rb

+# frozen_string_literal: true
+
+class DeleteLegacyTriggers < ActiveRecord::Migration[5.2]
+  DOWNTIME = false
+
+  def up
+    execute <<~SQL
+      DELETE FROM ci_triggers WHERE owner_id IS NULL
+    SQL
+
+    change_column_null :ci_triggers, :owner_id, false
+  end
+
+  def down
+    change_column_null :ci_triggers, :owner_id, true
+  end
+end

db/post_migrate/20191220102807_patch_prometheus_services_for_shared_cluster_applications.rb

-# frozen_string_literal: true
-
-class PatchPrometheusServicesForSharedClusterApplications < ActiveRecord::Migration[5.2]
-  include Gitlab::Database::MigrationHelpers
-
-  DOWNTIME = false
-  MIGRATION = 'ActivatePrometheusServicesForSharedClusterApplications'.freeze
-  BATCH_SIZE = 500
-  DELAY = 2.minutes
-
-  disable_ddl_transaction!
-
-  module Migratable
-    module Applications
-      class Prometheus < ActiveRecord::Base
-        self.table_name = 'clusters_applications_prometheus'
-
-        enum status: {
-          errored: -1,
-          installed: 3,
-          updated: 5
-        }
-      end
-    end
-
-    class Project < ActiveRecord::Base
-      self.table_name = 'projects'
-      include ::EachBatch
-
-      scope :with_application_on_group_clusters, -> {
-        joins("INNER JOIN namespaces ON namespaces.id = projects.namespace_id")
-          .joins("INNER JOIN cluster_groups ON cluster_groups.group_id = namespaces.id")
-          .joins("INNER JOIN clusters ON clusters.id = cluster_groups.cluster_id AND clusters.cluster_type = #{Cluster.cluster_types['group_type']}")
-          .joins("INNER JOIN clusters_applications_prometheus ON clusters_applications_prometheus.cluster_id = clusters.id
-                      AND clusters_applications_prometheus.status IN (#{Applications::Prometheus.statuses[:installed]}, #{Applications::Prometheus.statuses[:updated]})")
-      }
-
-      scope :without_active_prometheus_services, -> {
-        joins("LEFT JOIN services ON services.project_id = projects.id AND services.type = 'PrometheusService'")
-          .where("services.id IS NULL OR (services.active = FALSE AND services.properties = '{}')")
-      }
-    end
-
-    class Cluster < ActiveRecord::Base
-      self.table_name = 'clusters'
-
-      enum cluster_type: {
-        instance_type: 1,
-        group_type: 2
-      }
-
-      def self.has_prometheus_application?
-        joins("INNER JOIN clusters_applications_prometheus ON clusters_applications_prometheus.cluster_id = clusters.id
-                   AND clusters_applications_prometheus.status IN (#{Applications::Prometheus.statuses[:installed]}, #{Applications::Prometheus.statuses[:updated]})").exists?
-      end
-    end
-  end
-
-  def up
-    projects_without_active_prometheus_service.group('projects.id').each_batch(of: BATCH_SIZE) do |batch, index|
-      bg_migrations_batch = batch.select('projects.id').map { |project| [MIGRATION, project.id] }
-      delay = index * DELAY
-      BackgroundMigrationWorker.bulk_perform_in(delay.seconds, bg_migrations_batch)
-    end
-  end
-
-  def down
-    # no-op
-  end
-
-  private
-
-  def projects_without_active_prometheus_service
-    scope = Migratable::Project.without_active_prometheus_services
-
-    return scope if migrate_instance_cluster?
-
-    scope.with_application_on_group_clusters
-  end
-
-  def migrate_instance_cluster?
-    if instance_variable_defined?('@migrate_instance_cluster')
-      @migrate_instance_cluster
-    else
-      @migrate_instance_cluster = Migratable::Cluster.instance_type.has_prometheus_application?
-    end
-  end
-end

db/schema.rb

@@ -994,7 +994,7 @@ ActiveRecord::Schema.define(version: 2020_01_08_233040) do
     t.datetime "created_at"
     t.datetime "updated_at"
     t.integer "project_id"
-    t.integer "owner_id"
+    t.integer "owner_id", null: false
     t.string "description"
     t.string "ref"
     t.index ["owner_id"], name: "index_ci_triggers_on_owner_id"

doc/ci/parent_child_pipelines.md

+---
+type: reference
+---
+
+# Parent-child pipelines
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/16094) in GitLab Starter 12.7.
+
+As pipelines grow more complex, a few related problems start to emerge:
+
+- The staged structure, where all steps in a stage must be completed before the first
+  job in next stage begins, causes arbitrary waits, slowing things down.
+- Configuration for the single global pipeline becomes very long and complicated,
+  making it hard to manage.
+- Imports with [`include`](yaml/README.md#include) increase the complexity of the configuration, and create the potential
+  for namespace collisions where jobs are unintentionally duplicated.
+- Pipeline UX can become unwieldy with so many jobs and stages to work with.
+
+Additionally, sometimes the behavior of a pipeline needs to be more dynamic. The ability
+to choose to start sub-pipelines (or not) is a powerful ability, especially if the
+YAML is dynamically generated.
+
+![Parent pipeline graph expanded](img/parent_pipeline_graph_expanded_v12_6.png)
+
+Similarly to [multi-project pipelines](multi_project_pipelines.md), a pipeline can trigger a
+set of concurrently running child pipelines, but within the same project:
+
+- Child pipelines still execute each of their jobs according to a stage sequence, but
+  would be free to continue forward through their stages without waiting for unrelated
+  jobs in the parent pipeline to finish.
+- The configuration is split up into smaller child pipeline configurations, which are
+  easier to understand. This reduces the cognitive load to understand the overall configuration.
+- Imports are done at the child pipeline level, reducing the likelihood of collisions.
+- Each pipeline has only the steps relevant steps, making it easier to understand what's going on.
+
+Child pipelines work well with other GitLab CI features:
+
+- Use [`only: changes`](yaml/README.md#onlychangesexceptchanges) to trigger pipelines only when
+  certain files change. This is useful for monorepos, for example.
+- Since the parent pipeline in `.gitlab-ci.yml` and the child pipeline run as normal
+  pipelines, they can have their own behaviors and sequencing in relation to triggers.
+
+All of this will work with [`include:`](yaml/README.md#include) feature so you can compose
+the child pipeline configuration.
+
+## Examples
+
+The simplest case is [triggering a child pipeline](yaml/README.md#trigger-premium) using a
+local YAML file to define the pipeline configuration. In this case, the parent pipeline will
+trigger the child pipeline, and continue without waiting:
+
+```yaml
+microservice_a:
+  trigger:
+    include: path/to/microservice_a.yml
+```
+
+You can include multiple files when composing a child pipeline:
+
+```yaml
+microservice_a:
+  trigger:
+    include:
+      - local: path/to/microservice_a.yml
+      - template: SAST.gitlab-ci.yml
+```
+
+NOTE: **Note:**
+The max number of entries that are accepted for `trigger:include:` is three.
+
+Similar to [multi-project pipelines](multi_project_pipelines.md#mirroring-status-from-triggered-pipeline),
+we can set the parent pipeline to depend on the status of the child pipeline upon completion:
+
+```yaml
+microservice_a:
+  trigger:
+    include:
+      - local: path/to/microservice_a.yml
+      - template: SAST.gitlab-ci.yml
+    strategy: depend
+```
+
+## Limitations
+
+A parent pipeline can trigger many child pipelines, but a child pipeline cannot trigger
+further child pipelines. See the [related issue](https://gitlab.com/gitlab-org/gitlab/issues/29651) for discussion on possible future improvements.

doc/ci/pipelines.md

@@ -246,6 +246,13 @@ Pipelines for different projects can be combined and visualized together.
 For more information, see [Multi-project pipelines](multi_project_pipelines.md).
+## Parent-child pipelines
+
+Complex pipelines can be broken down into one parent pipeline that can trigger
+multiple child sub-pipelines, which all run in the same project and with the same SHA.
+
+For more information, see [Parent-Child pipelines](parent_child_pipelines.md).
+
 ## Working with pipelines
 In general, pipelines are executed automatically and require no intervention once created.

doc/ci/yaml/README.md

@@ -2600,14 +2600,17 @@ job split into three separate jobs.
 from `trigger` definition is started by GitLab, a downstream pipeline gets
 created.
-Learn more about [multi-project pipelines](../multi_project_pipelines.md#creating-multi-project-pipelines-from-gitlab-ciyml).
+This keyword allows the creation of two different types of downstream pipelines:
+
+- [Multi-project pipelines](../multi_project_pipelines.md#creating-multi-project-pipelines-from-gitlab-ciyml)
+- [Child pipelines](../parent_child_pipelines.md)
 NOTE: **Note:**
 Using a `trigger` with `when:manual` together results in the error `jobs:#{job-name}
 when should be on_success, on_failure or always`, because `when:manual` prevents
 triggers being used.
-#### Simple `trigger` syntax
+#### Simple `trigger` syntax for multi-project pipelines
 The simplest way to configure a downstream trigger is to use `trigger` keyword
 with a full path to a downstream project:
@@ -2622,7 +2625,7 @@ staging:
   trigger: my/deployment
 ```
-#### Complex `trigger` syntax
+#### Complex `trigger` syntax for multi-project pipelines
 It is possible to configure a branch name that GitLab will use to create
 a downstream pipeline with:
@@ -2657,6 +2660,28 @@ upstream_bridge:
     pipeline: other/project
 ```
+#### `trigger` syntax for child pipeline
+
+To create a [child pipeline](../parent_child_pipelines.md), specify the path to the
+YAML file containing the CI config of the child pipeline:
+
+```yaml
+trigger_job:
+  trigger:
+    include: path/to/child-pipeline.yml
+```
+
+Similar to [multi-project pipelines](../multi_project_pipelines.md#mirroring-status-from-triggered-pipeline),
+it is possible to mirror the status from a triggered pipeline:
+
+```yaml
+trigger_job:
+  trigger:
+    include:
+      - local: path/to/child-pipeline.yml
+    strategy: depend
+```
+
 ### `interruptible`
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/23464) in GitLab 12.3.

lib/gitlab/background_migration/activate_prometheus_services_for_shared_cluster_applications.rb

-# frozen_string_literal: true
-
-module Gitlab
-  module BackgroundMigration
-    # Create missing PrometheusServices records or sets active attribute to true
-    # for all projects which belongs to cluster with Prometheus Application installed.
-    class ActivatePrometheusServicesForSharedClusterApplications
-      module Migratable
-        # Migration model namespace isolated from application code.
-        class PrometheusService < ActiveRecord::Base
-          self.inheritance_column = :_type_disabled
-          self.table_name = 'services'
-
-          default_scope { where("services.type = 'PrometheusService'") }
-
-          def self.for_project(project_id)
-            new(
-              project_id: project_id,
-              active: true,
-              properties: '{}',
-              type: 'PrometheusService',
-              template: false,
-              push_events: true,
-              issues_events: true,
-              merge_requests_events: true,
-              tag_push_events: true,
-              note_events: true,
-              category: 'monitoring',
-              default: false,
-              wiki_page_events: true,
-              pipeline_events: true,
-              confidential_issues_events: true,
-              commit_events: true,
-              job_events: true,
-              confidential_note_events: true,
-              deployment_events: false
-            )
-          end
-
-          def managed?
-            properties == '{}'
-          end
-        end
-      end
-
-      def perform(project_id)
-        service = Migratable::PrometheusService.find_by(project_id: project_id) || Migratable::PrometheusService.for_project(project_id)
-        service.update!(active: true) if service.managed?
-      end
-    end
-  end
-end

lib/gitlab/ci/pipeline/chain/command.rb

@@ -22,12 +22,6 @@ module Gitlab
             end
           end
-          def uses_unsupported_legacy_trigger?
-            trigger_request.present? &&
-              trigger_request.trigger.legacy? &&
-              !trigger_request.trigger.supports_legacy_tokens?
-          end
-
           def branch_exists?
             strong_memoize(:is_branch) do
               project.repository.branch_exists?(ref)

lib/gitlab/ci/pipeline/chain/validate/abilities.rb

@@ -14,16 +14,12 @@ module Gitlab
                 return error('Pipelines are disabled!')
               end
-              if @command.uses_unsupported_legacy_trigger?
-                return error('Trigger token is invalid because is not owned by any user')
+              unless allowed_to_create_pipeline?
+                return error('Insufficient permissions to create a new pipeline')
               end
-              unless allowed_to_trigger_pipeline?
-                if can?(current_user, :create_pipeline, project)
-                  return error("Insufficient permissions for protected ref '#{command.ref}'")
-                else
-                  return error('Insufficient permissions to create a new pipeline')
-                end
+              unless allowed_to_write_ref?
+                return error("Insufficient permissions for protected ref '#{command.ref}'")
               end
             end
@@ -31,17 +27,13 @@ module Gitlab
               @pipeline.errors.any?
             end
-            def allowed_to_trigger_pipeline?
-              if current_user
-                allowed_to_create?
-              else # legacy triggers don't have a corresponding user
-                !@command.protected_ref?
-              end
-            end
-            def allowed_to_create?
-              return unless can?(current_user, :create_pipeline, project)
+            private
+            def allowed_to_create_pipeline?
+              can?(current_user, :create_pipeline, project)
+            end
+            def allowed_to_write_ref?
               access = Gitlab::UserAccess.new(current_user, project: project)
               if @command.branch_exists?