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. 병합 요청의 개요 탭에서 파이프라인 결과 아래에서 노출된 아티팩트 보기를 클릭하여 섹션을 펼칩니다.

  2. 코드 커버리지를 클릭합니다.

  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 이 링크를 통해 보고서가 저장된 위치로 리디렉션됩니다.

병합 요청 UI에서 커버리지 데이터 또한 시각화 되어야 합니다.

병합 요청 제목 검토

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

병합 요청을 병합하기 전에 제목을 확인하고, CHANGELOG.md 파일에서 명확하지 않을 것으로 생각된다면 제목을 업데이트하세요. 변경 로그에는 병합 요청 설명, 토론 또는 맥락을 제공하는 차이가 없으며, 단 한 줄만 나타납니다.

예를 들어 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 generator에 대해 알아야 할 중요한 몇 가지 사항이 있습니다:

  • 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 페이지를 읽어볼 시간을 가져보세요. 여기에는 특정 레이블을 사용해야 하는 경우에 대한 일부 지침이 제공됩니다.

개요

친애하는 리뷰어, 당신은 이제 검을 갖고 있습니다. 이제 용과 싸우세요!