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/
config/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/
config/db/database-setup.md @docs-team

이 예에서:

• @general-approvers는 재정의 없이 모든 곳의 모든 항목을 소유합니다.
• @docs-team은 Documentation 섹션의 모든 항목을 소유합니다.
• @database-team은 Database 섹션의 모든 항목을 소유하지만, @docs-team에게 할당하는 재정의가 있는 config/db/database-setup.md는 제외합니다.
• 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에게 여러 승인 요구#

머지 리퀘스트의 승인 영역에 있는 Code Owners 섹션에 여러 승인을 요구할 수 있습니다. 섹션 이름에 대괄호 안에 숫자 n을 추가합니다(예: [2] 또는 [3]). 이는 이 섹션의 Code Owners로부터 n개의 승인을 요구합니다. n의 유효한 항목은 ≥ 1인 정수입니다. [1]은 기본값이므로 선택 사항입니다. n의 잘못된 값은 1로 처리됩니다.

Code Owner에게 여러 승인을 요구하려면:

1. 상단 메뉴에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > 저장소를 선택합니다.
3. 브랜치 규칙을 펼칩니다.
4. 기본 브랜치 옆에서 세부 사항 보기를 선택합니다.
5. Code owner 승인 아래의 토글을 켭니다.
6. 여러 승인에 대한 규칙을 추가하기 위해 CODEOWNERS 파일을 편집합니다.

예를 들어, [Documentation] 섹션에 두 개의 승인을 요구하려면:

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

[Ruby]
*.rb @dev-team

승인 영역의 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)가 프로젝트 A를 소유합니다.
• 상위 그룹 X에는 하위 그룹 Y(group-x/subgroup-y)도 포함되어 있습니다.
• 하위 그룹 Y가 프로젝트 B를 소유합니다.

적격한 Code Owner는:

• 프로젝트 A: 프로젝트 A가 하위 그룹 Y에 속하지 않으므로 그룹 X의 구성원만 해당됩니다.
• 프로젝트 B: 그룹 X와 하위 그룹 Y 모두의 구성원이 해당됩니다.

상위 그룹과 공유된 그룹#

직접 속하지 않은 프로젝트에 대해 그룹의 구성원이 Code Owner로 자격을 갖추게 하려면, 프로젝트의 상위 그룹에 그룹을 초대할 수 있습니다. 그룹을 초대하면 직접 구성원이 상위 그룹의 계층 구조에 있는 모든 프로젝트의 Code 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".

파싱할 수 없는 섹션#

섹션 제목을 파싱할 수 없는 경우, 섹션은:

1. 항목으로 파싱됩니다.
2. 이전 섹션에 추가됩니다.
3. 이전 섹션이 없으면 기본 섹션에 추가됩니다.

기본 섹션 이후#

* @group

[Section name
docs/ @docs_group

GitLab은 제목 [Section name을 항목으로 인식합니다. 기본 섹션에는 세 가지 규칙이 포함됩니다:

• 기본 섹션
  • * owned by @group
  • [Section owned by name
  • docs/ owned by @docs_group

명명된 섹션 이후#

[Docs]
docs/**/* @group

[Section name
docs/ @docs_group

GitLab은 제목 [Section name을 항목으로 인식합니다. [Docs] 섹션에는 세 가지 규칙이 포함됩니다:

• docs/**/* owned by @group
• [Section owned by name
• docs/ owned by @docs_group

잘못된 형식의 소유자#

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

/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이 하나의 승인을 요구합니다.