Help Center/ CodeArts Repo/ User Guide/ Configuring Project-Level Settings for CodeArts Repo/ Configuring Project-Level Merge Request Rules
Updated on 2026-06-24 GMT+08:00
View PDF
Share

Configuring Project-Level Merge Request Rules

Introduction

The merge request rules refer to the configuration of code merge conditions and modes in merge request mode. Project-level merge request rules can be inherited to the repositories and repository groups.

Before configuring a merge request rule, check Constraints. If you have the configuration permission, configure the rule based on Configuring Merge Request Rules.

Constraints

Table 1 Constraints on setting merge request rules

Item

Description

Permission constraint

Project manager or project administrator can set project-level merge request rules. For details, see Configuring Project-Level Permissions.

Configuring Merge Request Rules

You can select Force inherit. The settings in the project are automatically inherited and cannot be changed.

You can also access the target project homepage of the code to be configured and choose Settings > Policy Settings > Merge Requests on the top navigation bar. You can create a merge request rule by referring to the following steps:

  1. Select a merge mechanism. There are two merge request mechanisms: score and approval. The differences between the two mechanisms are as follows:

    • Scoring mechanism: This mode includes only code review and is based on scoring (0—5). Code can be merged only when the score meets the gate conditions.
    • The approval method consists of code review and merge approval. Code can be merged only after the number of reviewers and approvers reaches gate requirements.

  2. After selecting a mechanism, set other parameters by referring to the following table. The configuration takes effect for the entire code repo.

    Table 2 Parameters for setting the merge condition, request, and method

    Parameter

    Description

    Example Value

    Merge Conditions

    Optional. There are two options:

    • Only when all reviews and comments are resolved. After this parameter is selected, if Must resolve is selected as the review comment, a message Review comment gate: failed is displayed and the Merge button is unavailable. If it is a common review comment, the Resolved button does not exist, the merge request is not intercepted by the merge condition.
    • Only when associated with CodeArts Req. The options are as follows:
      1. Associate only one ticket number. After this option is selected, one merge request can be associated with only one ticket number.
      2. All E2E ticket numbers pass verification. After this option is selected, all associated E2E ticket numbers must pass the verification.
      3. Target branches to configure the merge request policy. You can add multiple branches to configure the merge request policy. You can manually enter wildcard characters (for example, *-stable or production/*), and press Enter.
      CAUTION:

      The Only when evaluated parameter is available for the Pro edition.

    • Only when evaluated

      If this option is selected, at least one member who has the merge permission must perform evaluation.

    • Roles allowed to evaluation

      You can select one or more roles with the merge permission from the drop-down list box.

    *-stable indicates that the E2E trouble ticket number ending with -stable is matched.

    Merge Request Settings

    Optional. Options:

    • Do not merge your own requests. After this parameter is selected, the Merge button is unavailable when you view the merge requests created by yourself. You need to ask the person who has the permission to handle them.
    • Do not approve your own requests.
    • Do not review your own requests.
    • A repo administrator or project manager can force merge code.
    • Allow code review and comment for merged or closed MRs.
    • Mark the automatically merged MRs as Closed. If all commits in merge request B are included in merge request A, merging A will automatically merge B. By default, merge request B is marked as merged. You can select this option to mark merge request B as closed.
    • Cannot re-open a Closed MR. This option is deselected by default. You can change it anytime.
    • Enable "Delete source branch after merged" when creating MRs.
    • Do not Squash. (Forbid to select squash merge when creating a merge request)
    • Enable Squash merge for new MRs.

    Merge Method

    There are three options:

    • Merge commit. If this parameter is selected, a merge commit is created for every merge, and merging is allowed as long as there are no conflicts. That is, no matter whether the baseline node is the latest node, the baseline node can be merged if there is no conflict.
      • Do not generate Merge nodes during Squash merge: If this parameter is selected, no merge node is generated during the squash merging.
      • Use MR merger to generate Merge Commit: If this parameter is selected, the commit information is recorded.

        Use MR creator to generate Merge Commit: If this parameter is selected, the commit information is recorded.

    • Merge commit with semi-linear history. If this parameter is selected, a merge commit is recorded for each merge operation. However, different from Merge commit, the commitment must be performed based on the latest commit node of the target branch. Otherwise, the system prompts the developer to perform the rebase operation. In this merging mode, if the merge request can be correctly constructed, the target branch can be correctly constructed after the merge is complete.
    • Fast-forward. If this parameter is selected, no merge commits are created and all merges are fast-forwarded, which means that merging is only allowed if the branch could be fast-forwarded. When fast-forward merge is not possible, the user is given the option to rebase.

  3. After setting the parameters, click Submit to save the configurations.

If your merge mechanism is Approval and you want to set the merge policy for a specified branch or all branches in the repository, please refer to Configuring Branch Policy.

Configuring Branch Policy

Go to the target repository homepage, choose Settings > Policy Settings > Merge Requests. In the Branch Policies area, click Create Branch Policy, and set parameters by referring to Table 3.

Table 3 Parameters for creating a branch policy

Parameter

Description

Branch

Select a branch from the drop-down list. You can select all branches.

Reviewers Required

The default value is 2.

0 indicates that the merge request can pass the review gate without review.

Approvals Required

The default value is 2.

0 indicates that the merge request can pass the approval gate without approval.

Reset approval gate

Optional. This option is selected by default, indicating that merge request approval gate is reset when code is re-pushed to the source branch of the merge request.

Reset review gate

Optional. This option is selected by default, indicating that the merge request review gate is reset when code is re-pushed to the source branch of the merge request.

Add approvers/reviewers only from the following ones

Optional. If this option is selected, you can configure the list of New Approvers and New Reviewers. If you want to add additional members, you can only add members from the lists.

Enable pipeline gate

Optional. If this option is selected, before the merge, you need to pass all pipeline gates. This rule integrates the CI into the code development process.

Mergers

Optional. The list of mandatory mergers can be configured. When a merge request is created, the list is automatically synchronized to the merge request.

Approvers

Optional. The list of mandatory approvers can be configured. When a merge request is created, the list is automatically synchronized to the merge request.

Reviewers

Optional. The list of mandatory reviewers can be configured. When a merge request is created, the list is automatically synchronized to the merge request.

Helpful Links

  • The following is an example of the branch policy priority:
    • If a branch has both policies A and B in a repository, the latest created branch policy is used by default.
    • There are policies A and B in the repository. Branch A and branch B are configured for policy A, and branch A is also configured for policy B. When a merge request whose target branch is Branch A is committed, the policy B is used by default.
  • After the merger, approver, and reviewer are configured for a branch for the first time, the data is automatically loaded from the browser cache when a merge request is created. If the name of the merger, approver, or reviewer is changed and their repository permission is removed, a message is displayed on the page for creating a merge request, indicating insufficient permissions. In this case, you only need to remove the user as prompted to update the cache data. The user will not be displayed in subsequent merge requests.