Automatic merge of gitlab-org/gitlab master

app/assets/javascripts/vue_merge_request_widget/components/states/ready_to_merge.vue

@@ -557,6 +557,14 @@ export default {
               v-if="shouldShowMergeControls"
               class="gl-display-flex gl-align-items-center gl-flex-wrap"
             >
+              <merge-train-helper-icon
+                v-if="shouldRenderMergeTrainHelperIcon"
+                :merge-train-when-pipeline-succeeds-docs-path="
+                  mr.mergeTrainWhenPipelineSucceedsDocsPath
+                "
+                class="gl-mx-3"
+              />
+
               <gl-form-checkbox
                 v-if="canRemoveSourceBranch"
                 id="remove-source-branch-input"
@@ -575,13 +583,6 @@ export default {
                 :is-disabled="isSquashReadOnly"
                 class="gl-mx-3"
               />
-
-              <merge-train-helper-icon
-                v-if="shouldRenderMergeTrainHelperIcon"
-                :merge-train-when-pipeline-succeeds-docs-path="
-                  mr.mergeTrainWhenPipelineSucceedsDocsPath
-                "
-              />
             </div>
             <template v-else>
               <div class="bold js-resolve-mr-widget-items-message gl-ml-3">

doc/ci/pipelines/parent_child_pipelines.md

@@ -81,7 +81,8 @@ microservice_a:
   trigger:
     include:
       - project: 'my-group/my-pipeline-library'
-        file: 'path/to/ci-config.yml'
+        ref: 'main'
+        file: '/path/to/child-pipeline.yml'
 ```
 
 The maximum number of entries that are accepted for `trigger:include:` is three.
@@ -98,7 +99,7 @@ microservice_a:
     strategy: depend
 ```
 
-## Merge Request child pipelines
+## Merge request child pipelines
 
 To trigger a child pipeline as a [Merge Request Pipeline](merge_request_pipelines.md) we need to:
 
@@ -149,7 +150,7 @@ microservice_a:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35632) in GitLab 12.9.
 
 Instead of running a child pipeline from a static YAML file, you can define a job that runs
-your own script to generate a YAML file, which is then [used to trigger a child pipeline](../yaml/index.md#trigger-child-pipeline-with-generated-configuration-file).
+your own script to generate a YAML file, which is then used to trigger a child pipeline.
 
 This technique can be very powerful in generating pipelines targeting content that changed or to
 build a matrix of targets and architectures.
@@ -171,6 +172,31 @@ configuration for jobs, like scripts, that use the Windows runner would use `\`.
 In GitLab 12.9, the child pipeline could fail to be created in certain cases, causing the parent pipeline to fail.
 This is [resolved](https://gitlab.com/gitlab-org/gitlab/-/issues/209070) in GitLab 12.10.
 
+### Dynamic child pipeline example
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35632) in GitLab 12.9.
+
+You can trigger a child pipeline from a [dynamically generated configuration file](../pipelines/parent_child_pipelines.md#dynamic-child-pipelines):
+
+```yaml
+generate-config:
+  stage: build
+  script: generate-ci-config > generated-config.yml
+  artifacts:
+    paths:
+      - generated-config.yml
+
+child-pipeline:
+  stage: test
+  trigger:
+    include:
+      - artifact: generated-config.yml
+        job: generate-config
+```
+
+The `generated-config.yml` is extracted from the artifacts and used as the configuration
+for triggering the child pipeline.
+
 ## Nested child pipelines
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29651) in GitLab 13.4.

doc/ci/resource_groups/index.md

@@ -177,7 +177,7 @@ deploy:
 ```
 
 In a parent pipeline, it runs the `test` job that subsequently runs a child pipeline,
-and the [`strategy: depend` option](../yaml/index.md#linking-pipelines-with-triggerstrategy) makes the `test` job wait until the child pipeline has finished.
+and the [`strategy: depend` option](../yaml/index.md#triggerstrategy) makes the `test` job wait until the child pipeline has finished.
 The parent pipeline runs the `deploy` job in the next stage, that requires a resource from the `production` resource group.
 If the process mode is `oldest_first`, it executes the jobs from the oldest pipelines, meaning the `deploy` job is going to be executed next.
 

doc/ci/triggers/index.md

@@ -113,6 +113,9 @@ This means that whenever a new tag is pushed on project A, the job runs and the
 `stage: deploy` ensures that this job runs only after all jobs with
 `stage: test` complete successfully.
 
+NOTE:
+You [cannot use the API to start `when:manual` trigger jobs](https://gitlab.com/gitlab-org/gitlab/-/issues/284086).
+
 ## Triggering a pipeline from a webhook
 
 To trigger a job from a webhook of another project you need to add the following

doc/ci/yaml/index.md

@@ -3802,31 +3802,19 @@ deploystacks:
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/8997) in GitLab Premium 11.8.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
 
-Use `trigger` to define a downstream pipeline trigger. When GitLab starts a `trigger` job,
-a downstream pipeline is created.
+Use `trigger` to start a downstream pipeline that is either:
 
-Jobs with `trigger` can only use a [limited set of keywords](../pipelines/multi_project_pipelines.md#define-multi-project-pipelines-in-your-gitlab-ciyml-file).
-For example, you can't run commands with [`script`](#script), [`before_script`](#before_script),
-or [`after_script`](#after_script).
+- [A multi-project pipeline](../pipelines/multi_project_pipelines.md).
+- [A child pipeline](../pipelines/parent_child_pipelines.md).
 
-You can use this keyword to create two different types of downstream pipelines:
-
-- [Multi-project pipelines](../pipelines/multi_project_pipelines.md#define-multi-project-pipelines-in-your-gitlab-ciyml-file)
-- [Child pipelines](../pipelines/parent_child_pipelines.md)
-
-In [GitLab 13.2 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/197140/), you can
-view which job triggered a downstream pipeline. In the [pipeline graph](../pipelines/index.md#visualize-pipelines),
-hover over the downstream pipeline job.
+**Keyword type**: Job keyword. You can use it only as part of a job.
 
-In [GitLab 13.5 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/201938), you
-can use [`when:manual`](#when) in the same job as `trigger`. In GitLab 13.4 and
-earlier, using them together causes the error `jobs:#{job-name} when should be on_success, on_failure or always`.
-You [cannot start `manual` trigger jobs with the API](https://gitlab.com/gitlab-org/gitlab/-/issues/284086).
+**Possible inputs**: 
 
-#### Basic `trigger` syntax for multi-project pipelines
+- For multi-project pipelines, path to the downstream project.
+- For child pipelines, path to the child pipeline CI/CD configuration file.
 
-You can configure a downstream trigger by using the `trigger` keyword
-with a full path to a downstream project:
+**Example of `trigger` for multi-project pipeline**:
 
 ```yaml
 rspec:
@@ -3838,47 +3826,7 @@ staging:
   trigger: my/deployment
 ```
 
-#### Complex `trigger` syntax for multi-project pipelines
-
-You can configure a branch name that GitLab uses to create
-a downstream pipeline with:
-
-```yaml
-rspec:
-  stage: test
-  script: bundle exec rspec
-
-staging:
-  stage: deploy
-  trigger:
-    project: my/deployment
-    branch: stable
-```
-
-To mirror the status from a triggered pipeline:
-
-```yaml
-trigger_job:
-  trigger:
-    project: my/project
-    strategy: depend
-```
-
-To mirror the status from an upstream pipeline:
-
-```yaml
-upstream_bridge:
-  stage: test
-  needs:
-    pipeline: other/project
-```
-
-#### `trigger` syntax for child pipeline
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/16094) in GitLab 12.7.
-
-To create a [child pipeline](../pipelines/parent_child_pipelines.md), specify the path to the
-YAML file that contains the configuration of the child pipeline:
+**Example of `trigger` for child pipelines**:
 
 ```yaml
 trigger_job:
@@ -3886,71 +3834,36 @@ trigger_job:
     include: path/to/child-pipeline.yml
 ```
 
-Similar to [multi-project pipelines](../pipelines/multi_project_pipelines.md#mirror-status-of-a-triggered-pipeline-in-the-trigger-job),
-it's possible to mirror the status from a triggered pipeline:
-
-```yaml
-trigger_job:
-  trigger:
-    include:
-      - local: path/to/child-pipeline.yml
-    strategy: depend
-```
-
-##### Trigger child pipeline with generated configuration file
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35632) in GitLab 12.9.
-
-You can also trigger a child pipeline from a [dynamically generated configuration file](../pipelines/parent_child_pipelines.md#dynamic-child-pipelines):
-
-```yaml
-generate-config:
-  stage: build
-  script: generate-ci-config > generated-config.yml
-  artifacts:
-    paths:
-      - generated-config.yml
-
-child-pipeline:
-  stage: test
-  trigger:
-    include:
-      - artifact: generated-config.yml
-        job: generate-config
-```
+**Additional details**:
 
-The `generated-config.yml` is extracted from the artifacts and used as the configuration
-for triggering the child pipeline.
+- Jobs with `trigger` can only use a [limited set of keywords](../pipelines/multi_project_pipelines.md#define-multi-project-pipelines-in-your-gitlab-ciyml-file).
+  For example, you can't run commands with [`script`](#script), [`before_script`](#before_script),
+  or [`after_script`](#after_script).
+- In [GitLab 13.5 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/201938), you
+  can use [`when:manual`](#when) in the same job as `trigger`. In GitLab 13.4 and
+  earlier, using them together causes the error `jobs:#{job-name} when should be on_success, on_failure or always`.
+- In [GitLab 13.2 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/197140/), you can
+  view which job triggered a downstream pipeline in the [pipeline graph](../pipelines/index.md#visualize-pipelines).
 
-##### Trigger child pipeline with files from another project
+**Related topics**:
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/205157) in GitLab 13.5.
+- [Multi-project pipeline configuration examples](../pipelines/multi_project_pipelines.md#define-multi-project-pipelines-in-your-gitlab-ciyml-file).
+- [Child pipeline configuration examples](../pipelines/parent_child_pipelines.md#examples).
+- To force a rebuild of a specific branch, tag, or commit, you can
+  [use an API call with a trigger token](../triggers/index.md).
+  The trigger token is different than the `trigger` keyword.
 
-To trigger child pipelines with files from another private project under the same
-GitLab instance, use [`include:file`](#includefile):
+#### `trigger:strategy`
 
-```yaml
-child-pipeline:
-  trigger:
-    include:
-      - project: 'my-group/my-pipeline-library'
-        ref: 'main'
-        file: '/path/to/child-pipeline.yml'
-```
-
-#### Linking pipelines with `trigger:strategy`
+Use `trigger:strategy` to force the `trigger` job to wait for the downstream pipeline to complete
+before it is marked as **success**.
 
-By default, the `trigger` job completes with the `success` status
-as soon as the downstream pipeline is created.
+This behavior is different than the default, which is for the `trigger` job to be marked as
+**success** as soon as the downstream pipeline is created.
 
-To force the `trigger` job to wait for the downstream (multi-project or child) pipeline to complete, use
-`strategy: depend`. This setting makes the trigger job wait with a "running" status until the triggered
-pipeline completes. At that point, the `trigger` job completes and displays the same status as
-the downstream job.
+This setting makes your pipeline execution linear rather than parallel.
 
-This setting can help keep your pipeline execution linear. In the following example, jobs from
-subsequent stages wait for the triggered pipeline to successfully complete before
-starting, which reduces parallelization.
+**Example of `trigger:strategy`**:
 
 ```yaml
 trigger_job:
@@ -3959,14 +3872,8 @@ trigger_job:
     strategy: depend
 ```
 
-#### Trigger a pipeline by API call
-
-To force a rebuild of a specific branch, tag, or commit, you can use an API call
-with a trigger token.
-
-The trigger token is different than the [`trigger`](#trigger) keyword.
-
-[Read more in the triggers documentation.](../triggers/index.md)
+In this example, jobs from subsequent stages wait for the triggered pipeline to
+successfully complete before starting. 
 
 ### `interruptible`
 
@@ -4109,7 +4016,7 @@ deployment:
   script: echo "Deploying..."
 ```
 
-You must define [`strategy: depend`](#linking-pipelines-with-triggerstrategy)
+You must define [`strategy: depend`](#triggerstrategy)
 with the `trigger` keyword. This ensures that the lock isn't released until the downstream pipeline
 finishes.
 

doc/development/testing_guide/testing_migrations_guide.md

@@ -234,53 +234,64 @@ Migration tests depend on what the migration does exactly, the most common types
 #### Example of a data migration test
 
 This spec tests the
-[`db/post_migrate/20170526185842_migrate_pipeline_stages.rb`](https://gitlab.com/gitlab-org/gitlab-foss/blob/v11.6.5/db/post_migrate/20170526185842_migrate_pipeline_stages.rb)
+[`db/post_migrate/20200723040950_migrate_incident_issues_to_incident_type.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/post_migrate/20200723040950_migrate_incident_issues_to_incident_type.rb)
 migration. You can find the complete spec in
-[`spec/migrations/migrate_pipeline_stages_spec.rb`](https://gitlab.com/gitlab-org/gitlab-foss/blob/v11.6.5/spec/migrations/migrate_pipeline_stages_spec.rb).
+[`spec/migrations/migrate_incident_issues_to_incident_type_spec.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/migrations/migrate_incident_issues_to_incident_type_spec.rb).
 
 ```ruby
-require 'spec_helper'
+# frozen_string_literal: true
 
+require 'spec_helper'
 require_migration!
 
-RSpec.describe MigratePipelineStages do
-  # Create test data - pipeline and CI/CD jobs.
-  let(:jobs) { table(:ci_builds) }
-  let(:stages) { table(:ci_stages) }
-  let(:pipelines) { table(:ci_pipelines) }
+RSpec.describe MigrateIncidentIssuesToIncidentType do
+  let(:migration) { described_class.new }
+
   let(:projects) { table(:projects) }
+  let(:namespaces) { table(:namespaces) }
+  let(:labels) { table(:labels) }
+  let(:issues) { table(:issues) }
+  let(:label_links) { table(:label_links) }
+  let(:label_props) { IncidentManagement::CreateIncidentLabelService::LABEL_PROPERTIES }
+
+  let(:namespace) { namespaces.create!(name: 'foo', path: 'foo') }
+  let!(:project) { projects.create!(namespace_id: namespace.id) }
+  let(:label) { labels.create!(project_id: project.id, **label_props) }
+  let!(:incident_issue) { issues.create!(project_id: project.id) }
+  let!(:other_issue) { issues.create!(project_id: project.id) }
+
+  # Issue issue_type enum
+  let(:issue_type) { 0 }
+  let(:incident_type) { 1 }
 
   before do
-    projects.create!(id: 123, name: 'gitlab1', path: 'gitlab1')
-    pipelines.create!(id: 1, project_id: 123, ref: 'master', sha: 'adf43c3a')
-    jobs.create!(id: 1, commit_id: 1, project_id: 123, stage_idx: 2, stage: 'build')
-    jobs.create!(id: 2, commit_id: 1, project_id: 123, stage_idx: 1, stage: 'test')
+    label_links.create!(target_id: incident_issue.id, label_id: label.id, target_type: 'Issue')
   end
 
-  # Test just the up migration.
-  it 'correctly migrates pipeline stages' do
-    expect(stages.count).to be_zero
-
-    migrate!
+  describe '#up' do
+    it 'updates the incident issue type' do
+      expect { migrate! }
+        .to change { incident_issue.reload.issue_type }
+        .from(issue_type)
+        .to(incident_type)
 
-    expect(stages.count).to eq 2
-    expect(stages.all.pluck(:name)).to match_array %w[test build]
+      expect(other_issue.reload.issue_type).to eql(issue_type)
+    end
   end
 
-  # Test a reversible migration.
-  it 'correctly migrates up and down pipeline stages' do
-    reversible_migration do |migration|
-      # Expectations will run before the up migration,
-      # and then again after the down migration
-      migration.before -> {
-        expect(stages.count).to be_zero
-      }
+  describe '#down' do
+    let!(:incident_issue) { issues.create!(project_id: project.id, issue_type: issue_type) }
 
-      # Expectations will run after the up migration.
-      migration.after -> {
-        expect(stages.count).to eq 2
-        expect(stages.all.pluck(:name)).to match_array %w[test build]
-      }
+    it 'updates the incident issue type' do
+      migration.up
+
+      expect { migration.down }
+        .to change { incident_issue.reload.issue_type }
+        .from(incident_type)
+        .to(issue_type)
+
+      expect(other_issue.reload.issue_type).to eql(issue_type)
+    end
   end
 end
 ```
@@ -357,41 +368,62 @@ end
 ### Example background migration test
 
 This spec tests the
-[`lib/gitlab/background_migration/archive_legacy_traces.rb`](https://gitlab.com/gitlab-org/gitlab-foss/blob/v11.6.5/lib/gitlab/background_migration/archive_legacy_traces.rb)
+[`lib/gitlab/background_migration/backfill_draft_status_on_merge_requests.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/background_migration/backfill_draft_status_on_merge_requests.rb)
 background migration. You can find the complete spec on
-[`spec/lib/gitlab/background_migration/archive_legacy_traces_spec.rb`](https://gitlab.com/gitlab-org/gitlab-foss/blob/v11.6.5/spec/lib/gitlab/background_migration/archive_legacy_traces_spec.rb)
+[`spec/lib/gitlab/background_migration/backfill_draft_status_on_merge_requests_spec.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/lib/gitlab/background_migration/backfill_draft_status_on_merge_requests_spec.rb)
 
 ```ruby
-require 'spec_helper'
+# frozen_string_literal: true
 
-describe Gitlab::BackgroundMigration::ArchiveLegacyTraces, schema: 20180529152628 do
-  include TraceHelpers
+require 'spec_helper'
 
+RSpec.describe Gitlab::BackgroundMigration::BackfillDraftStatusOnMergeRequests do
   let(:namespaces)     { table(:namespaces) }
   let(:projects)       { table(:projects) }
-  let(:builds) { table(:ci_builds) }
-  let(:job_artifacts) { table(:ci_job_artifacts) }
+  let(:merge_requests) { table(:merge_requests) }
 
-  before do
-    namespaces.create!(id: 123, name: 'gitlab1', path: 'gitlab1')
-    projects.create!(id: 123, name: 'gitlab1', path: 'gitlab1', namespace_id: 123)
-    @build = builds.create!(id: 1, project_id: 123, status: 'success', type: 'Ci::Build')
+  let(:group)   { namespaces.create!(name: 'gitlab', path: 'gitlab') }
+  let(:project) { projects.create!(namespace_id: group.id) }
+
+  let(:draft_prefixes) { ["[Draft]", "(Draft)", "Draft:", "Draft", "[WIP]", "WIP:", "WIP"] }
+
+  def create_merge_request(params)
+    common_params = {
+      target_project_id: project.id,
+      target_branch: 'feature1',
+      source_branch: 'master'
+    }
+
+    merge_requests.create!(common_params.merge(params))
   end
 
-  context 'when trace file exists at the right place' do
+  context "for MRs with #draft? == true titles but draft attribute false" do
+    let(:mr_ids) { merge_requests.all.collect(&:id) }
+
     before do
-      create_legacy_trace(@build, 'trace in file')
+      draft_prefixes.each do |prefix|
+        (1..4).each do |n|
+          create_merge_request(
+            title: "#{prefix} This is a title",
+            draft: false,
+            state_id: n
+          )
+        end
+      end
     end
 
-    it 'correctly archive legacy traces' do
-      expect(job_artifacts.count).to eq(0)
-      expect(File.exist?(legacy_trace_path(@build))).to be_truthy
+    it "updates all open draft merge request's draft field to true" do
+      mr_count = merge_requests.all.count
+
+      expect { subject.perform(mr_ids.first, mr_ids.last) }
+        .to change { MergeRequest.where(draft: false).count }
+              .from(mr_count).to(mr_count - draft_prefixes.length)
+    end
 
-      described_class.new.perform(1, 1)
+    it "marks successful slices as completed" do
+      expect(subject).to receive(:mark_job_as_succeeded).with(mr_ids.first, mr_ids.last)
 
-      expect(job_artifacts.count).to eq(1)
-      expect(File.exist?(legacy_trace_path(@build))).to be_falsy
-      expect(File.read(archived_trace_path(job_artifacts.first))).to eq('trace in file')
+      subject.perform(mr_ids.first, mr_ids.last)
     end
   end
 end