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 을 열면 https://gitlab-org.gitlab.io/-/gitlab-runner/-/jobs/172824578/artifacts/out/coverage/coverprofile.regular.html 로 리디렉션되어 보고서가 저장된 곳으로 이동합니다.

커버리지 데이터는 또한 병합 요청 UI에서 확인할 수 있습니다.

병합 요청 제목 검토

우리는 CHANGELOG.md 항목을 병합 요청 제목에서 생성하기 때문에 제목이 유효하고 유익한지 확인하는 것이 검토자와 유지 관리자의 책임입니다.

병합 요청을 병합하기 전에 제목을 확인하고 그것이 CHANGELOG.md 파일에서 명확하지 않을 것 같다면 업데이트하세요. changelog에는 병합 요청 설명, 논의 또는 더 많은 맥락을 제공하는 diff 없이 이 한 줄만 포함됩니다.

예를 들어 https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1812를 살펴보고 다음을 비교하세요:

  • yml to yaml - 원래 제목으로 스크립트를 통해 changelog에 추가되었습니다.
  • Fix values.yaml filename in documentation - 제가 changelog에서 업데이트한 내용입니다.

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

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

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

병합 요청 레이블 검토

우리는 병합 요청에 할당된 레이블을 사용하여 changelog 항목을 다양한 그룹으로 묶고 개별 항목의 특정 기능을 정의합니다.

changelog 생성을 위해 우리는 자체 Changelog generator를 사용하고 있습니다. 이 도구는 GitLab Runner 리포지토리에 커밋된 구성 파일을 사용합니다.

검토자가 Changelog generator에 대해 알아야 할 몇 가지 중요한 사항은 다음과 같습니다:

  • GitLab Changelog는 label_matchers가 정의된 순서에 따라 병합 요청 레이블을 분석합니다. 처음 일치하는 범위가 분석된 병합 요청에 사용됩니다.

    예를 들어, 두 개의 병합 요청이 있다고 가정합니다 - 첫 번째는 security와 bug 레이블을 포함하고, 두 번째는 bug 레이블만 포함합니다 - 그리고 세 개의 매처가 이 순서대로 정의되어 있습니다: [security, bug] -> [security] -> [bug], 그러면 첫 번째 병합 요청은 [security, bug]로 일치하는 범위에 추가되고 두 번째 병합 요청은 [bug]로 일치하는 범위에 추가됩니다.

  • authorship_labels로 정의된 레이블이 있는 병합 요청은 작성자의 사용자 이름이 끝에 추가되어 changelog에 추가됩니다. 모든 authorship_labels 레이블은 이 방식으로 표시되기 위해 병합 요청에 추가되어야 합니다.

  • skip_changelog_labels로 정의된 레이블이 있는 병합 요청은 changelog에서 무시됩니다. 모든 skip_changelog_labels 레이블은 병합 요청 무시를 위해 추가되어야 합니다.

  • 정의된 label_matchers와 일치하지 않는 병합 요청은 Other changes 범주로 추가됩니다.

이 모든 것을 염두에 두고, 병합 요청을 병합할 때 다음 몇 가지 규칙을 따르세요:

  • GitLab Runner 또는 그 구성 요소의 배포와 관련된 모든 병합 요청에는 runner-distribution 레이블이 추가되어야 합니다.

  • 보안 관련이든 새로운 기능이든 버그 수정이든 관계없이 모든 병합 요청에는 security 레이블이 있어야 합니다. feature::addition이 아닌 모든 병합 요청은 보안 범주에 추가됩니다.

  • 모든 버그 수정 병합 요청에는 bug 레이블이 있어야 합니다.

  • 문서 업데이트만 포함된 병합 요청이 아닌 대부분의 병합 요청에서는 feature:: 또는 tooling:: 레이블 중 하나가 추가되어야 합니다. 이는 changelog 항목을 올바르게 정렬하는 데 도움을 줍니다.

  • documentation 레이블은 기술 작문 검토가 완료되면 자동으로 추가됩니다. 병합 요청이 문서 업데이트만 포함되더라도 그렇습니다. 만약 병합 요청이 오직 documentation 레이블만 있고 정의된 label_matchers 중 어떠한 레이블과도 일치하지 않는다면, 병합 요청이 오직 문서 업데이트만 있는지 다시 확인하세요. 그렇지 않으면, 추가되는 변경 유형에 맞는 구체적인 레이블 중 하나를 사용하세요!

  • 같은 릴리즈 주기 동안 병합된 변경 사항을 되돌리는 경우, 원래 병합 요청과 되돌리기 요청 모두에 skip_changelog_labels에 정의된 레이블을 추가하세요. 이는 릴리즈 준비 시 릴리즈 관리자가 해야 할 수동 작업을 줄여줍니다. 두 이벤트가 동일한 버전 에서 발생한 경우 변경을 추가하고 변환하는 것에 대해 항목을 추가하지 않아야 합니다.

    만약 되돌리기 병합 요청이 GitLab Runner의 이미 릴리즈된 버전으로 병합된 사항을 되돌린다면, 올바른 범주 레이블로 레이블을 추가하세요. 이 경우 changelog에 되돌리기를 표시해야 합니다.

  • 또한 엔지니어링 메트릭스 데이터 분류 페이지를 읽고 특정 레이블이 언제 사용되어야 하는지에 대한 지침을 확인하세요.

요약

친애하는 리뷰어님, 당신은 당신의 검을 받았습니다. 이제 드래곤과 싸우세요!