diff options
Diffstat (limited to 'doc/user/project/merge_requests')
31 files changed, 273 insertions, 216 deletions
diff --git a/doc/user/project/merge_requests/allow_collaboration.md b/doc/user/project/merge_requests/allow_collaboration.md index 7aa7673366d..5917d67c398 100644 --- a/doc/user/project/merge_requests/allow_collaboration.md +++ b/doc/user/project/merge_requests/allow_collaboration.md @@ -1,6 +1,6 @@ --- stage: Create -group: Source Code +group: Code Review 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 type: reference, howto --- @@ -18,15 +18,15 @@ This feature is available for merge requests across forked projects that are publicly accessible. When enabled for a merge request, members with merge access to the target -branch of the project will be granted write permissions to the source branch +branch of the project is granted write permissions to the source branch of the merge request. ## Enabling commit edits from upstream members In [GitLab 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/23308), this setting is enabled by default. It can be changed by users with Developer -permissions to the source project. Once enabled, upstream members will also be -able to retry the pipelines and jobs of the merge request: +permissions to the source project. Once enabled, upstream members can +retry the pipelines and jobs of the merge request: 1. While creating or editing a merge request, select the checkbox **Allow commits from members who can merge to the target branch**. @@ -64,7 +64,7 @@ Here's how the process would look like: git checkout -b thedude-awesome-project-update-docs FETCH_HEAD ``` - This will fetch the branch of the forked project and then create a local branch + This fetches the branch of the forked project and then create a local branch based off the fetched branch. 1. Make any changes you want and commit. @@ -74,7 +74,7 @@ Here's how the process would look like: git push git@gitlab.com:thedude/awesome-project.git thedude-awesome-project-update-docs:update-docs ``` - Note the colon (`:`) between the two branches. The above command will push the + Note the colon (`:`) between the two branches. The above command pushes the local branch `thedude-awesome-project-update-docs` to the `update-docs` branch of the `git@gitlab.com:thedude/awesome-project.git` repository. diff --git a/doc/user/project/merge_requests/authorization_for_merge_requests.md b/doc/user/project/merge_requests/authorization_for_merge_requests.md index 36481ac0133..aa43d34cdd9 100644 --- a/doc/user/project/merge_requests/authorization_for_merge_requests.md +++ b/doc/user/project/merge_requests/authorization_for_merge_requests.md @@ -1,6 +1,6 @@ --- stage: Create -group: Source Code +group: Code Review 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 type: concepts --- diff --git a/doc/user/project/merge_requests/browser_performance_testing.md b/doc/user/project/merge_requests/browser_performance_testing.md index 6fa2340c7a4..7a869ed071a 100644 --- a/doc/user/project/merge_requests/browser_performance_testing.md +++ b/doc/user/project/merge_requests/browser_performance_testing.md @@ -13,6 +13,9 @@ If your application offers a web interface and you're using [GitLab CI/CD](../../../ci/README.md), you can quickly determine the rendering performance impact of pending code changes in the browser. +NOTE: +You can automate this feature in your applications by using [Auto DevOps](../../../topics/autodevops/index.md). + ## Overview GitLab uses [Sitespeed.io](https://www.sitespeed.io), a free and open source @@ -90,7 +93,7 @@ that you can later download and analyze. This implementation always takes the la Browser Performance artifact available. If [GitLab Pages](../pages/index.md) is enabled, you can view the report directly in your browser. -You can also customize the jobs with environment variables: +You can also customize the jobs with CI/CD variables: - `SITESPEED_IMAGE`: Configure the Docker image to use for the job (default `sitespeedio/sitespeed.io`), but not the image version. - `SITESPEED_VERSION`: Configure the version of the Docker image to use for the job (default `14.1.0`). @@ -115,7 +118,7 @@ performance: > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27599) in GitLab 13.0. You can configure the sensitivity of degradation alerts to avoid getting alerts for minor drops in metrics. -This is done by setting the `DEGRADATION_THRESHOLD` variable. In the example below, the alert only shows up +This is done by setting the `DEGRADATION_THRESHOLD` CI/CD variable. In the example below, the alert only shows up if the `Total Score` metric degrades by 5 points or more: ```yaml @@ -186,7 +189,7 @@ GitLab version: - In GitLab 12.4 [a job template was made available](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Verify/Browser-Performance.gitlab-ci.yml). - In 13.2 the feature was renamed from `Performance` to `Browser Performance` with -additional template variables. The job name in the template is still `performance` +additional template CI/CD variables. The job name in the template is still `performance` for compatibility reasons, but may be renamed to match in a future iteration. - For 11.5 to 12.3 no template is available and the job has to be defined manually as follows: diff --git a/doc/user/project/merge_requests/code_quality.md b/doc/user/project/merge_requests/code_quality.md index 55dc0bcc41a..42c2547a618 100644 --- a/doc/user/project/merge_requests/code_quality.md +++ b/doc/user/project/merge_requests/code_quality.md @@ -22,8 +22,7 @@ Code Quality: [GitLab Code Quality](https://gitlab.com/gitlab-org/ci-cd/codequality) project using [default Code Climate configurations](https://gitlab.com/gitlab-org/ci-cd/codequality/-/tree/master/codeclimate_defaults). - Can make use of a [template](#example-configuration). -- Is available with [Auto - DevOps](../../../topics/autodevops/stages.md#auto-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). ## Code Quality Widget @@ -90,7 +89,7 @@ scans your source code for code quality issues. The report is saved as a that you can later download and analyze. It's also possible to override the URL to the Code Quality image by -setting the `CODE_QUALITY_IMAGE` variable. This is particularly useful if you want +setting the `CODE_QUALITY_IMAGE` CI/CD variable. This is particularly useful if you want to lock in a specific version of Code Quality, or use a fork of it: ```yaml @@ -236,12 +235,12 @@ was chosen as an operational decision by the runner team, instead of exposing `d ### Disabling the code quality job -The `code_quality` job doesn't run if the `$CODE_QUALITY_DISABLED` environment -variable is present. Please refer to the environment variables [documentation](../../../ci/variables/README.md) +The `code_quality` job doesn't run if the `$CODE_QUALITY_DISABLED` CI/CD variable +is present. Please refer to the CI/CD variables [documentation](../../../ci/variables/README.md) to learn more about how to define one. -To disable the `code_quality` job, add `CODE_QUALITY_DISABLED` as a custom environment -variable. This can be done: +To disable the `code_quality` job, add `CODE_QUALITY_DISABLED` as a custom CI/CD variable. +This can be done: - For the whole project, [in the project settings](../../../ci/variables/README.md#create-a-custom-variable-in-the-ui) or [CI/CD configuration](../../../ci/variables/README.md#create-a-custom-variable-in-the-ui). @@ -268,7 +267,7 @@ code_quality: - if: '$CI_COMMIT_TAG || $CI_COMMIT_BRANCH' ``` -If you are using merge request pipelines, your `rules` (or [`workflow: rules`](../../../ci/yaml/README.md#workflowrules)) +If you are using merge request pipelines, your `rules` (or [`workflow: rules`](../../../ci/yaml/README.md#workflow)) might look like this example: ```yaml @@ -365,7 +364,7 @@ After the Code Quality job completes: In [GitLab 13.6 and later](https://gitlab.com/gitlab-org/ci-cd/codequality/-/issues/10), it is possible to generate an HTML report file by setting the `REPORT_FORMAT` -variable to `html`. This is useful if you just want to view the report in a more +CI/CD variable to `html`. This is useful if you just want to view the report in a more human-readable format or to publish this artifact on GitLab Pages for even easier reviewing. @@ -509,6 +508,7 @@ This can be due to multiple reasons: nothing is displayed. - The [`artifacts:expire_in`](../../../ci/yaml/README.md#artifactsexpire_in) CI/CD setting can cause the Code Quality artifact(s) to expire faster than desired. +- The widgets use the pipeline of the latest commit to the target branch. If commits are made to the default branch that do not run the code quality job, this may cause the Merge Request widget to have no base report for comparison. - If you use the [`REPORT_STDOUT` environment variable](https://gitlab.com/gitlab-org/ci-cd/codequality#environment-variables), no report file is generated and nothing displays in the merge request. - Large `gl-code-quality-report.json` files (esp. >10 MB) are [known to prevent the report from being displayed](https://gitlab.com/gitlab-org/gitlab/-/issues/2737). As a work-around, try removing [properties](https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md#data-types) diff --git a/doc/user/project/merge_requests/creating_merge_requests.md b/doc/user/project/merge_requests/creating_merge_requests.md index 5cfedc6c9f1..58e80504212 100644 --- a/doc/user/project/merge_requests/creating_merge_requests.md +++ b/doc/user/project/merge_requests/creating_merge_requests.md @@ -1,6 +1,6 @@ --- stage: Create -group: Source Code +group: Code Review 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 type: howto description: "How to create Merge Requests in GitLab." @@ -30,11 +30,16 @@ button and start a merge request from there. ## New Merge Request page -On the **New Merge Request** page, start by filling in the title -and description for the merge request. If there are already -commits on the branch, the title is prefilled with the first -line of the first commit message, and the description is -prefilled with any additional lines in the commit message. +On the **New Merge Request** page, start by filling in the title and description +for the merge request. If commits already exist on the branch, GitLab suggests a +merge request title for you: + +- **If a multi-line commit message exists**: GitLab adds the first line of the + first multi-line commit message as the title. Any additional lines in that + commit message become the description. +- **If no multi-line commit message exists**: GitLab adds the branch name as the + title, and leaves the description blank. + The title is the only field that is mandatory in all cases. From there, you can fill it with information (title, description, diff --git a/doc/user/project/merge_requests/drafts.md b/doc/user/project/merge_requests/drafts.md new file mode 100644 index 00000000000..a030961e219 --- /dev/null +++ b/doc/user/project/merge_requests/drafts.md @@ -0,0 +1,99 @@ +--- +stage: Create +group: Code Review +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 +type: reference, concepts +disqus_identifier: 'https://docs.gitlab.com/ee/user/project/merge_requests/work_in_progress_merge_requests.html' +--- + +# Draft merge requests **(FREE)** + +If a merge request isn't ready to merge, potentially because of continued development +or open threads, you can prevent it from being accepted before you +[mark it as ready](#mark-merge-requests-as-ready). Flag it as a draft to disable +the **Merge** button until you remove the **Draft** flag: + + + +## Mark merge requests as drafts + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32692) in GitLab 13.2, Work-In-Progress (WIP) merge requests were renamed to **Draft**. Support for using **WIP** is scheduled for removal in GitLab 14.0. +> - **Mark as draft** and **Mark as ready** buttons [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/227421) in GitLab 13.5. + +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**. +- **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:** + 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. +- **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 + merge request as ready. + +WARNING: +Adding `WIP:` to the start of the merge request's title still marks a merge request +as a draft. This feature is scheduled for removal in GitLab 14.0. Use `Draft:` instead. + +## Mark merge requests as ready + +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**. + Users with [Developer or greater permissions](../../permissions.md) + can also scroll to the bottom of the merge request description and click **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** + 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 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 [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 +[merge request participants and watchers](../../profile/notifications.md#notifications-on-issues-merge-requests-and-epics). + +## Include or exclude drafts when searching + +When viewing or searching in your project's merge requests list, you can include or exclude +draft merge requests: + +1. In your project, select **Merge Requests** from the left sidebar. +1. In the navigation bar, click **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 + enter the word `draft`. +1. Select `=`. +1. Select **Yes** to include drafts, or **No** to exclude, and press **Return** + to update the list of merge requests: + +  + +## Pipelines for drafts + +When the [pipelines for merged results](../../../ci/merge_request_pipelines/pipelines_for_merged_results/index.md) +feature is enabled, draft merge requests run +[merge request pipelines](../../../ci/merge_request_pipelines/index.md) only. + +To run pipelines for merged results, you must +[mark the merge request as ready](#mark-merge-requests-as-ready). + +<!-- ## Troubleshooting + +Include any troubleshooting steps that you can foresee. If you know beforehand what issues +one might have when setting this up, or when something is changed, or on upgrading, it's +important to describe those, too. Think of things that may go wrong and include them here. +This is important to minimize requests for support, and to avoid doc comments with +questions that you know someone might ask. + +Each scenario can be a third-level heading, e.g. `### Getting error message X`. +If you have none to add when creating a doc, leave this section in place +but commented out to help encourage others to add to it in the future. --> diff --git a/doc/user/project/merge_requests/fast_forward_merge.md b/doc/user/project/merge_requests/fast_forward_merge.md index c4a34f9c65c..b1e8d761f5c 100644 --- a/doc/user/project/merge_requests/fast_forward_merge.md +++ b/doc/user/project/merge_requests/fast_forward_merge.md @@ -17,7 +17,7 @@ to accept merge requests without creating merge commits. When the fast-forward merge ([`--ff-only`](https://git-scm.com/docs/git-merge#git-merge---ff-only)) setting -is enabled, no merge commits will be created and all merges are fast-forwarded, +is enabled, no merge commits are created and all merges are fast-forwarded, which means that merging is only allowed if the branch can be fast-forwarded. When a fast-forward merge is not possible, the user is given the option to rebase. @@ -28,19 +28,19 @@ When a fast-forward merge is not possible, the user is given the option to rebas 1. Select the **Fast-forward merge** option 1. Hit **Save changes** for the changes to take effect -Now, when you visit the merge request page, you will be able to accept it +Now, when you visit the merge request page, you can accept it **only if a fast-forward merge is possible**.  If a fast-forward merge is not possible but a conflict free rebase is possible, -a rebase button will be offered. +a rebase button is offered.  If the target branch is ahead of the source branch and a conflict free rebase is not possible, you need to rebase the -source branch locally before you will be able to do a fast-forward merge. +source branch locally before you can do a fast-forward merge.  diff --git a/doc/user/project/merge_requests/getting_started.md b/doc/user/project/merge_requests/getting_started.md index b1a57d9c3e6..f25228729cf 100644 --- a/doc/user/project/merge_requests/getting_started.md +++ b/doc/user/project/merge_requests/getting_started.md @@ -1,6 +1,6 @@ --- stage: Create -group: Source Code +group: Code Review 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 type: index, reference description: "Getting started with Merge Requests." @@ -60,7 +60,7 @@ request's page at the top-right side: - [Close issues automatically](#merge-requests-to-close-issues) when they are merged. - Enable the [delete source branch when merge request is accepted](#deleting-the-source-branch) option to keep your repository clean. - Enable the [squash commits when merge request is accepted](squash_and_merge.md) option to combine all the commits into one before merging, thus keep a clean commit history in your repository. -- Set the merge request as a [**Draft**](work_in_progress_merge_requests.md) to avoid accidental merges before it is ready. +- Set the merge request as a [**Draft**](drafts.md) to avoid accidental merges before it is ready. After you have created the merge request, you can also: @@ -84,7 +84,7 @@ See also other [features associated to merge requests](reviewing_and_managing_me Choose an assignee to designate someone as the person responsible for the first [review of the merge request](reviewing_and_managing_merge_requests.md). Open the drop down box to search for the user you wish to assign, -and the merge request will be added to their +and the merge request is added to their [assigned merge request list](../../search/index.md#issues-and-merge-requests). #### Multiple assignees **(PREMIUM)** @@ -110,7 +110,7 @@ dropdown menu. It is also possible to manage multiple assignees: - When creating a merge request. -- Using [quick actions](../quick_actions.md#quick-actions-for-issues-merge-requests-and-epics). +- Using [quick actions](../quick_actions.md#issues-merge-requests-and-epics). ### Reviewer @@ -122,17 +122,19 @@ Requesting a code review is an important part of contributing code. However, dec your code and asking for a review are no easy tasks. Using the "assignee" field for both authors and reviewers makes it hard for others to determine who's doing what on a merge request. -GitLab Merge Request Reviewers easily allow authors to request a review as well as see the status of the -review. By selecting one or more users from the **Reviewers** field in the merge request's right-hand -sidebar, the assigned reviewers will receive a notification of the request to review the merge request. +The Merge Request Reviewers feature enables you to request a review of your work, and +see the status of the review. Reviewers help distinguish the roles of the users +involved in the merge request. In comparison to an **Assignee**, who is directly +responsible for creating or merging a merge request, a **Reviewer** is a team member +who may only be involved in one aspect of the merge request, such as a peer review. -This makes it easy to determine the relevant roles for the users involved in the merge request, as well as formally requesting a review from a peer. - -To request it, open the **Reviewers** drop-down box to search for the user you wish to get a review from. +To request a review of a merge request, expand the **Reviewers** select box in +the right-hand sidebar. Search for the users you want to request a review from. +When selected, GitLab creates a [to-do list item](../../todos.md) for each reviewer. #### Approval Rule information for Reviewers **(PREMIUM)** -> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/233736) in GitLab 13.8. For this version only, GitLab administrators can opt to [enable it](#enable-or-disable-approval-rule-information). +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/233736) in GitLab 13.8. > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/293742) in GitLab 13.9. When editing the **Reviewers** field in a new or existing merge request, GitLab @@ -162,6 +164,13 @@ the author of the merge request can request a new review from the reviewer: GitLab creates a new [to-do item](../../todos.md) for the reviewer, and sends them a notification email. +#### Approval status + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292936) in GitLab 13.10. + +If a user in the reviewer list has approved the merge request, a green tick symbol is +shown to the right of their name. + ### Merge requests to close issues If the merge request is being created to resolve an issue, you can @@ -198,9 +207,9 @@ is set for deletion, the merge request widget displays the > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/320902) in GitLab 13.9. > - It's [deployed behind a feature flag](../../feature_flags.md), disabled by default. -> - It's disabled on GitLab.com. -> - It's not recommended for production use. -> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-branch-retargeting-on-merge). +> - [Became enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/320895) on GitLab 13.10. +> - It's recommended for production use. +> - To use it in GitLab self-managed instances, ask a GitLab administrator to [disable it](#enable-or-disable-branch-retargeting-on-merge). **(FREE SELF)** In specific circumstances, GitLab can retarget the destination branch of open merge request, if the destination branch merges while the merge request is @@ -221,6 +230,12 @@ GitLab retargets up to four merge requests when their target branch is merged in `master`, so you don't need to perform this operation manually. Merge requests from forks are not retargeted. +The feature today works only one a merge. Clicking the `Remove source branch` button +after the merge request was merged will not automatically retarget merge request. +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 @@ -231,33 +246,6 @@ forks are not retargeted. reviews are faster and your changes are less prone to errors. - Do not use capital letters nor special chars in branch names. -## Enable or disable Approval Rule information **(PREMIUM SELF)** - -> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/293742) in GitLab 13.9. - -Merge Request Reviewers is under development and ready for production use. -It is deployed behind a feature flag that is **enabled by default**. -[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md) -can opt to disable it. - -To enable it: - -```ruby -# For the instance -Feature.enable(:reviewer_approval_rules) -# For a single project -Feature.enable(:reviewer_approval_rules, Project.find(<project id>)) -``` - -To disable it: - -```ruby -# For the instance -Feature.disable(:reviewer_approval_rules) -# For a single project -Feature.disable(:reviewer_approval_rules, Project.find(<project id>)) -``` - ### Enable or disable branch retargeting on merge **(FREE SELF)** Automatically retargeting merge requests is under development but ready for production use. diff --git a/doc/user/project/merge_requests/img/comment-on-any-diff-line.png b/doc/user/project/merge_requests/img/comment-on-any-diff-line.png Binary files differdeleted file mode 100644 index cff5acb98ef..00000000000 --- a/doc/user/project/merge_requests/img/comment-on-any-diff-line.png +++ /dev/null diff --git a/doc/user/project/merge_requests/img/comment-on-any-diff-line_v13_10.png b/doc/user/project/merge_requests/img/comment-on-any-diff-line_v13_10.png Binary files differnew file mode 100644 index 00000000000..a31fea85be9 --- /dev/null +++ b/doc/user/project/merge_requests/img/comment-on-any-diff-line_v13_10.png diff --git a/doc/user/project/merge_requests/img/draft_blocked_merge_button_v13_10.png b/doc/user/project/merge_requests/img/draft_blocked_merge_button_v13_10.png Binary files differnew file mode 100644 index 00000000000..3bac9f7fee8 --- /dev/null +++ b/doc/user/project/merge_requests/img/draft_blocked_merge_button_v13_10.png diff --git a/doc/user/project/merge_requests/img/draft_blocked_merge_button_v13_2.png b/doc/user/project/merge_requests/img/draft_blocked_merge_button_v13_2.png Binary files differdeleted file mode 100644 index f7968772500..00000000000 --- a/doc/user/project/merge_requests/img/draft_blocked_merge_button_v13_2.png +++ /dev/null diff --git a/doc/user/project/merge_requests/img/filter_draft_merge_requests_v13_10.png b/doc/user/project/merge_requests/img/filter_draft_merge_requests_v13_10.png Binary files differnew file mode 100644 index 00000000000..4458df987d6 --- /dev/null +++ b/doc/user/project/merge_requests/img/filter_draft_merge_requests_v13_10.png diff --git a/doc/user/project/merge_requests/img/filter_wip_merge_requests.png b/doc/user/project/merge_requests/img/filter_wip_merge_requests.png Binary files differdeleted file mode 100644 index 0989b41e2a4..00000000000 --- a/doc/user/project/merge_requests/img/filter_wip_merge_requests.png +++ /dev/null diff --git a/doc/user/project/merge_requests/img/multiline-comment-highlighted.png b/doc/user/project/merge_requests/img/multiline-comment-highlighted.png Binary files differdeleted file mode 100644 index 1bdcc37e274..00000000000 --- a/doc/user/project/merge_requests/img/multiline-comment-highlighted.png +++ /dev/null diff --git a/doc/user/project/merge_requests/img/scoped_to_protected_branch_v12_8.png b/doc/user/project/merge_requests/img/scoped_to_protected_branch_v12_8.png Binary files differdeleted file mode 100644 index 9446ed66c38..00000000000 --- a/doc/user/project/merge_requests/img/scoped_to_protected_branch_v12_8.png +++ /dev/null diff --git a/doc/user/project/merge_requests/img/scoped_to_protected_branch_v13_10.png b/doc/user/project/merge_requests/img/scoped_to_protected_branch_v13_10.png Binary files differnew file mode 100644 index 00000000000..b1c2e147134 --- /dev/null +++ b/doc/user/project/merge_requests/img/scoped_to_protected_branch_v13_10.png diff --git a/doc/user/project/merge_requests/img/update_approval_rule_v13_10.png b/doc/user/project/merge_requests/img/update_approval_rule_v13_10.png Binary files differnew file mode 100644 index 00000000000..c0cc0db600c --- /dev/null +++ b/doc/user/project/merge_requests/img/update_approval_rule_v13_10.png diff --git a/doc/user/project/merge_requests/img/update_approval_rule_v13_4.png b/doc/user/project/merge_requests/img/update_approval_rule_v13_4.png Binary files differdeleted file mode 100644 index af713b48140..00000000000 --- a/doc/user/project/merge_requests/img/update_approval_rule_v13_4.png +++ /dev/null diff --git a/doc/user/project/merge_requests/index.md b/doc/user/project/merge_requests/index.md index 8ccf50e48b8..99e0193d496 100644 --- a/doc/user/project/merge_requests/index.md +++ b/doc/user/project/merge_requests/index.md @@ -1,16 +1,29 @@ --- stage: Create -group: Source Code +group: Code Review 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 type: index, reference --- # Merge requests **(FREE)** -A Merge Request (**MR**) is a _request_ to _merge_ one branch into another. +Whenever you need to merge one branch into another branch with GitLab, you +must create a merge request (MR). -Use merge requests to visualize and collaborate on proposed changes -to source code. +Using merge requests, you can visualize and collaborate on proposed changes to +source code. Merge requests display information about the proposed code changes, +including: + +- A description of the request. +- Code changes and inline code reviews. +- Information about CI/CD pipelines. +- A comment section for discussion threads. +- The list of commits. + +Based on your workflow, after review you can merge a merge request into its +target branch. + +To get started, read the [introduction to merge requests](getting_started.md). ## Use cases @@ -36,21 +49,9 @@ B. Consider you're a web developer writing a webpage for your company's website: 1. Your changes are previewed with [Review Apps](../../../ci/review_apps/index.md) 1. You request your web designers for their implementation 1. You request the [approval](merge_request_approvals.md) from your manager **(STARTER)** -1. Once approved, your merge request is [squashed and merged](squash_and_merge.md), and [deployed to staging with GitLab Pages](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/) +1. Once approved, your merge request is [squashed and merged](squash_and_merge.md), and [deployed to staging with GitLab Pages](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/) 1. Your production team [cherry picks](cherry_pick_changes.md) the merge commit into production -## Overview - -Merge requests (aka "MRs") display a great deal of information about the changes proposed. -The body of an MR contains its description, along with its widget (displaying information -about CI/CD pipelines, when present), followed by the discussion threads of the people -collaborating with that MR. - -MRs also contain navigation tabs from which you can see the discussion happening on the thread, -the list of commits, the list of pipelines and jobs, the code changes, and inline code reviews. - -To get started, read the [introduction to merge requests](getting_started.md). - ## Merge request navigation tabs at the top > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33813) in GitLab 12.6. This positioning is experimental. diff --git a/doc/user/project/merge_requests/load_performance_testing.md b/doc/user/project/merge_requests/load_performance_testing.md index 9154897d42d..e8062fadcfe 100644 --- a/doc/user/project/merge_requests/load_performance_testing.md +++ b/doc/user/project/merge_requests/load_performance_testing.md @@ -104,8 +104,8 @@ An example configuration workflow: 1. Set up GitLab Runner to run Docker containers, like the [Docker-in-Docker workflow](../../../ci/docker/using_docker_build.md#use-the-docker-executor-with-the-docker-image-docker-in-docker). -1. Configure the default Load Performance Testing CI job in your `.gitlab-ci.yml` file. - You need to include the template and configure it with variables: +1. Configure the default Load Performance Testing CI/CD job in your `.gitlab-ci.yml` file. + You need to include the template and configure it with CI/CD variables: ```yaml include: @@ -153,7 +153,7 @@ but it can be extended to work with [review apps](../../../ci/review_apps) or [dynamic environments](../../../ci/environments) with a few extra steps. The best approach is to capture the dynamic URL in a [`.env` file](https://docs.docker.com/compose/env-file/) -as a job artifact to be shared, then use a custom environment variable we've provided named `K6_DOCKER_OPTIONS` +as a job artifact to be shared, then use a custom CI/CD variable we've provided named `K6_DOCKER_OPTIONS` to configure the k6 Docker container to use the file. With this, k6 can then use any environment variables from the `.env` file in scripts using standard JavaScript, such as: ``http.get(`${__ENV.ENVIRONMENT_URL}`)``. diff --git a/doc/user/project/merge_requests/merge_request_approvals.md b/doc/user/project/merge_requests/merge_request_approvals.md index 1fcc09a9d8a..3d3e04842f8 100644 --- a/doc/user/project/merge_requests/merge_request_approvals.md +++ b/doc/user/project/merge_requests/merge_request_approvals.md @@ -79,7 +79,8 @@ An individual user can be added as an approver for a project if they are a membe - The project's immediate parent group. - A group that has access to the project via a [share](../members/share_project_with_groups.md). -A group of users can also be added as approvers. In the future, group approvers may be +A group of users can also be added as approvers, though they only count as approvers if +they have direct membership to the group. In the future, group approvers may be [restricted to only groups with share access to the project](https://gitlab.com/gitlab-org/gitlab/-/issues/2048). If a user is added as an individual approver and is also part of a group approver, @@ -138,17 +139,17 @@ to push or merge code to any branches. To enable this access: -1. [Create a new group](../../group/index.md#create-a-new-group), and then +1. [Create a new group](../../group/index.md#create-a-group), and then [add the user to the group](../../group/index.md#add-users-to-a-group), ensuring you select the Reporter role for the user. 1. [Share the project with your group](../members/share_project_with_groups.md#sharing-a-project-with-a-group-of-users), based on the Reporter role. 1. Navigate to your project's **Settings > General**, and in the **Merge request approvals** section, click **Expand**. -1. [Add the group](../../group/index.md#create-a-new-group) to the permission list - for the protected branch. +1. Select **Add approval rule** or **Update approval rule**. +1. [Add the group](../../group/index.md#create-a-group) to the permission list. - + #### Adding / editing a default approval rule @@ -239,7 +240,7 @@ the **Target branch** dropdown. Alternatively, you can select a very specific protected branch from the **Target branch** dropdown: - + To enable this configuration, see [Code Owner’s approvals for protected branches](../protected_branches.md#protected-branches-approval-by-code-owners). diff --git a/doc/user/project/merge_requests/merge_request_dependencies.md b/doc/user/project/merge_requests/merge_request_dependencies.md index 646d77391a3..2d7ba853258 100644 --- a/doc/user/project/merge_requests/merge_request_dependencies.md +++ b/doc/user/project/merge_requests/merge_request_dependencies.md @@ -1,6 +1,6 @@ --- stage: Create -group: Source Code +group: Code Review 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 type: reference, concepts --- @@ -40,8 +40,7 @@ require changes to `awesome-lib`, and so necessitate two merge requests. Merging the `awesome-project` merge request before the `awesome-lib` one would break the `master`branch. -The `awesome-project` merge request could be [marked as -**Draft**](work_in_progress_merge_requests.md), +The `awesome-project` merge request could be [marked as **Draft**](drafts.md), and the reason for the draft stated included in the comments. However, this requires the state of the `awesome-lib` merge request to be manually tracked, and doesn't scale well if the `awesome-project` merge request @@ -85,7 +84,7 @@ merge request widget:  Until all dependencies have, themselves, been merged, the **Merge** -button will be disabled for the dependent merge request. In +button is disabled for the dependent merge request. In particular, note that **closed merge requests** still prevent their dependents from being merged - it is impossible to automatically determine whether the dependency expressed by a closed merge request 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 d33a8e40aac..58f2c310375 100644 --- a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md +++ b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md @@ -1,6 +1,6 @@ --- stage: Create -group: Source Code +group: Code Review 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 type: reference, concepts --- @@ -94,7 +94,7 @@ merge-request-pipeline-job: ``` You should avoid configuration like this, and only use branch (`push`) pipelines -or merge request pipelines, when possible. See [`rules` documentation](../../../ci/yaml/README.md#prevent-duplicate-pipelines) +or merge request pipelines, when possible. See [`rules` documentation](../../../ci/yaml/README.md#avoid-duplicate-pipelines) for details on avoiding two pipelines for a single merge request. ### Skipped pipelines diff --git a/doc/user/project/merge_requests/resolve_conflicts.md b/doc/user/project/merge_requests/resolve_conflicts.md index a53b5032e1d..4d5d89d6508 100644 --- a/doc/user/project/merge_requests/resolve_conflicts.md +++ b/doc/user/project/merge_requests/resolve_conflicts.md @@ -1,6 +1,6 @@ --- stage: Create -group: Source Code +group: Code Review 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 type: reference, concepts --- diff --git a/doc/user/project/merge_requests/revert_changes.md b/doc/user/project/merge_requests/revert_changes.md index d5d0578c07c..a798f2c9b85 100644 --- a/doc/user/project/merge_requests/revert_changes.md +++ b/doc/user/project/merge_requests/revert_changes.md @@ -1,6 +1,6 @@ --- stage: Create -group: Source Code +group: Code Review 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 type: reference, concepts --- @@ -13,27 +13,26 @@ by clicking the **Revert** button in merge requests and commit details. ## Reverting a merge request NOTE: -The **Revert** button will only be available for merge requests +The **Revert** button is available only for merge requests created in GitLab 8.5 and later. However, you can still revert a merge request by reverting the merge commit from the list of Commits page. NOTE: -The **Revert** button will only be shown for projects that use the +The **Revert** button is shown only for projects that use the merge method "Merge Commit", which can be set under the project's **Settings > General > Merge request**. [Fast-forward commits](fast_forward_merge.md) -can not be reverted via the MR view. +can not be reverted by using the merge request view. -After the Merge Request has been merged, a **Revert** button will be available +After the merge request has been merged, use the **Revert** button to revert the changes introduced by that merge request. - + -After you click that button, a modal will appear where you can choose to +After you click 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. -After the merge request has been reverted, the **Revert** button will not be -available anymore. +After the merge request has been reverted, the **Revert** button is no longer available. ## Reverting a commit @@ -45,14 +44,13 @@ Similar to reverting a merge request, you can opt to revert the changes directly into the target branch or create a new merge request to revert the changes. -After the commit has been reverted, the **Revert** button will not be available -anymore. +After a commit is reverted, the **Revert** button is no longer available. -Please note that when reverting merge commits, the mainline will always be the -first parent. If you want to use a different mainline then you need to do that +When reverting merge commits, the mainline is always the +first parent. If you want to use a different mainline, you need to do that from the command line. -Here is a quick example to revert a merge commit using the second parent as the +Here's an example to revert a merge commit using the second parent as the mainline: ```shell diff --git a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md index 94f48fa544f..406a79217d0 100644 --- a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md +++ b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md @@ -1,6 +1,6 @@ --- stage: Create -group: Source Code +group: Code Review 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 type: index, reference --- @@ -187,27 +187,31 @@ Feature.disable(:local_file_reviews) > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/13950) in GitLab 11.5. In a merge request, you can leave comments in any part of the file being changed. -In the Merge Request Diff UI, click the **{comment}** **comment** icon in the gutter -to expand the diff lines and leave a comment, just as you would for a changed line. +In the Merge Request Diff UI, you can: - +- **Comment on a single line**: Click the **{comment}** **comment** icon in the + gutter to expand the diff lines and display a comment box. +- [**Comment on multiple lines**](#commenting-on-multiple-lines). ### Commenting on multiple lines > - [Introduced](https://gitlab.com/gitlab-org/ux-research/-/issues/870) in GitLab 13.2. +> - [Added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49875) click-and-drag features in GitLab 13.8. > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/299121) in GitLab 13.9. -GitLab provides a way to select which lines of code a comment refers to. After starting a comment -a dropdown selector is shown to select the first line that this comment refers to. -The last line is the line that the comment icon was initially clicked on. +When commenting on a diff, you can select which lines of code your comment refers +to by either: -New comments default to single line comments by having the first and last lines -the same. Selecting a different starting line turns this into a multiline comment. + - +- Clicking and dragging the **{comment}** **comment** icon in the gutter to highlight + lines in the diff. GitLab expands the diff lines and displays a comment box. +- After starting a comment by clicking the **{comment}** **comment** icon in the + gutter, select the first line number your comment refers to in the **Commenting on lines** + select box. New comments default to single-line comments, unless you select + a different starting line. -Once a multiline comment is saved the lines of code pertaining to that comment are listed directly -above it. +Multiline comments display the comment's line numbers above the body of the comment:  diff --git a/doc/user/project/merge_requests/squash_and_merge.md b/doc/user/project/merge_requests/squash_and_merge.md index 1b99b1b5c44..f500c18a32e 100644 --- a/doc/user/project/merge_requests/squash_and_merge.md +++ b/doc/user/project/merge_requests/squash_and_merge.md @@ -31,7 +31,7 @@ NOTE: The squashed commit in this example is followed by a merge commit, because the merge method for this repository uses a merge commit. You can disable merge commits in **Project Settings > General > Merge requests > Merge method > Fast-forward merge**. -The squashed commit's commit message will be either: +The squashed commit's commit message is either: - Taken from the first multi-line commit message in the merge. - The merge request's title if no multi-line commit message is found. @@ -60,7 +60,7 @@ This way, the history of your base branch remains clean with meaningful commit messages and: - It's simpler to [revert](revert_changes.md) if necessary. -- The merged branch will retain the full commit history. +- The merged branch retains the full commit history. ## Enabling squash for a merge request @@ -113,18 +113,18 @@ squashing can itself be considered equivalent to rebasing. With Squash Commits Options you can configure the behavior of Squash and Merge for your project. To set it up, navigate to your project's **Settings > General** and expand **Merge requests**. -You will find the following options to choose, which will affect existing and new merge requests +You can choose from these options, which affect existing and new merge requests submitted to your project: - **Do not allow**: users cannot use Squash and Merge to squash all the commits immediately before - merging. The checkbox to enable or disable it will be unchecked and hidden from the users. -- **Allow**: users will have the option to enable Squash and Merge on a merge request basis. - The checkbox will be unchecked (disabled) by default, but and the user is allowed to enable it. -- **Encourage**: users will have the option to enable Squash and Merge on a merge request basis. - The checkbox will be checked (enabled) by default to encourage its use, but the user is allowed to + merging. The checkbox to enable or disable it is unchecked and hidden from the users. +- **Allow**: users can enable Squash and Merge on a merge request basis. + The checkbox is unchecked (disabled) by default, but and the user is allowed to enable it. +- **Encourage**: users can enable Squash and Merge on a merge request basis. + The checkbox is checked (enabled) by default to encourage its use, but the user is allowed to disable it. -- **Require**: Squash and Merge is enabled for all merge requests, so it will always be performed. - The checkbox to enable or disable it will be checked and hidden from the users. +- **Require**: Squash and Merge is enabled for all merge requests, so it is always performed. + The checkbox to enable or disable it is checked and hidden from the users. The Squash and Merge checkbox is displayed when you create a merge request and when you edit the description of an existing one, except when Squash Commit Options is set to **Do not allow** or **Require**. diff --git a/doc/user/project/merge_requests/test_coverage_visualization.md b/doc/user/project/merge_requests/test_coverage_visualization.md index e60f2f712d3..02b557e22b9 100644 --- a/doc/user/project/merge_requests/test_coverage_visualization.md +++ b/doc/user/project/merge_requests/test_coverage_visualization.md @@ -146,7 +146,7 @@ coverage-jdk11: # The `visualize` stage does not exist by default. # Please define it first, or chose an existing stage like `deploy`. stage: visualize - image: haynes/jacoco2cobertura:1.0.4 + image: registry.gitlab.com/haynes/jacoco2cobertura:1.0.7 script: # convert report from jacoco to cobertura - 'python /opt/cover2cover.py target/site/jacoco/jacoco.xml src/main/java > target/site/cobertura.xml' @@ -186,7 +186,7 @@ coverage-jdk11: # The `visualize` stage does not exist by default. # Please define it first, or chose an existing stage like `deploy`. stage: visualize - image: haynes/jacoco2cobertura:1.0.4 + image: registry.gitlab.com/haynes/jacoco2cobertura:1.0.7 script: # convert report from jacoco to cobertura - 'python /opt/cover2cover.py build/jacoco/jacoco.xml src/main/java > build/cobertura.xml' @@ -219,3 +219,32 @@ run tests: reports: cobertura: coverage.xml ``` + +### C/C++ example + +The following [`gitlab-ci.yml`](../../../ci/yaml/README.md) example for C/C++ with +`gcc` or `g++` as the compiler uses [`gcovr`](https://gcovr.com/en/stable/) to generate the coverage +output file in Cobertura XML format. + +This example assumes: + +- That the `Makefile` is created by `cmake` in the `build` directory, + within another job in a previous stage. + (If you use `automake` to generate the `Makefile`, + then you need to call `make check` instead of `make test`.) +- `cmake` (or `automake`) has set the compiler option `--coverage`. + +```yaml +run tests: + stage: test + script: + - cd build + - make test + - gcovr --xml-pretty --exclude-unreachable-branches --print-summary -o coverage.xml --root ${CI_PROJECT_DIR} + coverage: /^\s*lines:\s*\d+.\d+\%/ + artifacts: + name: ${CI_JOB_NAME}-${CI_COMMIT_REF_NAME}-${CI_COMMIT_SHA} + expire_in: 2 days + reports: + cobertura: build/coverage.xml +``` diff --git a/doc/user/project/merge_requests/versions.md b/doc/user/project/merge_requests/versions.md index 8f3ce9186f1..2c77957c98d 100644 --- a/doc/user/project/merge_requests/versions.md +++ b/doc/user/project/merge_requests/versions.md @@ -64,7 +64,7 @@ In GitLab 12.10, we added a comparison mode, which shows a diff calculated by simulating how it would look like once merged - a more accurate representation of the changes rather than using the base of the two branches. The new mode is available from the comparison target drop down -by selecting **master (HEAD)**. In GitLab 13.9, it +by selecting **master (HEAD)**. In GitLab 13.9, it [replaced](https://gitlab.com/gitlab-org/gitlab/-/issues/198458) the old default comparison. For technical details, additional information is available in the [developer documentation](../../../development/diffs.md#merge-request-diffs-against-the-head-of-the-target-branch). diff --git a/doc/user/project/merge_requests/work_in_progress_merge_requests.md b/doc/user/project/merge_requests/work_in_progress_merge_requests.md index 43ab03114fa..4b854da116e 100644 --- a/doc/user/project/merge_requests/work_in_progress_merge_requests.md +++ b/doc/user/project/merge_requests/work_in_progress_merge_requests.md @@ -1,78 +1,8 @@ --- -stage: Create -group: Source Code -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 -type: reference, concepts +redirect_to: 'drafts.md' --- -# Draft merge requests **(FREE)** +This document was moved to [another location](drafts.md). -If a merge request is not yet ready to be merged, perhaps due to continued development -or open threads, you can prevent it from being accepted before it's ready by flagging -it as a **Draft**. This disables the **Merge** button, preventing it from -being merged. It stays disabled until the **Draft** flag has been removed. - - - -When [pipelines for merged results](../../../ci/merge_request_pipelines/pipelines_for_merged_results/index.md) -is enabled, draft merge requests run [merge request pipelines](../../../ci/merge_request_pipelines/index.md) -only. - -To run pipelines for merged results, you must [remove the draft status](#removing-the-draft-flag-from-a-merge-request). - -## Adding the "Draft" flag to a merge request - -> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32692) in GitLab 13.2, Work-In-Progress (WIP) merge requests were renamed to **Draft**. Support for using **WIP** is scheduled for removal in GitLab 14.0. -> - **Mark as draft** and **Mark as ready** buttons [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/227421) in GitLab 13.5. - -There are several ways to flag a merge request as a Draft: - -- Click the **Mark as draft** button on the top-right corner of the merge request's page. -- Add `[Draft]`, `Draft:` or `(Draft)` to the start of the merge request's title. Clicking on - **Start the title with Draft:**, under the title box, when editing the merge request's - description has the same effect. -- **Deprecated** Add `[WIP]` or `WIP:` to the start of the merge request's title. - **WIP** still works but was deprecated in favor of **Draft**. It is scheduled for removal in the next major version (GitLab 14.0). -- Add the `/draft` (or `/wip`) [quick action](../quick_actions.md#quick-actions-for-issues-merge-requests-and-epics) - in a comment in the merge request. This is a toggle, and can be repeated - to change the status back. Note that any other text in the comment is discarded. -- 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 doing it again in another - commit has no effect. - -## Removing the "Draft" flag from a merge request - -Similar to above, when a Merge Request is ready to be merged, you can remove the -`Draft` flag in several ways: - -- Click the **Mark as ready** button on the top-right corner of the merge request's page. -- Remove `[Draft]`, `Draft:` or `(Draft)` from the start of the merge request's title. Clicking on - **Remove the Draft: prefix from the title**, under the title box, when editing the merge - request's description, has the same effect. -- Add the `/draft` (or `/wip`) [quick action](../quick_actions.md#quick-actions-for-issues-merge-requests-and-epics) - in a comment in the merge request. This is a toggle, and can be repeated - to change the status back. Note that any other text in the comment is discarded. -- Click on the **Resolve Draft status** button near the bottom of the merge request description, - next to the **Merge** button (see [image above](#draft-merge-requests)). - Must have at least Developer level permissions on the project for the button to - be visible. - -## Including/excluding WIP merge requests when searching - -When viewing/searching the merge requests list, you can choose to include or exclude -WIP merge requests. Add a **WIP** filter in the search box, and choose **Yes** -to include, or **No** to exclude. - - - -<!-- ## Troubleshooting - -Include any troubleshooting steps that you can foresee. If you know beforehand what issues -one might have when setting this up, or when something is changed, or on upgrading, it's -important to describe those, too. Think of things that may go wrong and include them here. -This is important to minimize requests for support, and to avoid doc comments with -questions that you know someone might ask. - -Each scenario can be a third-level heading, e.g. `### Getting error message X`. -If you have none to add when creating a doc, leave this section in place -but commented out to help encourage others to add to it in the future. --> +<!-- This redirect file can be deleted after <2021-05-19>. --> +<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> |
