Define Code Owners for specific files or directories
Thefile helps you define who is responsible for specific files and directories.
You can use pattern matching, sections, and inheritance rules to assign reviewers to merge requests
and require their approval before merging.
GitLab useswith theandflags set for pattern matching:
The repository structure is treated like an isolated file system.The patterns follow a subset of shell filename globbing rules, and are not regular expressions.Theflag allowsto match dotfiles like .Theflag preventsfrom matching thepath separator. matches directories recursively. For example,matches
and .
To combine the syntax for default owners with optional sections
and required approvals, place default owners at the end:
If you set a default Code Owner for a path outside a section, their approval is always required.
Such entries aren’t overridden by sections.
Entries without sections are treated as if they were another, unnamed section:
In this example:
owns all items everywhere, without overrides. owns all items in thesection. owns all items in thesection except
, which has an override assigning it to .A merge request that modifieswould require three approvals: one from each
of the ,, andgroups.
Compare this behavior to when you use only default owners for sections,
when specific entries in a section override the section default.
If multiple sections have the same name, they are combined.
Also, section headings are not case-sensitive. For example:
This code results in three entries under thesection header, and two
entries under . The entries defined under the sectionsand
are combined, using the case of the first section.
When a file or directory matches multiple entries in thefile,
the users from last pattern matching the file or directory are used. This enables you
to define more specific owners for more specifically defined files or directories, when
you order the entries in a sensible way.
For example, in the followingfile:
The Code Owner forwould be .
You can require multiple approvals for the Code Owners sections in the Approvals area in merge requests.
Append the section name with a numberin brackets, for example,or .
This requiresapprovals from the Code Owners in this section.
Valid entries forare integers .is optional because it is the default. Invalid values forare treated as .
To require multiple approvals from Code Owners:
On the left sidebar, select Search or go to and find your project.Select Settings > Repository.Expand Branch rules.Next to the default branch, select View details.Turn on the toggle under Code owner approval.Edit thefile to add a rule for multiple approvals.
For example, to require two approvals for thesection:
TheCode Owners section in the Approvals area displays two approvals are required:
https://docs.gitlab.com/user/project/codeowners/img/multi_approvals_code_owners_sections_v15_9.png width=800
In this example:
Parent group X () owns Project A.Parent group X also contains a subgroup, Subgroup Y. ()Subgroup Y owns Project B.
The eligible Code Owners are:
Project A: the members of Group X only, because Project A doesn’t belong to Subgroup Y.Project B: the members of both Group X and Subgroup Y.
Inviting Subgroup Y to a parent group of Project A
is not supported. To set Subgroup Y as
Code Owners, invite this group directly to the project itself.
You can invite Subgroup Y to Project A
so that their members also become eligible Code Owners.
If you do not invite Subgroup Y to Project A, but make them Code Owners, their approval
of the merge request becomes optional.
Escape whitespace in paths with backslashes:
Without escaping, GitLab parsesas: .
If a section heading cannot be parsed, the section is:
Parsed as an entry.Added to the previous section.If no previous section exists, the section is added to the default section.After the default section
GitLab recognizes the headingas an entry. The default section includes 3 rules:
Default section owned byowned byowned by After a named section
GitLab recognizes the headingas an entry. Thesection includes 3 rules:
owned byowned byowned by
Each entry must contain one or more owners. Malformed owners are invalid and ignored:
This entry is owned byand .
GitLab ignores inaccessible or incorrect owners. For example:
If only , , andare accessible, GitLab ignores the others.
If an entry includes no owners, or zero accessible owners
exist, the entry is invalid. Because this rule can never be satisfied, GitLab
auto-approves it in merge requests.
When defining the number of approvals for a section,
the minimum number of approvals is . Setting the number of approvals to
results in GitLab requiring one approval.
页:
[1]