Add latest changes from gitlab-org/gitlab@master

.markdownlint.json

@@ -124,6 +124,5 @@
       "YouTrack"
     ],
     "code_blocks": false
-  },
-  "code-fence-style": false
+  }
 }

app/assets/javascripts/ide/components/commit_sidebar/actions.vue

@@ -36,7 +36,9 @@ export default {
     },
   },
   mounted() {
-    this.updateSelectedCommitAction();
+    if (!this.commitAction) {
+      this.updateSelectedCommitAction();
+    }
   },
   methods: {
     ...mapCommitActions(['updateCommitAction']),

app/assets/javascripts/ide/stores/modules/commit/state.js

 export default () => ({
   commitMessage: '',
-  commitAction: '1',
+  commitAction: null,
   newBranchName: '',
   submitCommitLoading: false,
   shouldCreateMR: true,

doc/ci/merge_request_pipelines/index.md

@@ -23,11 +23,82 @@ A few notes:
 - Pipelines for merge requests are incompatible with
   [CI/CD for external repositories](../ci_cd_for_external_repos/index.md).
 - [Since GitLab 11.10](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/25504), pipelines for merge requests require GitLab Runner 11.9.
+- If you use this feature with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md),
+  pipelines for merge requests take precedence over the other regular pipelines.
 
 ## Configuring pipelines for merge requests
 
-To configure pipelines for merge requests, add the `only: [merge_requests]` parameter to
-your `.gitlab-ci.yml` file.
+To configure pipelines for merge requests, configure your CI yaml file.
+There are a few different ways to do this.
+
+### Enable pipelines for merge requests for all jobs
+
+The recommended method for enabling pipelines for merge requests for all jobs in
+a pipeline is to use [`workflow:rules`](../yaml/README.md#workflowrules).
+
+In this example, the pipeline always runs for all merge requests, as well as for all changes
+to the master branch:
+
+```yaml
+workflow:
+  rules:
+    - if: $CI_MERGE_REQUEST_ID               # Execute jobs in merge request context
+    - if: $CI_COMMIT_BRANCH == 'master'      # Execute jobs when a new commit is pushed to master branch
+
+build:
+  stage: build
+  script: ./build
+
+test:
+  stage: test
+  script: ./test
+
+deploy:
+  stage: deploy
+  script: ./deploy
+```
+
+### Enable pipelines for merge requests for specific jobs
+
+To enable pipelines for merge requests for specific jobs, you can use
+[`rules`](../yaml/README.md#rules).
+
+In the following example:
+
+- The `build` job runs for all changes to the `master` branch, as well as for all merge requests.
+- The `test` job runs for all merge requests.
+- The `deploy` job runs for all changes to the `master` branch, but does *not* run
+  for merge requests.
+
+```yaml
+build:
+  stage: build
+  script: ./build
+  rules:
+    - if: $CI_COMMIT_BRANCH == 'master'   # Execute jobs when a new commit is pushed to master branch
+    - if: $CI_MERGE_REQUEST_ID            # Execute jobs in merge request context
+
+test:
+  stage: test
+  script: ./test
+  rules:
+    - if: $CI_MERGE_REQUEST_ID             # Execute jobs in merge request context
+
+deploy:
+  stage: deploy
+  script: ./deploy
+  rules:
+    - if: $CI_COMMIT_BRANCH == 'master'    # Execute jobs when a new commit is pushed to master branch
+```
+
+### Use `only` or `except` to run pipelines for merge requests
+
+NOTE: **Note**:
+The [`only` / `except`](../yaml/README.md#onlyexcept-basic) keywords are going to be deprecated
+and you should not use them.
+
+To enable pipelines for merge requests, you can use `only / except`. When you use this method,
+you have to specify `only: - merge_requests` for each job.
 
 In this example, the pipeline contains a `test` job that is configured to run on merge requests.
 
@@ -54,24 +125,7 @@ deploy:
   - master
 ```
 
-Whenever a merge request is updated with new commits:
-
-- GitLab detects that changes have occurred and creates a new pipeline for the merge request.
-- The pipeline fetches the latest code from the source branch and run tests against it.
-
-NOTE: **Note**:
-If you use this feature with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md),
-pipelines for merge requests take precedence over the other regular pipelines.
-
-## Pipelines for Merged Results **(PREMIUM)**
-
-Read the [documentation on Pipelines for Merged Results](pipelines_for_merged_results/index.md).
-
-### Merge Trains **(PREMIUM)**
-
-Read the [documentation on Merge Trains](pipelines_for_merged_results/merge_trains/index.md).
-
-## Excluding certain jobs
+#### Excluding certain jobs
 
 The behavior of the `only: [merge_requests]` parameter is such that _only_ jobs with
 that parameter are run in the context of a merge request; no other jobs will be run.
@@ -119,7 +173,7 @@ Therefore:
 This helps you avoid having to add the `only:` rule to all of your jobs
 in order to make them always run. You can use this format to set up a Review App, helping to save resources.
 
-## Excluding certain branches
+#### Excluding certain branches
 
 Pipelines for merge requests require special treatment when
 using [`only`/`except`](../yaml/README.md#onlyexcept-basic). Unlike ordinary
@@ -149,6 +203,14 @@ test:
       - $CI_COMMIT_REF_NAME =~ /^docs-/
 ```
 
+## Pipelines for Merged Results **(PREMIUM)**
+
+Read the [documentation on Pipelines for Merged Results](pipelines_for_merged_results/index.md).
+
+### Merge Trains **(PREMIUM)**
+
+Read the [documentation on Merge Trains](pipelines_for_merged_results/merge_trains/index.md).
+
 ## Important notes about merge requests from forked projects
 
 Note that the current behavior is subject to change. In the usual contribution

doc/user/group/roadmap/index.md

@@ -6,24 +6,28 @@ type: reference
 
 > - Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.5.
 > - In [GitLab 12.9](https://gitlab.com/gitlab-org/gitlab/issues/198062), Roadmaps were moved to the Premium tier.
-> - In [GitLab 12.9](https://gitlab.com/gitlab-org/gitlab/issues/5164) and later, the epic bars show their title, progress, and completed weight percentage.
+> - In [GitLab 12.9](https://gitlab.com/gitlab-org/gitlab/issues/5164) and later, the epic bars show epics' title, progress, and completed weight percentage.
+> - In [GitLab 12.10](https://gitlab.com/gitlab-org/gitlab/-/issues/6802), and later, milestones appear in Roadmaps.
 
-An Epic within a group containing **Start date** and/or **Due date**
-can be visualized in a form of a timeline (a Gantt chart). The Epics Roadmap page
-shows such a visualization for all the epics which are under a group and/or its subgroups.
+Epics and milestones within a group containing **Start date** and/or **Due date**
+can be visualized in a form of a timeline (that is, a Gantt chart). The Roadmap page
+shows such a visualization for all the epics and milestones which are under a group or one of its
+subgroups.
 
-On the epic bars, you can see their title, progress, and completed weight percentage.
-When you hover over an epic bar, a popover appears with its title, start and due dates, and weight
-completed.
+On the epic bars, you can see the each epic's title, progress, and completed weight percentage.
+When you hover over an epic bar, a popover appears with the epic's title, start date, due date, and
+weight completed.
 
 You can expand epics that contain child epics to show their child epics in the roadmap.
 You can click the chevron **{chevron-down}** next to the epic title to expand and collapse the child epics.
 
-![roadmap view](img/roadmap_view_v12_9.png)
+On top of the milestone bars, you can see their title. When you hover a milestone bar or title, a popover appears with its title, start date and due date.
+
+![roadmap view](img/roadmap_view_v12_10.png)
 
 A dropdown menu allows you to show only open or closed epics. By default, all epics are shown.
 
-![epics state dropdown](img/epics_state_dropdown.png)
+![epics state dropdown](img/epics_state_dropdown_v12_10.png)
 
 You can sort epics in the Roadmap view by:
 
@@ -32,8 +36,8 @@ You can sort epics in the Roadmap view by:
 - Start date
 - Due date
 
-Each option contains a button that toggles the sort order between **ascending** and **descending**. The sort option and order will be persisted when browsing Epics,
-including the [epics list view](../epics/index.md).
+Each option contains a button that toggles the sort order between **ascending** and **descending**.
+The sort option and order persist when browsing Epics, including the [epics list view](../epics/index.md).
 
 Roadmaps can also be [visualized inside an epic](../epics/index.md#roadmap-in-epics).
 
@@ -45,15 +49,16 @@ Roadmaps can also be [visualized inside an epic](../epics/index.md#roadmap-in-ep
 Roadmap supports the following date ranges:
 
 - Quarters
-- Months (Default)
+- Months (default)
 - Weeks
 
 ### Quarters
 
 ![roadmap date range in quarters](img/roadmap_timeline_quarters.png)
 
-In _Quarters_ preset, roadmap shows epics which have start or due dates _falling within_ or
-_going through_ **past quarter**, **current quarter** and **next 4 quarters**, where _today_
+In the **Quarters** preset, roadmap shows epics and milestones which have start or due dates
+**falling within** or **going through** past quarter, current quarter, and the next four quarters,
+where **today**
 is shown by the vertical red line in the timeline. The sub-headers underneath the quarter name on
 the timeline header represent the month of the quarter.
 
@@ -61,8 +66,9 @@ the timeline header represent the month of the quarter.
 
 ![roadmap date range in months](img/roadmap_timeline_months.png)
 
-In _Months_ preset, roadmap shows epics which have start or due dates _falling within_ or
-_going through_ **past month**, **current month** and **next 5 months**, where _today_
+In the **Months** preset, roadmap shows epics and milestones which have start or due dates
+**falling within** or
+**going through** the past month, current month, and the next five months, where **today**
 is shown by the vertical red line in the timeline. The sub-headers underneath the month name on
 the timeline header represent the date on starting day (Sunday) of the week. This preset is
 selected by default.
@@ -71,14 +77,15 @@ selected by default.
 
 ![roadmap date range in weeks](img/roadmap_timeline_weeks.png)
 
-In _Weeks_ preset, roadmap shows epics which have start or due dates _falling within_ or
-_going through_ **past week**, **current week** and **next 4 weeks**, where _today_
+In the **Weeks** preset, roadmap shows epics and milestones which have start or due dates **falling
+within** or **going through** the past week, current week and the next four weeks, where **today**
 is shown by the vertical red line in the timeline. The sub-headers underneath the week name on
 the timeline header represent the days of the week.
 
-## Timeline bar for an epic
+## Roadmap timeline bar
 
-The timeline bar indicates the approximate position of an epic based on its start and due date.
+The timeline bar indicates the approximate position of an epic or milestone based on its start and
+due dates.
 
 <!-- ## Troubleshooting
 

lib/gitlab/ci/reports/test_reports.rb

@@ -34,6 +34,14 @@ module Gitlab
           end
         end
 
+        def with_attachment!
+          @test_suites.keep_if do |_job_name, test_suite|
+            test_suite.with_attachment!.present?
+          end
+
+          self
+        end
+
         TestCase::STATUS_TYPES.each do |status_type|
           define_method("#{status_type}_count") do
             # rubocop: disable CodeReuse/ActiveRecord

lib/gitlab/ci/reports/test_suite.rb

@@ -37,6 +37,16 @@ module Gitlab
           end
         end
 
+        def with_attachment!
+          @test_cases = @test_cases.extract!("failed")
+
+          @test_cases.keep_if do |status, hash|
+            hash.any? do |key, test_case|
+              test_case.has_attachment?
+            end
+          end
+        end
+
         TestCase::STATUS_TYPES.each do |status_type|
           define_method("#{status_type}") do
             test_cases[status_type] || {}

spec/factories/ci/test_case.rb

@@ -11,7 +11,12 @@ FactoryBot.define do
     attachment { nil }
     association :job, factory: :ci_build
 
+    trait :failed do
+      status { "failed" }
+    end
+
     trait :with_attachment do
+      status { "failed" }
       attachment { "some/path.png" }
     end
 

spec/javascripts/ide/components/commit_sidebar/actions_spec.js

@@ -85,6 +85,13 @@ describe('IDE commit sidebar actions', () => {
       expect(vm.$store.dispatch).not.toHaveBeenCalled();
     });
 
+    it('is not called on mount if there is already a selected commitAction', () => {
+      store.state.commitAction = '1';
+      createComponent({ currentBranchId: null });
+
+      expect(vm.$store.dispatch).not.toHaveBeenCalled();
+    });
+
     it('calls again after staged changes', done => {
       createComponent({ currentBranchId: null });
 

spec/lib/gitlab/ci/reports/test_reports_spec.rb

@@ -109,6 +109,38 @@ describe Gitlab::Ci::Reports::TestReports do
     end
   end
 
+  describe '#with_attachment' do
+    let(:test_case) { build(:test_case, :failed) }
+
+    subject { test_reports.with_attachment! }
+
+    context 'when test suites do not contain an attachment' do
+      before do
+        test_reports.get_suite('rspec').add_test_case(create_test_case_rspec_success)
+        test_reports.get_suite('junit').add_test_case(test_case)
+      end
+
+      it 'returns empty test suites' do
+        expect(subject.test_suites).to be_empty
+      end
+    end
+
+    context 'when test suites contain an attachment' do
+      let(:test_case_succes) { build(:test_case) }
+      let(:test_case_with_attachment) { build(:test_case, :with_attachment) }
+
+      before do
+        test_reports.get_suite('rspec').add_test_case(test_case_succes)
+        test_reports.get_suite('junit').add_test_case(test_case_with_attachment)
+      end
+
+      it 'returns test suites with attachment' do
+        expect(subject.test_suites.count).to eq(1)
+        expect(subject.test_suites['junit'].test_cases['failed']).to be_present
+      end
+    end
+  end
+
   Gitlab::Ci::Reports::TestCase::STATUS_TYPES.each do |status_type|
     describe "##{status_type}_count" do
       subject { test_reports.public_send("#{status_type}_count") }

spec/lib/gitlab/ci/reports/test_suite_spec.rb

@@ -85,6 +85,35 @@ describe Gitlab::Ci::Reports::TestSuite do
     end
   end
 
+  describe '#with_attachment' do
+    subject { test_suite.with_attachment! }
+
+    context 'when test cases do not contain an attachment' do
+      let(:test_case) { build(:test_case, :failed)}
+
+      before do
+        test_suite.add_test_case(test_case)
+      end
+
+      it 'returns an empty hash' do
+        expect(subject).to be_empty
+      end
+    end
+
+    context 'when test cases contain an attachment' do
+      let(:test_case_with_attachment) { build(:test_case, :with_attachment)}
+
+      before do
+        test_suite.add_test_case(test_case_with_attachment)
+      end
+
+      it 'returns failed test cases with attachment' do
+        expect(subject.count).to eq(1)
+        expect(subject['failed']).to be_present
+      end
+    end
+  end
+
   Gitlab::Ci::Reports::TestCase::STATUS_TYPES.each do |status_type|
     describe "##{status_type}" do
       subject { test_suite.public_send("#{status_type}") }