InfoGrab Docs

GitLab Runner 리뷰하기

요약

이 문서는 GitLab Runner 프로젝트 리뷰어를 위한 규칙과 제안 사항을 담고 있습니다. 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. 머지 리퀘스트의 Overview 탭에서 파이프라인 결과 아래의 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 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와 일치하지 않는 머지 리퀘스트는 Other changes 범위 버킷에 추가됩니다.

이 모든 것을 염두에 두고, 머지 리퀘스트를 머지할 때 다음 몇 가지 규칙을 따르세요:

  • GitLab Runner 또는 그 부분이 배포되는 방식과 관련된 모든 머지 리퀘스트에는 runner-distribution 레이블을 붙여야 합니다.

  • 새 기능이든 버그 수정이든 보안과 관련된 모든 머지 리퀘스트에는 security 레이블이 있어야 합니다. feature::addition이 아닌 모든 머지 리퀘스트는 보안 범위에 추가됩니다.

  • 모든 버그 수정 머지 리퀘스트에는 bug 레이블이 있어야 합니다.

  • 문서 업데이트만이거나 명시적으로 버그 수정이 아닌 대부분의 머지 리퀘스트에서 feature:: 또는 tooling:: 레이블 중 하나가 추가되어 있는지 확인하세요. 이는 변경 로그 항목을 적절히 정렬하는 데 도움이 됩니다.

  • documentation 레이블은 Technical Writing 리뷰가 완료될 때 자동으로 추가됩니다. 머지 리퀘스트가 문서만이 아닌 다른 것도 업데이트할 때도 마찬가지입니다. 머지 리퀘스트에 documentation 레이블만 있고 정의된 label_matchers 중 어떤 것과도 일치하는 다른 레이블이 없다면 - 머지 리퀘스트가 문서만 업데이트하는지 다시 확인하세요. 그렇지 않으면 추가되는 변경 유형과 일치하는 특정 레이블 중 하나를 사용하세요!

  • 동일한 릴리스 사이클 동안 머지된 변경 사항을 되돌릴 때는 원래 머지 리퀘스트와 되돌린 머지 리퀘스트 모두에 skip_changelog_labels에 정의된 레이블을 붙이세요. 이렇게 하면 릴리스 매니저가 릴리스를 준비할 때 해야 하는 수동 작업이 줄어듭니다. 두 이벤트가 동일한 버전에서 발생한 경우 변경 사항 추가와 변경 사항 되돌리기에 대한 항목을 추가해서는 안 됩니다.

    되돌린 머지 리퀘스트가 이미 릴리스된 버전의 GitLab Runner에 머지된 것을 되돌리는 경우에는, 올바른 범위 레이블을 붙이기만 하면 됩니다. 그 경우에는 변경 로그에서 되돌리기를 표시하고자 합니다.

  • 특정 레이블을 사용해야 하는 시기에 대한 지침을 제공하는 Engineering metrics data classification 페이지를 잠시 읽어보세요.

요약#

리뷰어 여러분, 검을 갖게 되었습니다. 이제 용과 싸우러 가세요!

GitLab Runner 리뷰하기

원문 보기
요약

이 문서는 GitLab Runner 프로젝트 리뷰어를 위한 규칙과 제안 사항을 담고 있습니다. 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. 머지 리퀘스트의 Overview 탭에서 파이프라인 결과 아래의 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 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와 일치하지 않는 머지 리퀘스트는 Other changes 범위 버킷에 추가됩니다.

이 모든 것을 염두에 두고, 머지 리퀘스트를 머지할 때 다음 몇 가지 규칙을 따르세요:

  • GitLab Runner 또는 그 부분이 배포되는 방식과 관련된 모든 머지 리퀘스트에는 runner-distribution 레이블을 붙여야 합니다.

  • 새 기능이든 버그 수정이든 보안과 관련된 모든 머지 리퀘스트에는 security 레이블이 있어야 합니다. feature::addition이 아닌 모든 머지 리퀘스트는 보안 범위에 추가됩니다.

  • 모든 버그 수정 머지 리퀘스트에는 bug 레이블이 있어야 합니다.

  • 문서 업데이트만이거나 명시적으로 버그 수정이 아닌 대부분의 머지 리퀘스트에서 feature:: 또는 tooling:: 레이블 중 하나가 추가되어 있는지 확인하세요. 이는 변경 로그 항목을 적절히 정렬하는 데 도움이 됩니다.

  • documentation 레이블은 Technical Writing 리뷰가 완료될 때 자동으로 추가됩니다. 머지 리퀘스트가 문서만이 아닌 다른 것도 업데이트할 때도 마찬가지입니다. 머지 리퀘스트에 documentation 레이블만 있고 정의된 label_matchers 중 어떤 것과도 일치하는 다른 레이블이 없다면 - 머지 리퀘스트가 문서만 업데이트하는지 다시 확인하세요. 그렇지 않으면 추가되는 변경 유형과 일치하는 특정 레이블 중 하나를 사용하세요!

  • 동일한 릴리스 사이클 동안 머지된 변경 사항을 되돌릴 때는 원래 머지 리퀘스트와 되돌린 머지 리퀘스트 모두에 skip_changelog_labels에 정의된 레이블을 붙이세요. 이렇게 하면 릴리스 매니저가 릴리스를 준비할 때 해야 하는 수동 작업이 줄어듭니다. 두 이벤트가 동일한 버전에서 발생한 경우 변경 사항 추가와 변경 사항 되돌리기에 대한 항목을 추가해서는 안 됩니다.

    되돌린 머지 리퀘스트가 이미 릴리스된 버전의 GitLab Runner에 머지된 것을 되돌리는 경우에는, 올바른 범위 레이블을 붙이기만 하면 됩니다. 그 경우에는 변경 로그에서 되돌리기를 표시하고자 합니다.

  • 특정 레이블을 사용해야 하는 시기에 대한 지침을 제공하는 Engineering metrics data classification 페이지를 잠시 읽어보세요.

요약#

리뷰어 여러분, 검을 갖게 되었습니다. 이제 용과 싸우러 가세요!