CODEOWNERS 파일을 사용하면 특정 파일과 디렉터리를 누가 담당하는지 정의할 수 있습니다. 패턴 매칭, 섹션, 상속 규칙으로 머지 리퀘스트에 리뷰어를 지정하고 머지 전에 해당 리뷰어의 승인을 요구할 수 있습니다.

패턴 매칭#

GitLab은 패턴 매칭에 File::FNM_DOTMATCH와 File::FNM_PATHNAME 플래그를 설정한 File::fnmatch를 사용합니다:

• 리포지터리 구조는 독립된 파일 시스템처럼 취급됩니다.
• 패턴은 셸 파일 이름 글로빙 규칙의 일부를 따르며, 정규 표현식이 아닙니다.
• File::FNM_DOTMATCH 플래그는 *가 .gitignore 같은 닷파일과도 일치하도록 허용합니다.
• File::FNM_PATHNAME 플래그는 *가 경로 구분자 /와 일치하지 않도록 합니다.
• **는 디렉터리를 재귀적으로 일치시킵니다. 예를 들어 **/*.rb는 config/database.rb와 app/controllers/users/stars_controller.rb에 일치합니다.

기본 Code Owner 및 선택적 섹션#

기본 소유자 구문을 선택적 섹션 및 필수 승인과 함께 사용하려면 기본 소유자를 맨 끝에 배치합니다:

[Documentation][2] @docs-team
docs/
README.md

^[Database] @database-team
model/db/
model/db/database-setup.md @docs-team

일반 항목과 섹션#

섹션 밖의 경로에 기본 Code Owner를 지정하면 해당 소유자의 승인이 항상 필요합니다. 이런 항목은 섹션으로 재정의되지 않습니다. 섹션에 속하지 않은 항목은 이름 없는 또 다른 섹션처럼 취급됩니다:

# Required for all files
* @general-approvers

[Documentation] @docs-team
docs/
README.md
*.txt

[Database] @database-team
model/db/
model/db/database-setup.md @docs-team

이 예시에서 각 항목의 의미는 다음과 같습니다:

• @general-approvers는 모든 위치의 모든 항목을 소유하며, 재정의되지 않습니다.
• @docs-team은 Documentation 섹션의 모든 항목을 소유합니다.
• @database-team은 Database 섹션에서 model/db/database-setup.md를 제외한 모든 항목을 소유합니다. 이 파일은 재정의를 통해 @docs-team에 할당되어 있습니다.
• model/db/CHANGELOG.txt를 수정하는 머지 리퀘스트에는 @general-approvers, @docs-team, @database-team 그룹에서 각각 하나씩 총 세 건의 승인이 필요합니다.

이 동작은 섹션의 기본 소유자만 사용할 때와 비교됩니다. 그 경우에는 섹션 안의 개별 항목이 섹션 기본값을 재정의합니다.

중복된 이름의 섹션#

이름이 같은 섹션이 여러 개 있으면 하나로 합쳐집니다. 또한 섹션 제목은 대소문자를 구분하지 않습니다. 예를 들면 다음과 같습니다:

[Documentation]
ee/docs/    @docs
docs/       @docs

[Database]
README.md  @database
model/db/   @database

[DOCUMENTATION]
README.md  @docs

이 코드는 Documentation 섹션 제목 아래에 세 개의 항목을, Database 아래에 두 개의 항목을 만듭니다. Documentation 섹션과 DOCUMENTATION 섹션에 정의된 항목은 먼저 나온 섹션의 대소문자 표기를 사용해 하나로 합쳐집니다.

특정 파일 또는 디렉터리에 대한 Code Owner 정의#

파일이나 디렉터리가 CODEOWNERS 파일의 여러 항목에 일치하면, 그 파일이나 디렉터리에 일치하는 마지막 패턴의 사용자가 적용됩니다. 따라서 항목의 순서를 적절히 배치하면 더 구체적으로 정의한 파일이나 디렉터리에 더 구체적인 소유자를 정의할 수 있습니다.

예를 들어 다음과 같은 CODEOWNERS 파일이 있다고 가정합니다:

# This line would match the file terms.md
*.md @doc-team

# This line would also match the file terms.md
terms.md @legal-team

이 경우 terms.md의 Code Owner는 @legal-team 입니다.

Code Owner에게 여러 승인 요구#

머지 리퀘스트의 Approvals 영역에서 Code Owners 섹션에 여러 건의 승인을 요구할 수 있습니다. 섹션 이름 뒤에 대괄호로 숫자 n을 덧붙입니다. 예를 들면 [2] 나 [3] 입니다. 이렇게 하면 해당 섹션의 Code Owner 로부터 n 건의 승인이 필요합니다. n에는 ≥ 1 인 정수를 사용할 수 있습니다. [1]은 기본값이므로 생략할 수 있습니다. n에 유효하지 않은 값을 넣으면 1로 처리됩니다.

Code Owner에게 여러 승인을 요구하려면 다음과 같이 진행합니다:

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Settings > Repository를 선택합니다.
3. Branch rules를 확장합니다.
4. 기본 브랜치 옆에서 View details를 선택합니다.
5. Code owner approval 아래의 토글을 켭니다.
6. CODEOWNERS 파일을 편집해 여러 승인 규칙을 추가합니다.

예를 들어 [Documentation] 섹션에 두 건의 승인을 요구하려면 다음과 같이 작성합니다:

[Documentation][2]
*.md @tech-writer-team

[Ruby]
*.rb @dev-team

Approvals 영역의 Documentation Code Owners 섹션에 두 건의 승인이 필요하다고 표시됩니다:

그룹 상속 및 자격#

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
    accTitle: Diagram of group inheritance
    accDescr: If a subgroup owns a project, the parent group inherits ownership.
    A[Parent group X] -->|owns| B[Project A]
    A -->|contains| C[Subgroup Y]
    C -->|owns| D[Project B]
    A-. inherits ownership .-> D

이 예시에서 각 항목의 의미는 다음과 같습니다:

• 상위 그룹 X(group-x)가 Project A를 소유합니다.
• 상위 그룹 X에는 하위 그룹인 Subgroup Y(group-x/subgroup-y)도 포함되어 있습니다.
• Subgroup Y가 Project B를 소유합니다.

Code Owner가 될 수 있는 대상은 다음과 같습니다:

• Project A: Group X의 멤버만 해당합니다. Project A는 Subgroup Y에 속하지 않기 때문입니다.
• Project B: Group X와 Subgroup Y의 멤버 모두 해당합니다.

상위 그룹과 공유된 그룹#

그룹의 멤버가 직접 소속되지 않은 프로젝트에서도 Code Owner 자격을 갖게 하려면 해당 프로젝트의 상위 그룹에 그룹을 초대할 수 있습니다. 그룹을 초대하면 그 그룹의 직접 멤버는 상위 그룹 계층의 모든 프로젝트에서 Code Owner 자격을 갖습니다.

사전 요구 사항:

• 다른 그룹을 초대할 그룹에 대한 Owner 권한이 있어야 합니다.
• 그룹을 초대할 때 Developer, Maintainer 또는 Owner 권한을 할당해야 합니다.

예를 들어 다음과 같은 계층이 있다고 가정합니다:

group-x
├── engineering-group
└── product-group
    └── project-a

engineering-group을 product-group에 초대하면 engineering-group의 멤버는 project-a에서 Code Owner 자격을 갖습니다. engineering-group을 project-a에 직접 초대할 필요는 없습니다.

초대된 그룹의 직접 멤버만 Code Owner 자격을 갖습니다. 초대된 그룹에서 멤버십을 상속한 멤버는 자격이 없습니다.

오류 처리#

공백이 있는 항목#

경로의 공백은 백슬래시로 이스케이프합니다:

path\ with\ spaces/*.md @owner

이스케이프하지 않으면 GitLab은 folder with spaces/*.md @group을 path: "folder", owners: " with spaces/*.md @group"으로 해석합니다.

파싱할 수 없는 섹션#

섹션 제목을 파싱할 수 없으면 GitLab은 다음과 같이 처리합니다.

• 제목을 무시합니다.
• 제목 뒤에 오는 항목을 이전 섹션에 추가합니다. 이전 섹션이 없으면 항목을 기본 섹션에 추가합니다.
• CODEOWNERS 파일을 확인할 때 Unparsable sections 오류를 표시합니다.

[Docs]] 또는 [Docs][ 1]처럼 GitLab이 여전히 사용할 수 있는 일부 잘못된 형식의 제목에도 Unparsable sections 오류가 나타납니다. GitLab은 이러한 제목을 섹션으로 취급하므로, 이 오류가 항상 제목이 무시된다는 뜻은 아닙니다.

기본 섹션 이후#

* @group

[Section name
docs/ @docs_group

GitLab은 제목 [Section name을 무시합니다. 기본 섹션에는 다음 두 가지 규칙이 포함됩니다:

• @group 이 소유하는 *
• @docs_group 이 소유하는 docs/

명명된 섹션 이후#

[Docs]
docs/**/* @group

[Section name
docs/ @docs_group

GitLab은 제목 [Section name을 무시합니다. [Docs] 섹션에는 다음 두 가지 규칙이 포함됩니다:

• @group 이 소유하는 docs/**/*
• @docs_group 이 소유하는 docs/

잘못된 형식의 소유자#

각 항목에는 소유자가 하나 이상 있어야 합니다. 잘못된 형식의 소유자는 유효하지 않으며 무시됩니다:

/path/* @group user_without_at_symbol @user_with_at_symbol

이 항목은 @group과 @user_with_at_symbol 이 소유합니다.

접근 불가능하거나 잘못된 소유자#

GitLab은 접근할 수 없거나 잘못된 소유자를 무시합니다. 예를 들면 다음과 같습니다:

* @group @grou @username @i_left @i_dont_exist example@gitlab.com invalid@gitlab.com

@group, @username, example@gitlab.com만 접근 가능하면 GitLab은 나머지를 무시합니다.

소유자가 없는 경우#

항목에 소유자가 없거나 접근 가능한 소유자가 하나도 없으면 그 항목은 유효하지 않습니다. 이 규칙은 충족될 수 없으므로 GitLab은 머지 리퀘스트에서 해당 규칙을 자동으로 승인 처리합니다.

최소 승인 수#

섹션에 승인 수를 정의할 때 최소 승인 수는 1 입니다. 승인 수를 0으로 설정하면 GitLab은 승인 한 건을 요구합니다.