Define Code Owners for specific files or directories

CasinoGames

The  file 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 uses  with the  and  flags 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.The  flag allows  to match dotfiles like .The  flag prevents  from matching the  path 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 the  section. owns all items in the  section except
, which has an override assigning it to .A merge request that modifies  would require three approvals: one from each
of the ,, and  groups.
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 the  section header, and two
entries under . The entries defined under the sections  and
are combined, using the case of the first section.

When a file or directory matches multiple entries in the  file,
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 following  file:

The Code Owner for  would be .

You can require multiple approvals for the Code Owners sections in the Approvals area in merge requests.
Append the section name with a number  in brackets, for example,  or .
This requires  approvals from the Code Owners in this section.
Valid entries for  are integers .  is optional because it is the default. Invalid values for  are 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 the  file to add a rule for multiple approvals.
For example, to require two approvals for the  section:

The  Code Owners section in the Approvals area displays two approvals are required:



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 parses  as: .

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 heading  as an entry. The default section includes 3 rules:
Default section owned by  owned by  owned by After a named section
GitLab recognizes the heading  as an entry. The  section includes 3 rules:
owned by  owned by  owned by
Each entry must contain one or more owners. Malformed owners are invalid and ignored:

This entry is owned by  and .

GitLab ignores inaccessible or incorrect owners. For example:

If only , , and  are 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.