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의 개요 탭에서, 파이프라인 결과 아래 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로 리디렉션하여 보고서를 저장하는 곳으로 이동할 것입니다.

이 커버리지 데이터는 또한 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 변경 로그는 label_matchers가 정의된 순서대로 Merge Request 레이블을 분석합니다. 첫 번째 일치하는 범위가 분석된 Merge Request에 사용됩니다.

    예를 들어, 두 개의 Merge Request이 있고, 첫 번째는 security와 bug 레이블을 포함하고 두 번째는 bug 레이블만 포함한다고 가정하면, 순서가 이와 같이 정의된 세 개의 일치 항목이 있다면: [security, bug] -> [security] -> [bug], 그렇다면 첫 번째 Merge Request은 [security, bug]에 일치하는 범위(즉, 디렉터리에서 첫 번째로 정의된 범위)에 추가되고, 두 번째 Merge Request은 [bug]에 일치하는 범위(즉, 디렉터리에서 마지막으로 정의된 범위)에 추가됩니다.

  • authorship_labels에서 정의된 레이블이 지정된 Merge Request은 변경 로그에 사용자명이 끝에 추가됩니다. 이러한 경우 모든 authorship_labels 레이블이 Merge Request에 추가되어야 합니다.

  • skip_changelog_labels에서 정의된 레이블이 지정된 Merge Request은 변경 로그에서 건너뜁니다. 건너뛰기위해서 모든 skip_changelog_labels 레이블이 Merge Request에 추가되어야 합니다.

  • 정의된 label_matchers와 일치하지 않는 Merge Request은 Other changes 범위 버킷에 추가됩니다.

모든 이것을 염두에 두면, Merge Request을 하는 동안 다음 몇 가지 규칙을 따르십시오:

  • 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에 정의된 레이블을 지정하세요. 이렇게 하면 릴리스 관리자가 릴리스를 준비할 때 매뉴얼 작업이 줄어듭니다. 동일한 버전에서 변경 사항을 추가하고 되돌리는 변경 사항에 대한 항목은 추가하지 않아야 합니다.

    되돌리기 Merge Request이 이미 릴리스된 GitLab Runner 버전에 속한 것을 되돌리는 경우, 적절한 범위 레이블을 지정하도록 만드세요. 이 경우에는 변경 로그에 되돌림을 표시하려고 합니다.

  • 마지막으로, Engineering metrics data classification 페이지를 읽어보고, 특정 레이블을 사용해야 하는 시기에 대한 일부 지침을 확인하십시오.

요약

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