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. 테스트는 코드 내부에서 무엇이 테스트되었는지에 대한 전체 개요를 제공해야 합니다.

Merge Request의 코드 커버리지 보고서를 보려면:

  1. Merge Request의 개요 탭에서 파이프라인 결과 아래의 노출된 아티팩트 보기를 클릭하여 섹션을 확장합니다.

  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 로 리디렉션하여 보고서가 저장된 곳으로 이동하게 될 것입니다.

Merge Request에 대한 커버리지 데이터는 또한 Merge Request UI 에서 볼 수 있어야 합니다.

Merge Request 제목 리뷰

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

Merge Request을 Merge하기 전에 제목을 확인하고 CHANGELOG.md 파일에 명확하지 않을 것으로 생각된다면 업데이트하세요. 변경 로그에는 Merge Request 설명, 토론 또는 보다 많은 맥락을 제공하는 차이가 없는 이 한 줄만 포함될 것이라는 것을 명심하세요.

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

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

yml to yaml은 새로운 버전으로 업데이트하기 전에 변경 로그를 검토하는 GitLab Runner 관리자에게 무엇을 알려줄까요? 업데이트의 위험성, 구현된 동작 변경, 추가된 새로운 동작/기능이 표시됩니까? Merge Request과 해당 제목을 검토할 때 이러한 질문들을 기억하세요.

기여자는 위의 정보를 알지 못할 수 있으며, 그들의 제목이 우리의 요구 사항과 일치하지 않을 수 있습니다. 기여자에게 이에 대해 교육해보려고 노력해보세요.

마지막으로, Merge Request이 Merge되기 전에 제목을 검증하고 업데이트하는 것은 여러분의 책임입니다.

Merge Request 라벨 리뷰

Merge Request에 할당된 라벨을 사용하여 변경 로그 항목을 다른 그룹으로 그룹화하고 개별 항목의 특별한 기능을 정의합니다.

변경 로그 생성에는 우리 자체 Changelog generator를 사용합니다. 이 도구는 GitLab Runner 리포지터리에 커밋된 구성 파일을 사용합니다.

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

  • GitLab Changelog은 label_matchers가 정의된 순서대로 Merge Request 라벨을 분석합니다. 매칭된 범주 중 첫 번째로 일치하는 범위가 분석 대상 Merge Request에 사용됩니다.

    예를 들어, security 및 bug 라벨을 포함하는 첫 번째 Merge Request과 bug 라벨만 포함하는 두 번째 Merge Request이 있고, 다음과 같이 세 가지 매처를 정의했을 때 [security, bug] -> [security] -> [bug], 첫 번째 Merge Request은 [security, bug]로 일치하는 범위 (즉, 디렉터리에서 첫 번째로 정의된 것)에 추가될 것이며, 두 번째 Merge Request은 [bug]로 일치하는 범위 (즉, 디렉터리에서 마지막으로 정의된 범주)에 추가될 것입니다.

  • authorship_labels에서 정의된 라벨이 할당된 Merge Request은 해당 저자의 사용자 이름이 끝에 추가됩니다. Merge Request에 모든 authorship_labels 라벨이 추가되어야만 이와 같이 표시됩니다.

  • skip_changelog_labels에서 정의된 라벨이 할당된 Merge Request은 변경 로그에서 건너뛰어집니다. Merge Request이 건너뛰어지려면 모든 skip_changelog_labels 라벨이 해당 Merge Request에 추가되어야 합니다.

  • 정의된 label_matchers를 만족시키지 못하는 Merge Request은 다른 변경 사항 범주에 추가됩니다.

이 모든 사항을 고려하면 Merge Request을 Merge할 때 다음 몇 가지 규칙을 따르세요:

  • GitLab Runner 또는 해당 부분이 배포되는 방법과 관련된 모든 Merge Request은 runner-distribution 라벨이 지정되어야 합니다.

  • 보안과 관련된 모든 Merge Request(새로운 기능 또는 버그 수정 모두)은 security 라벨을 가져야 합니다. feature::addition이 아닌 모든 Merge Request은 보안 범주에 추가됩니다.

  • 버그 수정 Merge Request은 bug 라벨을 가져야 합니다.

  • 문서 업데이트만이 아니거나 명시적으로 버그 수정이 아닌 대부분의 Merge Request에서 feature:: 또는 tooling:: 라벨 중 하나가 추가되었는지 확인하세요. 이는 변경 로그 항목을 올바르게 정렬하는 데 도움이 됩니다.

  • 기술적 문서 검토가 완료된 경우에도 documentation 라벨이 자동으로 추가됩니다. 문서 업데이트뿐만 아니라 다른 내용이 업데이트된 경우에도입니다. Merge Request에 documentation 라벨만 있고 정의된 label_matchers에 해당하는 다른 라벨이 없는 경우에는 업데이트할 내용이 문서 업데이트뿐인지 반드시 확인하세요!

  • 동일한 릴리스 주기 내에 Merge 및 되돌림하는 경우, 원래 Merge Request과 되돌림 Merge Request에 skip_changelog_labels에 정의된 라벨을 지정하세요. 이는 릴리스 관리자가 릴리스를 준비할 때 매뉴얼 작업을 줄일 것입니다. 동일한 버전에서 변경 사항을 추가하고 해당 변경 사항을 되돌릴 경우, 이 두 이벤트에 대한 항목을 추가하면 안 됩니다.

    이미 릴리스된 GitLab Runner 버전에서 어떤 것을 되돌리는 경우, 단지 해당 범위 라벨로 Merge Request에 라벨을 지정하세요. 그 경우에는 변경 로그에 되돌리는 것으로 표시하고 싶습니다.

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

Summary

친애하는 리뷰어, 당신은 검을 갖고 있습니다. 이제 용과 싸우러 가십시오!