Help Center/ CodeArts Repo/ User Guide/ Creating and Configuring a CodeArts Project/ Configuring Project-Level Repo Settings
Updated on 2024-12-12 GMT+08:00
View PDF
Share

Configuring Project-Level Repo Settings

On the CodeArts Repo homepage, go to the project homepage and choose Settings > Policy Settings > Repository Settings. For details about how to set the parameters, see Table 1.

Table 1 Project-level parameters

Parameter

Description

Force inherit

Optional. Once selected, all repo groups and code repos in the project use the following settings and cannot be changed. Exercise caution when selecting this option.

Do not fork a repository

Optional. Once selected, no one can fork the repo in the project.

Pre-merge

Optional. Once this is selected, the server automatically generates the pre-merge code of the MR. Compared with running commands on the client, this operation is more efficient and simple, and the build result is more accurate. This option applies to scenarios that have strict requirements on real-time build.

Branch Name Rule

Optional. All branch names must match the regular expression with max. 500 characters. If this field is left blank, any branch name is allowed. The rules must meet the following tag naming rules:

  • Max. 500 characters.
  • Do not start with refs/heads/refs/remotes/ or end with . / .lock. Spaces and the following characters are not supported:. [ \ < ~ ^: ? ( ) ' " |.

Tag Name Rule

Optional. All tag names must match the regular expression specified by this parameter. If this field is left blank, any tag name is allowed. The basic tag naming rules must be met.

  • Max. 500 characters.
  • Do not start with refs/heads/refs/remotes/ or end with . / .lock. Spaces and the following characters are not supported:. [ \ < ~ ^: ? ( ) ' " |.

Configuring Project-Level Protected Branch Rules

CodeArts Repo makes code branches more secure by preventing anyone other than the administrator from committing code, preventing anyone from forcibly committing code, or from deleting the branch. You can set this branch to be protected. The procedure is as follows: On the CodeArts Repo homepage, go to the project homepage, choose Settings > Policy Settings > Protected Branch, click Create Protected Branch, and set parameters as follows.

  1. Enter a branch name. This parameter is mandatory. Enter a complete branch name or a branch name with wildcard characters. If a branch contains a single slash (/), the branch cannot be matched using the wildcard * due to the fnmatch syntax rule.
  2. You can set the push or merge permission for the administrator/project manager, committer, and developer. These two permissions cannot be granted at the same time because the protected branch cannot be forcibly pushed or merged into the code. You can create, edit, and delete protected branches in batches.

If you want all repo groups and repo in this project to use the preceding settings, select Force Inherit.

Configuring Project-Level Merge Request Rules

A merge request rule consists of three parts: merge mechanism, merge condition, MR setting, and merge method.

Table 2 Parameters of the merge mechanism

Parameter

Description

Merge Mechanism

Mandatory. There are two options.

  • Score: Code review is included. You can set minimum merge score and the score ranges from 0 to 5. The code can be merged only when the score and mandatory review meet pass conditions. Set a minimum score when using this mechanism.
  • Approval: It consists of code review and merge approval. Code can be merged only after the number of reviewers reaches gate requirements.
    NOTE:
    • By default, Approval is used. You can manually switch to Score.
    • After the merge mechanism is changed, the workflows of the MRs are changed. However, the early created MRs retain the previous merge mechanism.
Table 3 Parameters of merge conditions

Parameter

Description

Merge Conditions

Optional. The options are as follows:

  • Select Only when all reviews and comments are resolved. If Must resolve is selected, Review comment gate: failed will be displayed and the Merge button is dimmed. If it is only a common review comment, the Resolved button does not exist, and the comment will not be intercepted by the merge condition.
  • If you select Only when associated with CodeArts Req , all associated E2E ticket numbers must pass the verification. One MR can be associated with only one ticket number. 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 to confirm.
Table 4 MR setting parameters

Parameter

Description

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

If you select this parameter, the Approve button is dimmed and you cannot approve your own MRs. You need to ask another person with the approve permission to approve your MRs.

Do not review your own requests

If you select this parameter, the Review button is dimmed and you cannot review your own MRs. You need to ask another person with the approve permission to approve your MRs.

A repo administrator can force merge code

The project creator and administrator roles have the permission to forcibly merge MRs. If the merging conditions are not met, these roles can click Force Merge to merge MRs.

Allow code review and comment for merged or closed MRs

After this parameter is selected, you can continue to review and comment on the merged MR.

Mark the automatically merged MRs as Closed (If all commits in the B MR are included in the A MR, the B MR is automatically merged after the A MR is merged. By default, the B MR is marked as merged. You can use this parameter to mark the B MR as closed.)
  • If this parameter is not selected, automatically merged MRs are marked as merged.
  • If this parameter is selected, MRs that are automatically merged are marked as closed.

Cannot re-open a Closed MR

If this option is selected, the branch merge request cannot be set back to Open after it is closed. Re-open in the upper right corner is hidden.

This parameter is used for process control to prevent review history from being tampered with.

Enable "Delete source branch after merged" when creating MRs

After this parameter is selected, Delete source branch after merge is enabled for new MRs by default. When this function is enabled, the source branch is deleted after the merge.

  • A protected source branch cannot be deleted.
  • This setting does not take effect for historical MRs. Therefore, you do not need to worry about branch loss.

Do not Squash

After this parameter is selected, the Squash button is unavailable, and the entry for using this button is unavailable in the MR.

  • Squash is not allowed when MRs are merged.

Enable Squash merge for new MRs

When squash merge in Git, all changes from the branch being merged are "squashed" into a single commit, which is then appended to the current branch as a "merge commit". This can simplify the branch history. The only difference between squash merge and common merge lies in the commitment history. For common merge, the merge commitment on the current branch usually has two commit records, while squash merge has only one commit record.

Configuring Project-Level Member Sync

On the project homepage, choose Code > Repo, and choose Settings > Security Settings > Member Sync.

After Sync Project Members is enabled, select the roles to be synced. Selected project members will be synced to the repo and repo group. The project manager will always be synced regardless of the toggle. Click the refresh button to sync all the current settings.

Adding, deleting, or modifying a project member will be automatically synced.

Sync Project Members is disabled for historical projects but enabled for new projects, and the Project manager, Committer, and Developer are selected by default.