diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2022-06-20 14:10:13 +0300 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2022-06-20 14:10:13 +0300 |
| commit | 0ea3fcec397b69815975647f5e2aa5fe944a8486 (patch) | |
| tree | 7979381b89d26011bcf9bdc989a40fcc2f1ed4ff /doc/user/project/merge_requests | |
| parent | 72123183a20411a36d607d70b12d57c484394c8e (diff) | |
Add latest changes from gitlab-org/gitlab@15-1-stable-eev15.1.0-rc42
Diffstat (limited to 'doc/user/project/merge_requests')
23 files changed, 296 insertions, 133 deletions
diff --git a/doc/user/project/merge_requests/accessibility_testing.md b/doc/user/project/merge_requests/accessibility_testing.md index 612f499bb65..b8907532066 100644 --- a/doc/user/project/merge_requests/accessibility_testing.md +++ b/doc/user/project/merge_requests/accessibility_testing.md @@ -46,10 +46,10 @@ To define the `a11y` job for GitLab 12.9 and later: ```yaml stages: - accessibility - + variables: a11y_urls: "https://about.gitlab.com https://gitlab.com/users/sign_in" - + include: - template: "Verify/Accessibility.gitlab-ci.yml" ``` diff --git a/doc/user/project/merge_requests/approvals/index.md b/doc/user/project/merge_requests/approvals/index.md index f0ab4d606ad..014936208c6 100644 --- a/doc/user/project/merge_requests/approvals/index.md +++ b/doc/user/project/merge_requests/approvals/index.md @@ -22,7 +22,8 @@ flexibility: - Specify a list of users who act as [code owners](../../code_owners.md) for specific files, and require their approval before work can merge. -You can configure merge request approvals on a per-project basis. Administrators of +You can configure merge request approvals on a per-project basis, and +[on the group level](../../../group/index.md#group-merge-request-approval-settings). Administrators of [GitLab Premium](https://about.gitlab.com/pricing/) and [GitLab Ultimate](https://about.gitlab.com/pricing/) self-managed GitLab instances can also configure approvals @@ -103,7 +104,18 @@ Without the approvals, the work cannot merge. Required approvals enable multiple to determine who should review the work. - Require an [approval before merging code that causes test coverage to decline](../../../../ci/pipelines/settings.md#coverage-check-approval-rule) - Users on GitLab Ultimate can also [require approval from a security team](../../../application_security/index.md#security-approvals-in-merge-requests) - before merging code that could introduce a vulnerability. + before merging code that could introduce a vulnerability. + +## Invalid rules + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/334698) in GitLab 15.1. + +Whenever an approval rule cannot be satisfied, the rule will be displayed as `Invalid`. This applies to the following conditions: + +- The only eligible approver is the author of the merge request. +- No eligible approvers (either groups or users) have been assigned to the approval rule. + +These rules will be automatically approved to unblock their respective merge requests. ## Related topics diff --git a/doc/user/project/merge_requests/approvals/rules.md b/doc/user/project/merge_requests/approvals/rules.md index 17a42e1b540..21cf5cca4d1 100644 --- a/doc/user/project/merge_requests/approvals/rules.md +++ b/doc/user/project/merge_requests/approvals/rules.md @@ -250,6 +250,10 @@ For more information about this validation error, read You can use [scan result policies](../../../application_security/policies/scan-result-policies.md#scan-result-policy-editor) to define security approvals based on the status of vulnerabilities in the merge request and the default branch. Details for each security policy is shown in the Security Approvals section of your Merge Request configuration. +The security approval rules are applied to all merge requests until the pipeline is complete. The application of the +security approval rules prevents users from merging in code before the security scans run. Once the pipeline is +complete, the security approval rules are checked to determine if the security approvals are still required. +  These policies are both created and edited in the [security policy editor](../../../application_security/policies/index.md#policy-editor). diff --git a/doc/user/project/merge_requests/approvals/settings.md b/doc/user/project/merge_requests/approvals/settings.md index 9c2b54888fb..9295ea4c310 100644 --- a/doc/user/project/merge_requests/approvals/settings.md +++ b/doc/user/project/merge_requests/approvals/settings.md @@ -139,7 +139,7 @@ You can also enforce merge request approval settings: - At the [instance level](../../../admin_area/merge_requests_approvals.md), which apply to all groups on an instance and, therefore, all projects. -- On a [top-level group](../../../group/index.md#group-approval-settings), which apply to all subgroups +- On a [top-level group](../../../group/index.md#group-merge-request-approval-settings), which apply to all subgroups and projects. If the settings are inherited by a group or project, they cannot be changed in the group or project diff --git a/doc/user/project/merge_requests/cherry_pick_changes.md b/doc/user/project/merge_requests/cherry_pick_changes.md index fb41ec3eff6..14f3979cf34 100644 --- a/doc/user/project/merge_requests/cherry_pick_changes.md +++ b/doc/user/project/merge_requests/cherry_pick_changes.md @@ -18,7 +18,7 @@ to cherry-pick the changes introduced by that merge request.  -After you click that button, a modal displays a +After you select that button, a modal displays a [branch filter search box](../repository/branches/index.md#branch-filter-search-box) where you can choose to either: @@ -69,12 +69,12 @@ git cherry-pick -m 2 7a39eb0 You can cherry-pick merge requests from the same project, or forks of the same project, from the GitLab user interface: -1. In the merge request's secondary menu, click **Commits** to display the commit details page. -1. Click on the **Options** dropdown and select **Cherry-pick** to show the cherry-pick modal. +1. In the merge request's secondary menu, select **Commits** to display the commit details page. +1. Select the **Options** dropdown and select **Cherry-pick** to show the cherry-pick modal. 1. In **Pick into project** and **Pick into branch**, select the destination project and branch:  1. Optional. Select **Start a new merge request** if you're ready to create a merge request. -1. Click **Cherry-pick**. +1. Select **Cherry-pick**. ## Related topics diff --git a/doc/user/project/merge_requests/code_quality.md b/doc/user/project/merge_requests/code_quality.md index 7e8ef9272d4..623af914692 100644 --- a/doc/user/project/merge_requests/code_quality.md +++ b/doc/user/project/merge_requests/code_quality.md @@ -28,6 +28,20 @@ Code Quality: - Is available by using [Auto Code Quality](../../../topics/autodevops/stages.md#auto-code-quality), provided by [Auto DevOps](../../../topics/autodevops/index.md). - Can be extended through [Analysis Plugins](https://docs.codeclimate.com/docs/list-of-engines) or a [custom tool](#implementing-a-custom-tool). +## Summary of features per tier + +Different features are available in different [GitLab tiers](https://about.gitlab.com/pricing/), +as shown in the following table: + +| Capability | In Free | In Premium | In Ultimate | +|:----------------------------------------------------------------------|:--------------------|:--------------------|:-------------------| +| [Configure scanners](#configuring-jobs-using-variables) | **{check-circle}** | **{check-circle}** | **{check-circle}** | +| [Integrate custom scanners](#implementing-a-custom-tool) | **{check-circle}** | **{check-circle}** | **{check-circle}** | +| [Generate JSON or HTML report artifacts](#generate-an-html-report) | **{check-circle}** | **{check-circle}** | **{check-circle}** | +| [See findings in merge request widget](#code-quality-widget) | **{check-circle}** | **{check-circle}** | **{check-circle}** | +| [See reports in CI pipelines](#code-quality-reports) | **{dotted-circle}** | **{check-circle}** | **{check-circle}** | +| [See findings in merge request diff view](#code-quality-in-diff-view) | **{dotted-circle}** | **{dotted-circle}** | **{check-circle}** | + ## Code Quality Widget > [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/212499) to GitLab Free in 13.2. @@ -242,7 +256,7 @@ This can be done: - For a single pipeline run: 1. Go to **CI/CD > Pipelines** - 1. Click **Run pipeline** + 1. Select **Run pipeline** 1. Add `CODE_QUALITY_DISABLED` as the variable key, with any value. ### Using with merge request pipelines @@ -402,32 +416,40 @@ CI/CD variable to `html`. This is useful if you just want to view the report in human-readable format or to publish this artifact on GitLab Pages for even easier reviewing. +To generate both JSON and HTML report files, add another job to your template by using `extends: code_quality`: + ```yaml include: - template: Code-Quality.gitlab-ci.yml -code_quality: +code_quality_html: + extends: code_quality variables: REPORT_FORMAT: html artifacts: paths: [gl-code-quality-report.html] ``` -It's also possible to generate both JSON and HTML report files by defining -another job and using `extends: code_quality`: +NOTE: +Adding a job means your code is scanned twice: once to generate a JSON report and once to generate an HTML report. + +You can also generate _only_ an HTML report instead of the standard JSON report. To do so, set `REPORT_FORMAT` to `html` in the existing job: ```yaml include: - template: Code-Quality.gitlab-ci.yml -code_quality_html: - extends: code_quality +code_quality: variables: REPORT_FORMAT: html artifacts: paths: [gl-code-quality-report.html] ``` +WARNING: +If you only generate an HTML report, you can't see your results in the [merge request widget](#code-quality-widget), [pipeline report](#code-quality-reports), or [diff view](#code-quality-in-diff-view). +These features require a JSON report. + ## Extending functionality ### Using Analysis Plugins @@ -557,9 +579,9 @@ GitLab only uses the Code Quality artifact from the latest created job (with the If multiple jobs in a pipeline generate a code quality artifact, those of earlier jobs are ignored. To avoid confusion, configure only one job to generate a `gl-code-quality-report.json`. -### Rubocop errors +### RuboCop errors -When using Code Quality jobs on a Ruby project, you can encounter problems running Rubocop. +When using Code Quality jobs on a Ruby project, you can encounter problems running RuboCop. For example, the following error can appear when using either a very recent or very old version of Ruby: @@ -569,15 +591,15 @@ Unknown Ruby version 2.7 found in `.ruby-version`. (RuboCop::ValidationError) Supported versions: 2.1, 2.2, 2.3, 2.4, 2.5 ``` -This is caused by the default version of Rubocop used by the check engine not covering +This is caused by the default version of RuboCop used by the check engine not covering support for the Ruby version in use. -To use a custom version of Rubocop that +To use a custom version of RuboCop that [supports the version of Ruby used by the project](https://docs.rubocop.org/rubocop/compatibility.html#support-matrix), you can [override the configuration through a `.codeclimate.yml` file](https://docs.codeclimate.com/docs/rubocop#using-rubocops-newer-versions) created in the project repository. -For example, to specify using Rubocop release **0.67**: +For example, to specify using RuboCop release **0.67**: ```yaml version: "2" diff --git a/doc/user/project/merge_requests/commit_templates.md b/doc/user/project/merge_requests/commit_templates.md index b9b65d759dc..6f9bc452b96 100644 --- a/doc/user/project/merge_requests/commit_templates.md +++ b/doc/user/project/merge_requests/commit_templates.md @@ -92,8 +92,8 @@ Commit message templates support these variables: Any line containing only an empty variable is removed. If the line to be removed is both preceded and followed by an empty line, the preceding empty line is also removed. -After you edit a commit message on an open merge request, GitLab will -not automatically update the commit message again. +After you edit a commit message on an open merge request, GitLab +automatically updates the commit message again. To restore the commit message to the project template, reload the page. ## Related topics diff --git a/doc/user/project/merge_requests/csv_export.md b/doc/user/project/merge_requests/csv_export.md index df527ec6ebf..aaa9bec945f 100644 --- a/doc/user/project/merge_requests/csv_export.md +++ b/doc/user/project/merge_requests/csv_export.md @@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w Exporting merge requests CSV enables you and your team to export all the data collected from merge requests into a comma-separated values (CSV) file, which stores tabular data in plain text. -To export merge requests to CSV, navigate to your **Merge requests** from the sidebar of a project and click **Export to CSV**. +To export merge requests to CSV, navigate to your **Merge requests** from the sidebar of a project and select **Export to CSV**. ## CSV Output diff --git a/doc/user/project/merge_requests/drafts.md b/doc/user/project/merge_requests/drafts.md index 637b682d603..13cc68f02dd 100644 --- a/doc/user/project/merge_requests/drafts.md +++ b/doc/user/project/merge_requests/drafts.md @@ -23,14 +23,14 @@ the **Merge** button until you remove the **Draft** flag: There are several ways to flag a merge request as a draft: -- **Viewing a merge request**: In the top right corner of the merge request, click **Mark as draft**. +- **Viewing a merge request**: In the top right corner of the merge request, select **Mark as draft**. - **Creating or editing a merge request**: Add `[Draft]`, `Draft:` or `(Draft)` to - the beginning of the merge request's title, or click **Start the title with Draft:** + the beginning of the merge request's title, or select **Start the title with Draft:** below the **Title** field. - **Commenting in an existing merge request**: Add the `/draft` [quick action](../quick_actions.md#issues-merge-requests-and-epics) in a comment. This quick action is a toggle, and can be repeated to change the status - again. This quick action discards any other text in the comment. + back to Ready. - **Creating a commit**: Add `draft:`, `Draft:`, `fixup!`, or `Fixup!` to the beginning of a commit message targeting the merge request's source branch. This is not a toggle, and adding this text again in a later commit doesn't mark the @@ -40,19 +40,18 @@ There are several ways to flag a merge request as a draft: When a merge request is ready to be merged, you can remove the `Draft` flag in several ways: -- **Viewing a merge request**: In the top right corner of the merge request, click **Mark as ready**. +- **Viewing a merge request**: In the top right corner of the merge request, select **Mark as ready**. Users with at least the Developer role - can also scroll to the bottom of the merge request description and click **Mark as ready**: + can also scroll to the bottom of the merge request description and select **Mark as ready**:  - **Editing an existing merge request**: Remove `[Draft]`, `Draft:` or `(Draft)` - from the beginning of the title, or click **Remove the Draft: prefix from the title** + from the beginning of the title, or select **Remove the Draft: prefix from the title** below the **Title** field. -- **Commenting in an existing merge request**: Add the `/draft` +- **Commenting in an existing merge request**: Add the `/ready` [quick action](../quick_actions.md#issues-merge-requests-and-epics) - in a comment in the merge request. This quick action is a toggle, and can be repeated - to change the status back. This quick action discards any other text in the comment. + in a comment in the merge request. In [GitLab 13.10 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/15332), when you mark a merge request as ready, notifications are triggered to @@ -64,9 +63,9 @@ When viewing or searching in your project's merge requests list, you can include draft merge requests: 1. Go to your project and select **Merge requests**. -1. In the navigation bar, click **Open**, **Merged**, **Closed**, or **All** to +1. In the navigation bar, select **Open**, **Merged**, **Closed**, or **All** to filter by merge request status. -1. Click the search box to display a list of filters and select **Draft**, or +1. Select the search box to display a list of filters and select **Draft**, or enter the word `draft`. 1. Select `=`. 1. Select **Yes** to include drafts, or **No** to exclude, and press **Return** diff --git a/doc/user/project/merge_requests/getting_started.md b/doc/user/project/merge_requests/getting_started.md index c1986a80ca0..09ee828ffd3 100644 --- a/doc/user/project/merge_requests/getting_started.md +++ b/doc/user/project/merge_requests/getting_started.md @@ -126,7 +126,7 @@ When creating a merge request, select the **Delete source branch when merge request accepted** option, and the source branch is deleted when the merge request is merged. To make this option enabled by default for all new merge requests, enable it in the -[project's settings](../settings/index.md#merge-request-settings). +[project's settings](../settings/index.md#configure-merge-request-settings-for-a-project). This option is also visible in an existing merge request next to the merge request button and can be selected or cleared before merging. @@ -140,35 +140,6 @@ is set for deletion, the merge request widget displays the  -### Branch retargeting on merge **(FREE SELF)** - -> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/320902) in GitLab 13.9. -> - [Disabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/320902) in GitLab 13.9. -> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/320895) GitLab 13.10. - -In specific circumstances, GitLab can retarget the destination branch of -open merge request, if the destination branch merges while the merge request is -open. Merge requests are often chained in this manner, with one merge request -depending on another: - -- **Merge request 1**: merge `feature-alpha` into `main`. -- **Merge request 2**: merge `feature-beta` into `feature-alpha`. - -These merge requests are usually handled in one of these ways: - -- Merge request 1 is merged into `main` first. Merge request 2 is then - retargeted to `main`. -- Merge request 2 is merged into `feature-alpha`. The updated merge request 1, which - now contains the contents of `feature-alpha` and `feature-beta`, is merged into `main`. - -GitLab retargets up to four merge requests when their target branch is merged into -`main`, so you don't need to perform this operation manually. Merge requests from -forks are not retargeted. - -The feature today works only on merge. Clicking the **Remove source branch** button -after the merge request was merged will not automatically retarget a merge request. -This improvement is [tracked as a follow-up](https://gitlab.com/gitlab-org/gitlab/-/issues/321559). - ## Recommendations and best practices for merge requests - When working locally in your branch, add multiple commits and only push when diff --git a/doc/user/project/merge_requests/img/ff_merge_rebase_v14_9.png b/doc/user/project/merge_requests/img/ff_merge_rebase_v14_9.png Binary files differdeleted file mode 100644 index 17ce42e7a69..00000000000 --- a/doc/user/project/merge_requests/img/ff_merge_rebase_v14_9.png +++ /dev/null diff --git a/doc/user/project/merge_requests/img/filter_approved_by_merge_requests_v14_6.png b/doc/user/project/merge_requests/img/filter_approved_by_merge_requests_v14_6.png Binary files differnew file mode 100644 index 00000000000..8d47fdc2652 --- /dev/null +++ b/doc/user/project/merge_requests/img/filter_approved_by_merge_requests_v14_6.png diff --git a/doc/user/project/merge_requests/img/filter_approver_merge_requests_v14_6.png b/doc/user/project/merge_requests/img/filter_approver_merge_requests_v14_6.png Binary files differnew file mode 100644 index 00000000000..58950031378 --- /dev/null +++ b/doc/user/project/merge_requests/img/filter_approver_merge_requests_v14_6.png diff --git a/doc/user/project/merge_requests/img/filtering_merge_requests_by_date_v14_6.png b/doc/user/project/merge_requests/img/filtering_merge_requests_by_date_v14_6.png Binary files differnew file mode 100644 index 00000000000..398820f7864 --- /dev/null +++ b/doc/user/project/merge_requests/img/filtering_merge_requests_by_date_v14_6.png diff --git a/doc/user/project/merge_requests/img/filtering_merge_requests_by_environment_v14_6.png b/doc/user/project/merge_requests/img/filtering_merge_requests_by_environment_v14_6.png Binary files differnew file mode 100644 index 00000000000..c35f2c8a58b --- /dev/null +++ b/doc/user/project/merge_requests/img/filtering_merge_requests_by_environment_v14_6.png diff --git a/doc/user/project/merge_requests/index.md b/doc/user/project/merge_requests/index.md index 510dcd82907..30b69c2fff5 100644 --- a/doc/user/project/merge_requests/index.md +++ b/doc/user/project/merge_requests/index.md @@ -45,13 +45,100 @@ If your group contains subgroups, this view also displays merge requests from th To view all merge requests assigned to you: +<!-- vale gitlab.FirstPerson = NO --> + 1. On the top bar, put your cursor in the **Search** box. 1. From the dropdown list, select **Merge requests assigned to me**. -Or, to use a [keyboard shortcut](../../shortcuts.md), press <kbd>Shift</kbd> + <kbd>m</kbd>. +<!-- vale gitlab.FirstPerson = YES --> + +Or: + +- To use a [keyboard shortcut](../../shortcuts.md), press <kbd>Shift</kbd> + <kbd>m</kbd>. +- On the top bar, on the top right, select **{merge-request-open}** **Merge requests**. + Then select one of the following: + - [Review requests](reviews/index.md). + - Merge requests assigned. + +## Filter the list of merge requests + +To filter the list of merge requests: + +1. Above the list of merge requests, select **Search or filter results...**. +1. In the dropdown list that appears, select the attribute you wish to filter by. +1. Select or type the operator to use for filtering the attribute. The following operators are + available: + - `=`: Is + - `!=`: Is not ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18059) in GitLab 12.7) +1. Enter the text to filter the attribute by. + You can filter some attributes by **None** or **Any**. +1. Repeat this process to filter by multiple attributes. Multiple attributes are joined by a logical + `AND`. + +GitLab displays the results on-screen, but you can also +[retrieve them as an RSS feed](../../search/index.md#retrieve-search-results-as-feed). + +### Filter merge requests by ID + +> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/39908) in GitLab 12.1. + +You can filter the **Merge Request** list to find merge requests by their ID. + +For example, enter filter `#30` to return only merge request 30. + +### Filter merge requests by approvers **(PREMIUM)** + +> Moved to GitLab Premium in 13.9. + +To filter merge requests by an individual eligible approver ([Code owner](../code_owners.md)), you can type (or select from +the dropdown list) **Approver** and select the user. + + + +### Filter merge requests by "approved by" **(PREMIUM)** + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/30335) in GitLab 13.0. +> - Moved to GitLab Premium in 13.9. + +To filter merge requests already approved by a specific individual, you can type (or select from +the dropdown list) **Approved-By** and select the user. + + -You can [search and filter](../../search/index.md#filter-issue-and-merge-request-lists), -the results, or select a merge request to begin a review. +### Filter merge requests by reviewer + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/47605) in GitLab 13.7. + +To filter review requested merge requests for a specific individual, you can type (or select from +the dropdown list) **Reviewer** and select the user. + +### Filter merge requests by environment or deployment date + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/44041) in GitLab 13.6. + +To filter merge requests by deployment data, such as the environment or a date, +you can type (or select from the dropdown list) the following: + +- Environment +- Deployed-before +- Deployed-after + +NOTE: +Projects using a [fast-forward merge method](methods/index.md#fast-forward-merge) +do not return results, as this method does not create a merge commit. + +When filtering by an environment, a dropdown list presents all environments that +you can choose from: + + + +When filtering by `Deployed-before` or `Deployed-after`, the date refers to when +the deployment to an environment (triggered by the merge commit) completed successfully. +You must enter the deploy date manually. Deploy dates +use the format `YYYY-MM-DD`, and must be quoted if you wish to specify +both a date and time (`"YYYY-MM-DD HH:MM"`): + + ## Add changes to a merge request @@ -84,8 +171,7 @@ a merge request, or: 1. Select **Edit**. 1. Search for the user you want to assign, and select the user. -The merge request is added to the user's -[assigned merge request list](../../search/index.md#search-issues-and-merge-requests). +The merge request is added to the user's assigned merge request list. ### Assign multiple users **(PREMIUM)** @@ -136,6 +222,35 @@ To delete a merge request: 1. Go to the merge request you want to delete, and select **Edit**. 1. Scroll to the bottom of the page, and select **Delete merge request**. +### Update merge requests when target branch merges **(FREE SELF)** + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/320902) in GitLab 13.9. +> - [Disabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/320902) in GitLab 13.9. +> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/320895) GitLab 13.10. + +Merge requests are often chained together, with one merge request depending on +the code added or changed in another merge request. To support keeping individual +merge requests small, GitLab can update up to four open merge requests when their +target branch merges into `main`. For example: + +- **Merge request 1**: merge `feature-alpha` into `main`. +- **Merge request 2**: merge `feature-beta` into `feature-alpha`. + +If these merge requests are open at the same time, and merge request 1 (`feature-alpha`) +merges into `main`, GitLab updates the destination of merge request 2 from `feature-alpha` +to `main`. + +Merge requests with interconnected content updates are usually handled in one of these ways: + +- Merge request 1 is merged into `main` first. Merge request 2 is then + retargeted to `main`. +- Merge request 2 is merged into `feature-alpha`. The updated merge request 1, which + now contains the contents of `feature-alpha` and `feature-beta`, is merged into `main`. + +This feature works only when a merge request is merged. Selecting **Remove source branch** +after merging does not retarget open merge requests. This improvement is +[proposed as a follow-up](https://gitlab.com/gitlab-org/gitlab/-/issues/321559). + ## Request attention to a merge request > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/343528) in GitLab 14.10 [with a flag](../../../administration/feature_flags.md) named `mr_attention_requests`. Disabled by default. @@ -190,7 +305,7 @@ For a software developer working in a team: 1. You checkout a new branch, and submit your changes through a merge request. 1. You gather feedback from your team. 1. You work on the implementation optimizing code with [Code Quality reports](code_quality.md). -1. You verify your changes with [Unit test reports](../../../ci/unit_test_reports.md) in GitLab CI/CD. +1. You verify your changes with [Unit test reports](../../../ci/testing/unit_test_reports.md) in GitLab CI/CD. 1. You avoid using dependencies whose license is not compatible with your project with [License Compliance reports](../../compliance/license_compliance/index.md). 1. You request the [approval](approvals/index.md) from your manager. 1. Your manager: @@ -215,7 +330,7 @@ For a web developer writing a webpage for your company's website: - [Create a merge request](creating_merge_requests.md) - [Review a merge request](reviews/index.md) - [Authorization for merge requests](authorization_for_merge_requests.md) -- [Testing and reports](testing_and_reports_in_merge_requests.md) +- [Testing and reports](../../../ci/testing/index.md) - [GitLab keyboard shortcuts](../../shortcuts.md) - [Comments and threads](../../discussions/index.md) - [Suggest code changes](reviews/suggestions.md) diff --git a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md index ac1c61f2e72..9182cf11566 100644 --- a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md +++ b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md @@ -16,7 +16,7 @@ finish and remember to merge the request manually. ## How it works -When you click "Merge When Pipeline Succeeds", the status of the merge +When you select "Merge When Pipeline Succeeds", the status of the merge request is updated to show the impending merge. If you can't wait for the pipeline to succeed, you can choose **Merge immediately** in the dropdown menu on the right of the main button. @@ -56,10 +56,11 @@ As a result, [disabling GitLab CI/CD pipelines](../../../ci/enable_or_disable_ci does not disable this feature, as it is possible to use pipelines from external CI providers with this feature. To enable it, you must: -1. Navigate to your project's **Settings > General** page. -1. Expand the **Merge requests** section. -1. In the **Merge checks** subsection, select the **Pipelines must succeed** checkbox. -1. Press **Save** for the changes to take effect. +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **Settings > General**. +1. Expand **Merge requests**. +1. Under **Merge checks**, select the **Pipelines must succeed** checkbox. +1. Select **Save**. This setting also prevents merge requests from being merged if there is no pipeline. You should be careful to configure CI/CD so that pipelines run for every merge request. @@ -104,11 +105,13 @@ for details on avoiding two pipelines for a single merge request. When the **Pipelines must succeed** checkbox is checked, [skipped pipelines](../../../ci/pipelines/index.md#skip-a-pipeline) prevent merge requests from being merged. To change this behavior: -1. Navigate to your project's **Settings > General** page. -1. Expand the **Merge requests** section. -1. In the **Merge checks** subsection, ensure **Pipelines must succeed** is checked. -1. In the **Merge checks** subsection, select the **Skipped pipelines are considered successful** checkbox. -1. Press **Save** for the changes to take effect. +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **Settings > General**. +1. Expand **Merge requests**. +1. Under **Merge checks**: + - Ensure **Pipelines must succeed** is selected. + - Select the **Skipped pipelines are considered successful** checkbox. +1. Select **Save**. ## From the command line diff --git a/doc/user/project/merge_requests/methods/index.md b/doc/user/project/merge_requests/methods/index.md index adfa5288f81..d3221162cfd 100644 --- a/doc/user/project/merge_requests/methods/index.md +++ b/doc/user/project/merge_requests/methods/index.md @@ -77,7 +77,7 @@ When a fast-forward merge is not possible, the user is given the option to rebas NOTE: Projects using the fast-forward merge strategy can't filter merge requests -[by deployment date](../../../search/index.md#filtering-merge-requests-by-environment-or-deployment-date), +[by deployment date](../index.md#filter-merge-requests-by-environment-or-deployment-date), because no merge commit is created. When you visit the merge request page with `Fast-forward merge` @@ -87,8 +87,6 @@ method selected, you can accept it **only if a fast-forward merge is possible**. ## Rebasing in (semi-)linear merge methods -> Rebasing without running a CI/CD pipeline [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/118825) in GitLab 14.7. - In these merge methods, you can merge only when your source branch is up-to-date with the target branch: - Merge commit with semi-linear history. @@ -96,11 +94,7 @@ In these merge methods, you can merge only when your source branch is up-to-date If a fast-forward merge is not possible but a conflict-free rebase is possible, GitLab offers you the [`/rebase` quick action](../../../../topics/git/git_rebase.md#rebase-from-the-gitlab-ui), -and the ability to **Rebase** from the user interface: - - - -In [GitLab 14.7](https://gitlab.com/gitlab-org/gitlab/-/issues/118825) and later, you can also rebase without running a CI/CD pipeline. +and the ability to select **Rebase** from the user interface. If the target branch is ahead of the source branch and a conflict-free rebase is not possible, you must rebase the source branch locally before you can do a fast-forward merge. @@ -110,6 +104,23 @@ not possible, you must rebase the source branch locally before you can do a fast Rebasing may be required before squashing, even though squashing can itself be considered equivalent to rebasing. +### Rebase without CI/CD pipeline + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/118825) in GitLab 14.7 [with a flag](../../../../administration/feature_flags.md) named `rebase_without_ci_ui`. Disabled by default. + +FLAG: +On GitLab.com and self-managed GitLab, by default this feature is not available. To make it available, +ask an administrator to [enable the feature flag](../../../../administration/feature_flags.md) named `rebase_without_ci_ui`. +The feature is not ready for production use. + +To rebase a merge request's branch without triggering a CI/CD pipeline, select +**Rebase without pipeline** from the merge request reports section. +This option is available when fast-forward merge is not possible but a conflict-free +rebase is possible. + +Rebasing without a CI/CD pipeline saves resources in projects with a semi-linear +workflow that requires frequent rebases. + ## Related topics - [Commits history](../commits.md) diff --git a/doc/user/project/merge_requests/revert_changes.md b/doc/user/project/merge_requests/revert_changes.md index 7b4a41f9339..8f433c13887 100644 --- a/doc/user/project/merge_requests/revert_changes.md +++ b/doc/user/project/merge_requests/revert_changes.md @@ -22,7 +22,7 @@ to revert the changes introduced by that merge request.  -After you click that button, a modal appears where you can choose to +After you select that button, a modal appears where you can choose to revert the changes directly into the selected branch or you can opt to create a new merge request with the revert changes. diff --git a/doc/user/project/merge_requests/reviews/index.md b/doc/user/project/merge_requests/reviews/index.md index eb5a54e6119..8f77ce90436 100644 --- a/doc/user/project/merge_requests/reviews/index.md +++ b/doc/user/project/merge_requests/reviews/index.md @@ -89,7 +89,7 @@ comment itself. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/8225) in GitLab 13.10. -If you have a review in progress, you will be presented with the option to **Add to review**: +If you have a review in progress, you are presented with the option to **Add to review**:  @@ -123,9 +123,9 @@ Use [attention requests](../index.md#request-attention-to-a-merge-request) inste After a reviewer completes their [merge request reviews](../../../discussions/index.md), the author of the merge request can request a new review from the reviewer: -1. If the right sidebar in the merge request is collapsed, click the +1. If the right sidebar in the merge request is collapsed, select the **{chevron-double-lg-left}** **Expand Sidebar** icon to expand it. -1. In the **Reviewers** section, click the **Re-request a review** icon (**{redo}**) +1. In the **Reviewers** section, select the **Re-request a review** icon (**{redo}**) next to the reviewer's name. GitLab creates a new [to-do item](../../../todos.md) for the reviewer, and sends @@ -168,11 +168,11 @@ When bulk-editing merge requests in a project, you can edit the following attrib To update multiple project merge requests at the same time: 1. In a project, go to **Merge requests**. -1. Click **Edit merge requests**. A sidebar on the right-hand side of your screen appears with +1. Select **Edit merge requests**. A sidebar on the right-hand side of your screen appears with editable fields. 1. Select the checkboxes next to each merge request you want to edit. 1. Select the appropriate fields and their values from the sidebar. -1. Click **Update all**. +1. Select **Update all**. ## Bulk edit merge requests at the group level **(PREMIUM)** @@ -188,11 +188,11 @@ When bulk editing merge requests in a group, you can edit the following attribut To update multiple group merge requests at the same time: 1. In a group, go to **Merge requests**. -1. Click **Edit merge requests**. A sidebar on the right-hand side of your screen appears with +1. Select **Edit merge requests**. A sidebar on the right-hand side of your screen appears with editable fields. 1. Select the checkboxes next to each merge request you want to edit. 1. Select the appropriate fields and their values from the sidebar. -1. Click **Update all**. +1. Select **Update all**. ## Associated features diff --git a/doc/user/project/merge_requests/reviews/suggestions.md b/doc/user/project/merge_requests/reviews/suggestions.md index 8e6794bcfa7..7360b57103b 100644 --- a/doc/user/project/merge_requests/reviews/suggestions.md +++ b/doc/user/project/merge_requests/reviews/suggestions.md @@ -82,9 +82,13 @@ in four backticks instead of three: GitLab uses a default commit message when applying suggestions: `Apply %{suggestions_count} suggestion(s) to %{files_count} file(s)` +<!-- vale gitlab.BadPlurals = NO --> + For example, consider that a user applied 3 suggestions to 2 different files, the default commit message is: **Apply 3 suggestion(s) to 2 file(s)** +<!-- vale gitlab.BadPlurals = YES --> + These commit messages can be customized to follow any guidelines you might have. To do so, expand the **Merge requests** tab within your project's **General** settings and change the **Merge suggestions** text: diff --git a/doc/user/project/merge_requests/test_coverage_visualization.md b/doc/user/project/merge_requests/test_coverage_visualization.md index 85b5bbea284..fcbd732f8ee 100644 --- a/doc/user/project/merge_requests/test_coverage_visualization.md +++ b/doc/user/project/merge_requests/test_coverage_visualization.md @@ -68,11 +68,37 @@ A single Cobertura XML file can be no more than 10MiB. For large projects, split smaller files. See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/328772) for more details. When submitting many files, it can take a few minutes for coverage to show on a merge request. +The visualization only displays after the pipeline is complete. If the pipeline has +a [blocking manual job](../../../ci/jobs/job_control.md#types-of-manual-jobs), the +pipeline waits for the manual job before continuing and is not considered complete. +The visualization cannot be displayed if the blocking manual job did not run. + ### Artifact expiration By default, the [pipeline artifact](../../../ci/pipelines/pipeline_artifacts.md#storage) used to draw the visualization on the merge request expires **one week** after creation. +### Coverage report from child pipeline + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/363301) in GitLab 15.1 [with a flag](../../../administration/feature_flags.md). Disabled by default. + +FLAG: +On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `ci_child_pipeline_coverage_reports`. +On GitLab.com, this feature is not available. +The feature is not ready for production use. + +If the test coverage is created in jobs that are in a child pipeline, the parent pipeline must use +`strategy: depend`. + +```yaml +child_test_pipeline: + trigger: + include: + - local: path/to/child_pipeline.yml + - template: Security/SAST.gitlab-ci.yml + strategy: depend +``` + ### Automatic class path correction > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217664) in GitLab 13.8. @@ -255,7 +281,7 @@ run tests: - coverage run -m pytest - coverage report - coverage xml - coverage: '/TOTAL.*\s([.\d]+)%/' + coverage: '/(?i)total.*? (100(?:\.0+)?\%|[1-9]?\d(?:\.\d+)?\%)$/' artifacts: reports: coverage_report: @@ -389,3 +415,27 @@ run tests: coverage_format: cobertura path: coverage/coverage.xml ``` + +## Troubleshooting + +### Test coverage visualization not displayed + +If the test coverage visualization is not displayed in the diff view, you can check +the coverage report itself and verify that: + +- The file you are viewing in the diff view is mentioned in the coverage report. +- The `source` and `filename` nodes in the report follows the [expected structure](#automatic-class-path-correction) + to match the files in your repository. + +Report artifacts are not downloadable by default. If you want the report to be downloadable +from the job details page, add your coverage report to the artifact `paths`: + +```yaml +artifacts: + paths: + - coverage/cobertura-coverage.xml + reports: + coverage_report: + coverage_format: cobertura + path: coverage/cobertura-coverage.xml +``` diff --git a/doc/user/project/merge_requests/testing_and_reports_in_merge_requests.md b/doc/user/project/merge_requests/testing_and_reports_in_merge_requests.md index 741ac325cca..6c0086bc429 100644 --- a/doc/user/project/merge_requests/testing_and_reports_in_merge_requests.md +++ b/doc/user/project/merge_requests/testing_and_reports_in_merge_requests.md @@ -1,39 +1,11 @@ --- -stage: Verify -group: Pipeline Insights -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments -description: "Test your code and display reports in merge requests" +redirect_to: '../../../ci/testing/index.md' +remove_date: '2022-08-31' --- -# Tests and reports in merge requests **(FREE)** +This document was moved to [another location](../../../ci/testing/index.md). -GitLab has the ability to test the changes included in a feature branch and display reports -or link to useful information directly from merge requests: - -| Feature | Description | -|----------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| [Accessibility Testing](accessibility_testing.md) | Automatically report A11y violations for changed pages in merge requests. | -| [Browser Performance Testing](browser_performance_testing.md) | Quickly determine the browser performance impact of pending code changes. | -| [Load Performance Testing](load_performance_testing.md) | Quickly determine the server performance impact of pending code changes. | -| [Code Quality](code_quality.md) | Analyze your source code quality using the [Code Climate](https://codeclimate.com/) analyzer and show the Code Climate report right in the merge request widget area. | -| [Display arbitrary job artifacts](../../../ci/yaml/index.md#artifactsexpose_as) | Configure CI pipelines with the `artifacts:expose_as` parameter to directly link to selected [artifacts](../../../ci/pipelines/job_artifacts.md) in merge requests. | -| [GitLab CI/CD](../../../ci/index.md) | Build, test, and deploy your code in a per-branch basis with built-in CI/CD. | -| [Unit test reports](../../../ci/unit_test_reports.md) | Configure your CI jobs to use Unit test reports, and let GitLab display a report on the merge request so that it's easier and faster to identify the failure without having to check the entire job log. | -| [License Compliance](../../compliance/license_compliance/index.md) | Manage the licenses of your dependencies. | -| [Metrics Reports](../../../ci/metrics_reports.md) | Display the Metrics Report on the merge request so that it's fast and easy to identify changes to important metrics. | -| [Multi-Project pipelines](../../../ci/pipelines/multi_project_pipelines.md) | When you set up GitLab CI/CD across multiple projects, you can visualize the entire pipeline, including all cross-project interdependencies. | -| [Merge request pipelines](../../../ci/pipelines/merge_request_pipelines.md) | Customize a specific pipeline structure for merge requests in order to speed the cycle up by running only important jobs. | -| [Pipeline Graphs](../../../ci/pipelines/index.md#visualize-pipelines) | View the status of pipelines within the merge request, including the deployment process. | -| [Test Coverage visualization](test_coverage_visualization.md) | See test coverage results for merge requests, within the file diff. | - -## Security Reports **(ULTIMATE)** - -In addition to the reports listed above, GitLab can do many types of [Security reports](../../application_security/index.md), -generated by scanning and reporting any vulnerabilities found in your project: - -| Feature | Description | -|-----------------------------------------------------------------------------------------|------------------------------------------------------------------| -| [Container Scanning](../../application_security/container_scanning/index.md) | Analyze your Docker images for known vulnerabilities. | -| [Dynamic Application Security Testing (DAST)](../../application_security/dast/index.md) | Analyze your running web applications for known vulnerabilities. | -| [Dependency Scanning](../../application_security/dependency_scanning/index.md) | Analyze your dependencies for known vulnerabilities. | -| [Static Application Security Testing (SAST)](../../application_security/sast/index.md) | Analyze your source code for known vulnerabilities. | +<!-- This redirect file can be deleted after <2022-08-31>. --> +<!-- Redirects that point to other docs in the same project expire in three months. --> +<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. --> +<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html --> |
