Help Center/ CodeArts Repo/ User Guide/ Committing Code to CodeArts Repo and Creating a Merge Request/ Setting Repo-Level Merge Request Rules
Updated on 2024-11-22 GMT+08:00
View PDF
Share

Setting Repo-Level Merge Request Rules

The MR configuration refers to the configuration of code merge conditions and modes in MR mode. Project-level MR rules can be inherited to the repos and repo groups.

You can select Inherit from project. The settings in the project are automatically inherited and cannot be changed. You can also access the repo homepage of the code to be configured and choose Settings > Policy Settings > Merge Requests. There are two MR 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. 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.

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

    Table 1 Parameters for setting the merge condition and mode

    Parameter

    Description

    Merge Conditions

    Optional. There are two options:

    • Merge after all reviews 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 MR is not intercepted by the merge condition.
    • Must be associated with CodeArts Req The options are as follows:
      1. Associate only 1 ticket number. After this option is selected, one MR 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. Branches to configure the MR 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.

    MR Settings

    Optional. Options:

    • Do not merge your own requests After this parameter is selected, the Merge button is unavailable when you view the MRs created by yourself. You need to ask the person who has the permission to merge the MRs.
    • 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 MR A are included in MR A, MR B is automatically merged after MR A is merged. By default, the B MR is marked as merged. You can use this parameter to mark the B MR as closed.)
    • Cannot re-open a Closed MR This function is enabled by default. You can enable or disable it as required.
    • Enable "Delete source branch after merged" when creating MRs
    • Forbid squash merge (Forbid to select squash merge when create merge request)
    • Enable Squash merge for new MRs

    Merge Method

    Mandatory. The options are as follows:

    • 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 MR 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.

Configure Branch Policy

If you select the Approval mechanism as the Merge Mechanism and want to configure a merge policy for a branch, go to the repo homepage to be configured, choose Settings > Policy Settings > Merge Requests, click Create Branch Policy, and set parameters by referring to the following table.

Click Create Branch Policy to set a merge policy for a specified branch or all branches in the repository.

Table 2 Parameters for creating a branch policy

Parameter

Description

Branch

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

Reviewers Required

Mandatory. The default value is 0, indicating that the review gate can be passed without being reviewed by the reviewer.

Approvals Required

Mandatory. The default value is 0, indicating that the approval gate can be passed without being approved by the approver.

Reset approval gate

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

Reset review gate

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

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.

Reviewer

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

The following is an example of the branch policy priority:

  • Assume that there are policies A and B in the repository and their branches are the same. The system uses the latest branch policy by default.
  • Assume that 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 system uses policy B by default.

If no branch policy is set in the approval mechanism, the default branch policy is used when a merge request is committed. The branch policy can be edited and viewed but cannot be deleted. The policy configuration is as follows:

  • Branches: *. By default, all branches are used and cannot be modified.
  • Reviewers Required: The default value is 0.
  • Approvals Required: The default value is 0.
  • Reset approval gate: This option is selected by default.
  • Reset review gate: This option is selected by default.
  • Add approvers/reviewers only from the following ones: This option is not selected by default.
  • Enable pipeline gate: This option is not selected by default.
  • Mergers: This parameter is left blank by default.
  • Approvers: This parameter is left blank by default.
  • Reviewer: This parameter is left blank by default.
    Example of a mandatory reviewer list:
    • The Reviewers Required is 2. If the list of mandatory reviewers is empty, the 2 approvers in the list of New Reviewers give pass and the gate is passed.
    • The Reviewers Required is 2. If the list of mandatory reviewers is not empty, the gate can be approved only after at least one reviewer in the list give pass.