Commit ba836d98 authored by GitLab Bot's avatar GitLab Bot

Add latest changes from gitlab-org/gitlab@master

parent 796b00a9
...@@ -124,6 +124,5 @@ ...@@ -124,6 +124,5 @@
"YouTrack" "YouTrack"
], ],
"code_blocks": false "code_blocks": false
}, }
"code-fence-style": false
} }
...@@ -36,7 +36,9 @@ export default { ...@@ -36,7 +36,9 @@ export default {
}, },
}, },
mounted() { mounted() {
this.updateSelectedCommitAction(); if (!this.commitAction) {
this.updateSelectedCommitAction();
}
}, },
methods: { methods: {
...mapCommitActions(['updateCommitAction']), ...mapCommitActions(['updateCommitAction']),
......
export default () => ({ export default () => ({
commitMessage: '', commitMessage: '',
commitAction: '1', commitAction: null,
newBranchName: '', newBranchName: '',
submitCommitLoading: false, submitCommitLoading: false,
shouldCreateMR: true, shouldCreateMR: true,
......
...@@ -23,11 +23,82 @@ A few notes: ...@@ -23,11 +23,82 @@ A few notes:
- Pipelines for merge requests are incompatible with - Pipelines for merge requests are incompatible with
[CI/CD for external repositories](../ci_cd_for_external_repos/index.md). [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. - [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 ## Configuring pipelines for merge requests
To configure pipelines for merge requests, add the `only: [merge_requests]` parameter to To configure pipelines for merge requests, configure your CI yaml file.
your `.gitlab-ci.yml` 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. In this example, the pipeline contains a `test` job that is configured to run on merge requests.
...@@ -54,24 +125,7 @@ deploy: ...@@ -54,24 +125,7 @@ deploy:
- master - master
``` ```
Whenever a merge request is updated with new commits: #### Excluding certain jobs
- 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
The behavior of the `only: [merge_requests]` parameter is such that _only_ jobs with 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. that parameter are run in the context of a merge request; no other jobs will be run.
...@@ -119,7 +173,7 @@ Therefore: ...@@ -119,7 +173,7 @@ Therefore:
This helps you avoid having to add the `only:` rule to all of your jobs 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. 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 Pipelines for merge requests require special treatment when
using [`only`/`except`](../yaml/README.md#onlyexcept-basic). Unlike ordinary using [`only`/`except`](../yaml/README.md#onlyexcept-basic). Unlike ordinary
...@@ -149,6 +203,14 @@ test: ...@@ -149,6 +203,14 @@ test:
- $CI_COMMIT_REF_NAME =~ /^docs-/ - $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 ## Important notes about merge requests from forked projects
Note that the current behavior is subject to change. In the usual contribution Note that the current behavior is subject to change. In the usual contribution
......
...@@ -6,24 +6,28 @@ type: reference ...@@ -6,24 +6,28 @@ type: reference
> - Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.5. > - 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/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** Epics and milestones 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 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 which are under a group and/or its subgroups. 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. 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 its title, start and due dates, and weight When you hover over an epic bar, a popover appears with the epic's title, start date, due date, and
completed. weight completed.
You can expand epics that contain child epics to show their child epics in the roadmap. 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. 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. 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: You can sort epics in the Roadmap view by:
...@@ -32,8 +36,8 @@ You can sort epics in the Roadmap view by: ...@@ -32,8 +36,8 @@ You can sort epics in the Roadmap view by:
- Start date - Start date
- Due 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, Each option contains a button that toggles the sort order between **ascending** and **descending**.
including the [epics list view](../epics/index.md). 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). 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 ...@@ -45,15 +49,16 @@ Roadmaps can also be [visualized inside an epic](../epics/index.md#roadmap-in-ep
Roadmap supports the following date ranges: Roadmap supports the following date ranges:
- Quarters - Quarters
- Months (Default) - Months (default)
- Weeks - Weeks
### Quarters ### Quarters
![roadmap date range in quarters](img/roadmap_timeline_quarters.png) ![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 In the **Quarters** preset, roadmap shows epics and milestones which have start or due dates
_going through_ **past quarter**, **current quarter** and **next 4 quarters**, where _today_ **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 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. the timeline header represent the month of the quarter.
...@@ -61,8 +66,9 @@ 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) ![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 In the **Months** preset, roadmap shows epics and milestones which have start or due dates
_going through_ **past month**, **current month** and **next 5 months**, where _today_ **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 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 the timeline header represent the date on starting day (Sunday) of the week. This preset is
selected by default. selected by default.
...@@ -71,14 +77,15 @@ selected by default. ...@@ -71,14 +77,15 @@ selected by default.
![roadmap date range in weeks](img/roadmap_timeline_weeks.png) ![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 In the **Weeks** preset, roadmap shows epics and milestones which have start or due dates **falling
_going through_ **past week**, **current week** and **next 4 weeks**, where _today_ 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 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. 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 <!-- ## Troubleshooting
......
...@@ -34,6 +34,14 @@ module Gitlab ...@@ -34,6 +34,14 @@ module Gitlab
end end
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| TestCase::STATUS_TYPES.each do |status_type|
define_method("#{status_type}_count") do define_method("#{status_type}_count") do
# rubocop: disable CodeReuse/ActiveRecord # rubocop: disable CodeReuse/ActiveRecord
......
...@@ -37,6 +37,16 @@ module Gitlab ...@@ -37,6 +37,16 @@ module Gitlab
end end
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| TestCase::STATUS_TYPES.each do |status_type|
define_method("#{status_type}") do define_method("#{status_type}") do
test_cases[status_type] || {} test_cases[status_type] || {}
......
...@@ -11,7 +11,12 @@ FactoryBot.define do ...@@ -11,7 +11,12 @@ FactoryBot.define do
attachment { nil } attachment { nil }
association :job, factory: :ci_build association :job, factory: :ci_build
trait :failed do
status { "failed" }
end
trait :with_attachment do trait :with_attachment do
status { "failed" }
attachment { "some/path.png" } attachment { "some/path.png" }
end end
......
...@@ -85,6 +85,13 @@ describe('IDE commit sidebar actions', () => { ...@@ -85,6 +85,13 @@ describe('IDE commit sidebar actions', () => {
expect(vm.$store.dispatch).not.toHaveBeenCalled(); 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 => { it('calls again after staged changes', done => {
createComponent({ currentBranchId: null }); createComponent({ currentBranchId: null });
......
...@@ -109,6 +109,38 @@ describe Gitlab::Ci::Reports::TestReports do ...@@ -109,6 +109,38 @@ describe Gitlab::Ci::Reports::TestReports do
end end
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| Gitlab::Ci::Reports::TestCase::STATUS_TYPES.each do |status_type|
describe "##{status_type}_count" do describe "##{status_type}_count" do
subject { test_reports.public_send("#{status_type}_count") } subject { test_reports.public_send("#{status_type}_count") }
......
...@@ -85,6 +85,35 @@ describe Gitlab::Ci::Reports::TestSuite do ...@@ -85,6 +85,35 @@ describe Gitlab::Ci::Reports::TestSuite do
end end
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| Gitlab::Ci::Reports::TestCase::STATUS_TYPES.each do |status_type|
describe "##{status_type}" do describe "##{status_type}" do
subject { test_suite.public_send("#{status_type}") } subject { test_suite.public_send("#{status_type}") }
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment