Code Owners

Code owners are members who are responsible for specific parts of the codebase. Code owners are defined and shown in the special file named CODEOWNERS. While the Responsibilities list gives you a broad spectrum of who's in charge of different parts of the project, the CODEOWNERS file lets you find out who to contact if you have a question about specific paths or files in the repository.

Besides, the CODEOWNERS file can be used to streamline merge requests to protected branches with code owners approval required as a quality gate. When someone submits a merge request, code owners of modified files are automatically requested for review and need to approve changes before a committer will be able to merge them.

Creating and finding a CODEOWNERS file

The CODEOWNERS file is part of your Git repository, and outlines who owns certain paths or files in a repository.

When you create a new repository in Space, a CODEOWNERS file template is created automatically for you. In existing repositories, you may need to create the file yourself. You can create the CODEOWNERS file in two places:

In the root directory of your repository
In the .space/ directory

To define code ownership, you need to manually add rules to the CODEOWNERS file, following the syntax described below.

The CODEOWNERS file is branch-specific, so bear in mind that:

When a merge request is submitted against a protected target branch, the CODEOWNERS file from that target branch applies. Thus, the CODEOWNERS file must be on the target branch of the merge request.
Each branch can have its own CODEOWNERS file, which means you can assign different code owners for different branches.

CODEOWNERS file syntax

In the CODEOWNERS file, each line represents a rule, which starts with a pattern for a path or file and is followed by one or more owners.

The pattern generally follows the same syntax used for .gitignore files. Wildcards like docs/ are supported, as are glob patterns like docs/**/*.md.
Owners can be specified as Space usernames, verified email addresses, or roles in the project. Teams can be specified as well.
By default, the CODEOWNERS file itself is owned by team members who are assigned the Project Admin role.
Order is important for merge request approvals. Rules are processed from top to bottom, so that the last matching pattern takes precedence. We recommend adding more general rules at the top of the file, and more specific towards the end. In the example file below, any file under /web/assets/ will require approval by Andrew, even if it’s a *.js file that is owned by Paul and Rachel.

Example of a CODEOWNERS file:

# Each line represents a rule, followed by a list of members.
# These members are the default owners for all files that match the specified pattern.
# The pattern generally follows the same syntax used for .gitignore files.
# The last matching rule always wins; those that appear lower in the file take precedence over rules that appear higher up.
# Specify owners by their username, email, or role assignment in the project.

# Examples:

# Member with username "Travis.Wickett" and member with email "rachel.pardey@somemail.com"
# own any JavaScript file in the repository
*.js Travis.Wickett rachel.pardey@somemail.com

# Jake handles Gradle files
*.gradle Jake.Miller

# Andrew owns all files under "/web/assets" directory at the repository root and all its subdirectories
/web/assets/ Andrew.Nelson

# All members who are assigned the Project Collaborator role own any file under docs/ directory
# anywhere in the repository, but not further nested files
docs/* "Project Collaborator"

# This file itself is owned by members who are assigned the Project Admin role in this project.
CODEOWNERS "Project Admin"

Code owners approval in merge requests

If you have the CODEOWNERS file set up, you can enable the code owners approval requirement as one of the quality gates for merge requests.

In the Protected Branches tab of your repository Settings, create (or edit) the protected branch rule, then select the Require approval from code owners checkbox under Quality Gates:

For detailed information please read Set Up Branch and Merge Restrictions

Last modified: 03 February 2023