GitLab Runner 검토

이 문서에는 GitLab Runner 프로젝트 리뷰어를 위한 규칙과 제안이 포함되어 있습니다.

테스트 커버리지 보고서 검토

GitLab Runner 프로젝트에서는 많은 양의 코드가 있습니다. 불행하게도, 코드 커버리지는 포괄적이지 않습니다. 현재(2019년 초), 커버리지는 ~55% 수준입니다.

기존 코드에 테스트를 추가하는 것은 어렵지만, 프로젝트에 추가되는 새 코드가 좋은 테스트 커버리지를 갖도록 해야 합니다. 코드 리뷰어는 테스트 커버리지 보고서를 살펴보고 새 코드가 충분히 테스트되었는지 확인하는 것을 권장합니다.

가능한 한 신규 코드에 대한 테스트 커버리지를 최대한 많이 지향해야 합니다. 특정 변경에 대한 필요한 커버리지 수준을 정의하는 것은 리뷰어의 판단에 달려 있습니다. 때로는 100% 커버리지를 달성하는 것이 간단할 수 있지만, 때로는 커버리지가 20%인 코드를 추가하는 것이 현실적이며 가장 중요한 것들이 테스트되도록 보장할 수 있을 것입니다. 리뷰어님, 현명하게 선택하세요 :)

기술적인 세부 사항으로 돌아와서…

GitLab Runner CI/CD 파이프라인은 우리를 돕고 일반 (count) 및 경주 (atomic) 모드로 실행된 테스트에 대한 HTML 형식의 커버리지 보고서를 제공합니다.

보고서 유형은 두 가지이며, 파일 이름에 .race 및 .regular이 포함되어 있습니다. 이 파일들은 커버리지 옵션을 사용하여 실행된 go test 명령의 출력을 추적합니다. .race. 파일은 -race 플래그로 시작된 테스트의 소스와 보고서를 포함하고, .regular. 파일은 이 옵션 없이 시작된 테스트의 소스와 보고서를 포함합니다.

자세한 내용에 관심이 있는 분들을 위해, -race 테스트는 atomic 커버리지 모드를 사용하고, 표준 테스트는 count 커버리지 모드를 사용합니다.

우리의 경우 coverage/coverprofile.regular.html 파일을 살펴봐야 합니다. .race 테스트는 경합 상황에서 실패할 수 있으며 (이것이 실행되는 이유입니다), 현재 그 중 몇 가지가 지속적으로 실패하고 있습니다. 이는 커버리지 프로필이 완전하지 않을 수 있다는 것을 의미합니다.

반면에 .regular. 테스트는 우리 코드 내부에서 무엇이 테스트되었는지에 대한 완전한 개요를 제공해야 합니다.

병합 요청의 코드 커버리지 보고서를 보려면:

  1. 병합 요청의 개요 탭에서, 파이프라인 결과 아래 View exposed artifact를 클릭하여 섹션을 확장합니다.

  2. Code Coverage를 클릭합니다.

  3. out/coverage/ 디렉토리로 이동하는 아티팩트 브라우저를 사용합니다. 예를 들어, https://gitlab.com/gitlab-org/gitlab-runner/-/jobs/172824578/artifacts/browse/out/coverage/. 이 디렉토리에는 항상 세 개의 .race. 파일과 세 개의 .regular. 파일이 포함됩니다.

    변경 사항을 검토하는 경우, 주로 .regular. HTML 보고서( coverprofile.regular.html 파일)를 살펴보는 것이 중요합니다. 모든 파일이 외부 링크로 표시되므로, 이 예제에서는 https://gitlab.com/gitlab-org/gitlab-runner/-/jobs/172824578/artifacts/file/out/coverage/coverprofile.regular.html 을 열면 우리를 https://gitlab-org.gitlab.io/-/gitlab-runner/-/jobs/172824578/artifacts/out/coverage/coverprofile.regular.html 로 리디렉션하여 보고서를 저장하게 됩니다.

커버리지 데이터는 병합 요청 UI에서도 볼 수 있어야 합니다.

병합 요청 제목 검토

병합 요청 제목에서 CHANGELOG.md 항목 을 생성하기 때문에, 제목이 유효하고 정보를 제공하는지 확인하는 것은 리뷰어와 유지보수자의 책임입니다.

병합 요청을 병합하기 전에 제목을 확인하고, CHANGELOG.md 파일에서 명확하지 않을 것으로 생각되면 업데이트하세요. 변경 로그에는 병합 요청 설명, 토론 또는 추가 맥락을 제공하는 diff가 없는 이 한 줄만 포함될 것입니다.

예를 들어, https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1812를 살펴보고 비교해보세요:

  • yml to yaml - 원래 제목이며 우리 스크립트를 통해 변경 로그에 추가되었습니다.
  • Fix values.yaml filename in documentation - 이것이 제가 변경 로그에 업데이트한 내용입니다.

yml to yaml은 GitLab Runner 관리자가 더 높은 버전으로 업데이트하기 전에 변경 로그를 리뷰하면 무엇을 보여줄까요? 업데이트의 위험성을 보여주나요, 구현된 동작 변경을 보여주나요, 새로운 동작/기능이 추가되었나요? 병합 요청 및 제목을 검토할 때 이러한 질문들을 염두에 두세요.

기여자들은 위의 정보에 대해 인식하지 못할 수도 있고, 그들의 제목이 우리의 요구 사항과 일치하지 않을 수 있습니다. 기여자에게 이에 대해 교육을 시도하세요.

마지막으로, 병합 요청이 병합되기 전에 제목을 확인하고 업데이트하는 것은 여러분의 책임입니다.

병합 요청 라벨 검토

우리는 병합 요청에 할당된 라벨을 사용하여 변경 로그 항목을 서로 다른 그룹으로 묶고 개별 항목의 특별한 기능을 정의합니다.

변경 로그 생성을 위해 우리는 자체 Changelog generator를 사용하고 있습니다. 이 도구는 구성 파일을 사용하며, 이 파일은 GitLab Runner 리포지토리에 커밋되어 있습니다.

리뷰어가 Changelog 생성기에 대해 알아야 할 몇 가지 중요한 사항이 있습니다:

  • GitLab Changelog는 label_matchers가 정의된 순서대로 병합 요청 라벨을 분석합니다. 매칭되는 가장 먼저 일치하는 범위가 분석된 병합 요청에 사용됩니다.

예를 들어, security 및 bug 라벨이 있는 첫 번째 병합 요청과, bug 라벨만 있는 두 번째 병합 요청이 있다고 가정해보겠습니다. 그리고 여기에 정의된 세 개의 매처가 다음과 같은 순서로 정의되어 있다면: [security, bug] -> [security] -> [bug]
그러면 첫 번째 병합 요청은 [security, bug] (리스트에서 처음으로 정의된 것)에 맞게 될 것이고, 두 번째 병합 요청은 [bug] (리스트에서 마지막으로 정의된 범위)에 맞게 될 것입니다.

  • authorship_labels에서 정의된 라벨이 있는 병합 요청은 작성자의 사용자 이름이 끝에 추가된 채로 변경 로그에 추가됩니다. 모든 authorship_labels 라벨을 병합 요청에 추가해야 합니다.

  • skip_changelog_labels에서 정의된 라벨이 있는 병합 요청은 변경 로그에서 제외됩니다. 변경 로그를 건너뛰기 위해 모든 skip_changelog_labels 라벨을 병합 요청에 추가해야 합니다.

  • 정의된 label_matchers 중 어느 것과도 일치하지 않는 병합 요청은 기타 변경 범주에 추가됩니다.

위 모든 내용을 고려하여, 병합 요청을 병합할 때 다음 규칙을 준수해 주세요:

  • GitLab Runner나 그 부분이 배포되는 방법과 관련된 어떤 병합 요청이더라도 runner-distribution 라벨이 지정되어 있어야 합니다.

  • 보안과 관련된 어떤 병합 요청도 - 새로운 기능이든 버그 수정이든 - security 라벨을 가져야 합니다. feature::addition이 아닌 모든 병합 요청은 해당 보안 범주에 추가됩니다.

  • 버그 수정 병합 요청은 bug 라벨을 가져야 합니다.

  • 문서 업데이트만 하는 병합 요청이 아닐 경우 대부분의 병합 요청에서 feature:: 또는 tooling:: 라벨 중 하나를 추가했는지 확인해 주세요. 이것은 변경 로그 항목을 ​​올바르게 정렬하는 데 도움이 됩니다.

  • 기술 문서 검토가 완료되면 documentation 라벨이 자동으로 추가됩니다. 문서 업데이트 외에도 변경 내용이 있는 경우에도. 병합 요청에 documentation 라벨만 있는 경우 정의된 label_matchers와 일치하는 다른 라벨이 없다는 것을 다시 한 번 확인해 주세요. 그렇지 않으면 추가되는 변경의 유형과 일치하는 특정 라벨 중 하나를 사용해 주세요!

  • 동일한 릴리스 주기 동안 병합된 변경을 되돌릴 때, 본 병합 요청과 되돌리기 요청에 skip_changelog_labels에서 정의된 라벨을 지정해 주세요. 이렇게 하면 릴리스 관리자가 릴리스를 준비할 때 필요한 수동 작업이 줄어듭니다. 동일한 버전에서 변경을 추가하고 변경을 되돌린 항목에 대한 항목을 추가하지 않아야 합니다.

    변경을 되돌리는 병합 요청이 이미 릴리스된 버전의 GitLab Runner에 병합되었을 경우, 올바른 범위 라벨이 지정되어 있는지 확인해 주세요. 이 경우 변경 로그에 되돌리기를 표시하려면 적절한 범위 라벨을 지정해야 합니다.

  • 또한, Engineering metrics data classification 페이지를 읽어 보시기 바랍니다. 해당 페이지에서 특정 라벨을 사용해야 하는 경우에 대한 지침을 제공합니다.

요약

친애하는 리뷰어, 당신은 검열을 하기 위해 준비가 되었습니다. 이제 용과 싸우러 가세요!