요약

  • GitHub의CODEOWNERS메커니즘은 브랜치 범위의 경로 라우팅 규칙입니다. 자격을 갖춘 풀 리퀘스트가 소유된 코드를 변경하면 지정된 소유자에게 리뷰 요청이 전달되도록 할 수 있습니다.
  • 실제 결과는 베이스 브랜치의 파일, 파일 위치 우선순위, 경로 매칭, 줄 순서 및 현재 소유자 자격에 따라 달라집니다. 따라서 화면에 표시된 파일 자체만으로는 이전 풀 리퀘스트에 대한 규칙 결과의 증거가 되지 못합니다.
  • 리뷰 영수증은 베이스·헤드 참조, 변경된 경로, 적용된CODEOWNERS스냅샷, 확인된 소유권, 요청 및 리뷰 이벤트, 그리고 별도로 입증된 병합 통제를 보존해야 합니다. 이는 편집적 증거 패턴이지 GitHub의 요구사항이 아닙니다.

라우팅 규칙에는 시점과 범위가 있다

“소유자들이 리뷰했다”는 표현은 종종 여러 질문을 감춥니다. 어느 브랜치가 소유권 정책을 제공했는가? 실제로 어떤 파일이 변경되었는가? 어느 패턴이 우선했는가? 지정된 사람이나 팀이 그 시점에 자격을 갖추고 있었는가? 요청은 전송되었고, 리뷰는 제출되었으며, 별도로 구성된 규칙이 그 리뷰를 요구했는가? 저장소 브라우저는 이 질문들 중 단 하나에만 답하면서 안심시키는 소유권 레이블을 보여줄 수 있습니다.

GitHub 문서는CODEOWNERS가 설정임을 매우 명확하게 설명합니다. 저장소가 코드에 책임 있는 사람이나 팀을 정의할 수 있게 해 줍니다. 비드래프트 풀 리퀘스트가 소유된 코드를 변경하면 GitHub가 자동으로 해당 소유자에게 리뷰를 요청합니다. 드래프트 풀 리퀘스트는 다릅니다. 리뷰 준비 완료로 표시되기 전에는 소유자에게 자동 요청하지 않습니다. 이는 유용한 라우팅 동작이지만, 라우팅 동작은 수신자가 행동했다는 증명이 아닙니다.

이 규칙에는 브랜치도 있습니다. GitHub는 각CODEOWNERS파일이 단일 브랜치에 대한 소유자를 지정하며, 리뷰 요청은 풀 리퀘스트의 베이스 브랜치에 있는 버전을 사용한다고 설명합니다. 따라서main을 향한 변경은 유지보수 브랜치를 향한 동일한 변경과는 다른 소유권 맵으로 해석될 수 있습니다. 포크에서 업스트림 베이스로 가는 풀 리퀘스트의 경우 업스트림 베이스 브랜치가 파일을 제공합니다. 헤드 브랜치에서 복사한 파일이나 기본 브랜치에 나중에 표시된 파일은 그 사실을 대체할 수 없습니다.

위치도 규칙의 일부입니다. GitHub는.github/, 그다음 저장소 루트, 그다음docs/순서로 검색하여 가장 먼저 찾은CODEOWNERS파일을 사용합니다. 또한 파일은 로드 가능해야 합니다. 문서는 3메가바이트 제한을 명시합니다. 초과된 파일은 로드되지 않으므로 소유권 정보가 표시되지 않고 적절한 소유자도 요청되지 않습니다. 이것들은 낯선 각주가 아닙니다. 저장소에 존재하는 정책 텍스트와 특정 사건을 지배한 정책 텍스트 사이의 차이입니다.

마지막 매치가 책임 주체를 바꾼다

패턴 파일은 해석이 선택적일 때에도 가산적으로 보일 수 있습니다. GitHub는 동일한 패턴이 별도의 줄에서 지정되면 마지막에 언급된 소유자만 매치한다고 설명합니다. GitHub 자신의 예는 그 결과를 분명히 보여줍니다. 일반적인*소유자는 자바스크립트 전용 변경에 대해 나중의*.js소유자가 대체할 수 있습니다. 같은 패턴 줄에 두 소유자를 넣으면 둘 다 소유자이고, 연속되는 매치 줄에 넣으면 나중 줄이 이깁니다. 나중 매치를 재구성하지 않고 일반 줄을 인용하는 리뷰어는 실제로 적용되지 않은 정책을 보고하고 있을 수 있습니다.

제약은 계속됩니다. 패턴은 대소문자를 구분하는 파일 시스템에서 평가되므로 대소문자를 구별합니다. 유효하지 않은 줄은 건너뜁니다. 존재하지 않거나 충분한 접근 권한이 없는 사용자나 팀은 지정되지 않습니다. 따라서 눈에 보이는 파일은 유효한 소유자 해석을 만들어내지 않으면서 익숙한 이름을 담고 있을 수 있습니다. 이 중 어느 것도 특정 저장소의 결함을 의미하지 않습니다. 설정에는 조건이 있고, 사건에 대한 결론에는 그 조건들의 증거가 필요하다는 뜻이며, 파일 하나의 잘린 스크린샷 한 장으로는 부족합니다.

감시 차원 외에 보안 차원의 함의도 있습니다. GitHub는 다른 소유자를 선정하는 정책에 대한 무단 변경을 막기 위해CODEOWNERS파일 자체에 대한 소유자를 정의할 것을 권고합니다. 이 권고는 재귀적 거버넌스 문제를 드러냅니다. 소유권 규칙은 자기 자신의 변경 경로가 추적 가능할 때에만 애플리케이션 코드를 지배할 수 있습니다. “이것들이 소유자다”라고 말하는 저장소는 그 문장을 누가, 어떤 베이스 브랜치에서, 어떤 통제 아래 바꿀 수 있었는지도 보여줄 수 있어야 합니다.

요청, 승인, 병합은 별개의 기록으로 남는다

GitHub는 자동 리뷰 요청을 병합 전 코드 소유자 승인 요구와 분리합니다. 후자는 관리자나 소유자가 선택하여 활성화할 수 있습니다. 이 요구가 적용될 때 여러 소유자가 있는 패턴의 경우 나열된 소유자 중 한 명의 승인이면 충분합니다. “~할 수 있다”는 단어가 중요합니다.CODEOWNERS파일 하나만으로 소유자의 리뷰가 필수 게이트가 되는 것은 아닙니다.

코드 소유자 승인이 브랜치의 모든 통제를 소진하지도 않습니다. GitHub의 룰셋은 브랜치 보호와 함께 작동할 수 있으며, 적용 가능한 규칙은 합산되고 공통 규칙 중 가장 제한적인 버전이 적용됩니다. 룰셋은 풀 리퀘스트 요구, 승인 수, 코드 소유자 승인, 상태 검사, 성공한 배포, 해결된 코멘트 또는 지정된 병합 방식을 별도로 요구할 수 있습니다. 우회 권한은 또 다른 별도의 설정 대상입니다. GitHub는 또한 완전히 승인된 풀 리퀘스트라도 같은 헤드 커밋을 공유하는 다른 열린 풀 리퀘스트에 보류 중이거나 거부된 리뷰가 있으면 차단된 상태로 남을 수 있다고 언급합니다.

이것이 승인을 상징으로 치부하라는 뜻은 아닙니다. 승인은 중요한 리뷰 처분입니다. GitHub는 변경 사항이 병합 준비가 되었음을 알리는 신호라고 설명합니다. 필요한 것은 단지 한정사를 유지하는 규율입니다. 누구에 따라, 어떤 디퍼에 대해, 어떤 리뷰 정책 아래, 그리고 어떤 남은 게이트와 함께 준비되었는가? 이 질문들은 리뷰에 적대적이지 않습니다. 범위가 한정된 기술적 판단이 권한의 완전한 역사로 서술되는 일을 막습니다.

설정–리뷰 영수증을 보존하라

중요한 주장에 대해서는 설정–리뷰 영수증이 가장 작고 유용한 기록입니다. 풀 리퀘스트 식별자, 베이스·헤드 커밋 또는 트리 참조, 변경된 경로 집합으로 시작합니다. 그런 다음 오늘 파일이 보이는 모습만 가리키지 않고 적용된 베이스 브랜치CODEOWNERS파일의 위치와 내용 식별성을 보존합니다. 영수증은 매치된 규칙과 해석된 소유자 집합, 알려진 자격 부재가 있다면 그것까지 명시해야 합니다.

다음 층은 이벤트 증거입니다. 리뷰 요청 이벤트, 리뷰어의 응답, 그 시각, 그리고 그것이 다룬 디퍼나 커밋입니다. 요청을 리뷰로 기록해서는 안 되고, 리뷰를 성공한 게이트로 기록해서는 안 됩니다. 병합 준비에 관한 주장이라면 적용되는 보호 및 룰셋 조건, 그 관련 관찰 상태, 그리고 문서화된 우회가 있다면 그것을 명명해야 합니다. 한 단계의 연결에 대한 증거가 없다면 공개 서술은 거기서 멈춰야 합니다.

이 영수증은 새로운 권한을 만들지 않습니다. 기존의 경계를 재구성 가능하게 만들 뿐입니다. 목적은 모든 풀 리퀘스트를 법적 서류로 만드는 것이 아닙니다. 관련 브랜치와 디퍼가 이미 이동한 뒤에 정적 파일, 알림, 초록 라벨이 “소유자들이 변경을 승인했다”로 압축되는 더 싼 허구를 피하는 것입니다.

출처

  1. GitHub Docs — 코드 소유자에 대하여
  2. GitHub Docs — 풀 리퀘스트 리뷰
  3. GitHub Docs — 룰셋에 대하여
  4. GitHub Docs — 룰셋에 사용 가능한 규칙