Help Center/ CodeArts Repo/ User Guide/ Hierarchical Repository Management/ Configuring Repository Groups/ Repository Settings
Updated on 2024-11-22 GMT+08:00
View PDF
Share

Repository Settings

To configure repository settings, you can choose Settings > Repository Management > Repository Settings on the repository group details page.

The default branch is selected when you enter the current repository group or create an MR. Each new repository in a repository group has a default branch - master, which can be changed at any time.

The settings take effect only for the repository group configured.

All repository members can view this page. For details about whether a repository member has repository setting permissions, refer to the Permissions page. After the setting is complete, click Submit.

Table 1 Description

Parameter

Description

Pre-merge

By default, this option is not selected. After this option is selected, the server automatically generates MR pre-merging code. 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

All branch names must match the regular expression specified by this parameter. If this parameter is left empty, any branch name is allowed. The value must comply with the basic branch naming rules and contain a maximum of 500 characters. Example: ^feature-[0-9a-zA-Z]+

  • Max. 500 characters.
  • The name cannot start with -, refs/heads/, or refs/remotes/, and cannot contain spaces or special characters such as [\<~^:?*!()'"|. It cannot end with ./ or .lock.
  • The name of a new branch cannot be the same as that of an existing branch or tag.

Tag name rule

All tag names must match the regular expression specified by this parameter. If this parameter is left empty, any tag name is allowed. The tag name must comply with the basic tag naming rules and contain a maximum of 500 characters. Example: ^TAG*$

  • Max. 500 characters.
  • The name cannot start with -, refs/heads/, or refs/remotes/, and cannot contain spaces or special characters such as [\<~^:?*!()'"|. It cannot end with ./ or .lock.
  • The name of a new tag cannot be the same as that of an existing branch or tag.
  • Byte: a group of adjacent binary digits. It is an important data unit of computers and is usually represented by B. 1 B = 8 bits.
  • Character: a letter, digit, or another symbol that represents data and information.

Configuring MR Pre-merge

After an MR is created, you can customize the scripts for downloading plug-ins such as WebHook and CodeArts Pipeline. That is, you can control the downloaded code content.

  • If Pre-merge is selected, the server will generate a hidden branch, indicating that the MR code has been merged. You can directly download the code that already exists in the hidden branch.
  • If Pre-merge is not selected, you need to perform pre-merge on the client. That is, download the code of the MR source branch and MR target branch and perform pre-merge on the build executor.

Commands

The pre-merge commands on the server are as follows:

git init  
git remote add origin ${repo_url clone or download URL}
git fetch origin +refs/merge-requests/${repo_MR_iid}/merge:refs/${repo_MR_iid}merge

If this option is not selected, you can perform the pre-merge operation on the client and create a clean working directory on the local host. The command is as follows:

git init
git remote add origin ${repo_url clone or download URL}
git fetch origin +refs/heads/${repoTargetBranch}:refs/remotes/origin/${repoTargetBranch}
git checkout ${repoTargetBranch}
git fetch origin +refs/merge-requests/${repo_MR_iid}/head:refs/remotes/origin/${repo_MR_iid}/head
git merge refs/remotes/origin/${repo_MR_iid}/head --no-edit

Advantages

In scenarios that have high requirements on real-time build, for example, one MR may start the build of dozens or hundreds of servers, and the pre-merging result generated by the local or client may be inconsistent with that generated by the server. As a result, the build code cannot be obtained accurately and the build result is inaccurate. Pre-merging on the server can solve this problem in real time. In addition, the script building command is simpler, and developers or CIEs can better use it.