• 병합 요청의 Danger 코멘트
  • 장점
  • 단점
• 로컬에서 Danger 실행
• 운영
• 개발 가이드라인
  • Danger 사용 시기
  • 구현 세부 사항
    • Danger를 통해 레이블 추가
    • 공유된 규칙 및 플러그인
    • 프로젝트에서 Danger 활성화하기
• 현재 사용 사례
• 제약 사항
  • 개인 포크용으로 Danger 구성하기

Danger bot

GitLab CI/CD 파이프라인에는 danger-review 작업이 포함되어 있으며 Danger를 사용하여 테스트 중인 코드에 대한 다양한 자동화된 검사를 수행합니다.

Danger는 CI 환경에서 실행되는 일반적인 분석 도구와 같이 동작하는 gem입니다. 예를 들어 RuboCop과는 다르게, 코드나 변경 사항의 속성을 테스트하는 임의의 코드를 쉽게 작성할 수 있도록 설계되었습니다. 따라서 일반적인 도우미 세트와 환경의 변경 사항에 대한 정보에 액세스할 수 있도록하고 코드를 실행합니다.

만약 Danger가 병합 요청에 대해 변경 사항을 요청한다면, 변경 사항을 가장 좋은 방법으로 적용하는 것이 좋습니다. Danger가 작동하는 방법을 배우거나 기존 규칙을 변경하려면 이 문서를 참조하세요.

병합 요청의 Danger 코멘트

Danger는 오직 하나의 코멘트만 게시하고 후속 danger-review 실행에서 해당 코멘트를 업데이트합니다. 따라서 일반적으로 병합 요청의 처음 몇 개 코멘트 중 하나입니다. 보이지 않는다면, 병합 요청의 시작 부분을 찾아보세요.

장점

• danger-review가 실행될 때마다 이메일 알림을 받지 않습니다.

단점

• Danger가 이전 코멘트를 업데이트한다는 사실이 명확하지 않으므로 업데이트된 여부에 주의해야 합니다.
• Danger 토큰이 회전되면 오래된 코멘트를 업데이트할 수 없어 혼란과 혼잡을 초래합니다.

로컬에서 Danger 실행

현재 검사의 일부는 다음 Rake 작업을 사용하여 로컬에서 실행할 수 있습니다.

bin/rake danger_local

운영

시작할 때 Danger는 프로젝트 루트에서 Dangerfile을 읽습니다. GitLab에서의 Danger 코드는 danger/ 하위 디렉토리 내에 있는 일련의 도우미 및 플러그인으로 분해되어 있으므로 우리 코드는 모두 이를 로드하도록 Danger에 지시합니다. 그 후, Danger는 각 플러그인을 병합 요청에 대해 실행하고 각각의 출력물을 수집합니다. 플러그인은 알림, 경고 또는 오류를 출력할 수 있으며, 해당 모든 것이 CI 작업 로그에 복사됩니다. 오류가 발생하면 CI 작업(따라서 전체 파이프라인)이 실패합니다.

병합 요청에서, Danger는 또한 출력을 MR의 코멘트로 복사하여 가시성을 높입니다.

개발 가이드라인

Danger 코드는 Ruby 코드이므로 통상적인 백엔드 가이드라인이 계속 적용됩니다. 그러나 특별히 강조해야 할 몇 가지 사항이 있습니다.

Danger 사용 시기

Danger는 강력하고 유연한 도구이지만, 항상 주어진 문제나 워크플로우를 해결하기에 가장 적합한 방법은 아닙니다.

먼저, GitLab의 사용성 검증에 주목하세요. Danger용으로 작성하는 코드는 GitLab에 특화되어 있으며, 우리가 만난 필요를 해결하는 가장 적절한 장소가 아닐 수 있습니다. 결국, 우리 사용자, 고객 및 심지어 Gitaly와 같은 자사의 위성 프로젝트들도 종종 유사한 도전에 직면합니다. 모두가 해당 작업의 이익을 누리도록 보장하면서 동일한 필요를 충족시킬 수 있는 방법에 대해 고려하세요. 가능하다면 그렇게 하세요.

특정 작업에 대해 표준 도구(예: RuboCop)가 존재하는 경우, Danger를 사용하는 대신 직접 사용하는 것이 좋습니다. Danger를 사용하지 않고 로컬에서 해당 도구를 실행하고 디버깅하는 것이 더 쉽습니다. Danger 특정 기능을 사용하지 않는 한, Danger를 포함시키는 것에 이득은 없습니다.

Danger는 프로토타입 제작과 솔루션을 빠르게 반복하는 데 적합합니다. 따라서 구축하려는 것이 명확하지 않다면, Danger의 솔루션은 제품 영역에 대한 정보를 수집하기 위한 시도로 생각할 수 있습니다. 이렇게 하는 경우, 진행 중에 문제와 그 프로토타이핑의 결과를 이슈 또는 에픽에 기록해야 합니다. 이는 우리가 미래 버전의 GitLab에서 제품의 일부로 해당 필요를 해결할 수 있도록 도와줍니다!

구현 세부 사항

각 작업은 기능의 분리된 조각으로 구현하고 danger/<작업명>/Dangerfile로서 자체 디렉토리에 배치합니다.

각 작업은 다른 작업과 격리되어야 하며 독립적으로 작동할 수 있어야 합니다. 여러 작업 사이에서 공유해야 하는 코드가 있는 경우, danger/plugins/...에 플러그인을 추가하고 필요한 각 작업에서 그것을 요청하세요. 또한 해당 작업에 관련된 복잡한 로직을 자연스럽게 담을 수 있는 곳인 개별 작업에 특화된 플러그인을 만들 수 있습니다.

Danger 코드는 단순히 루비 코드입니다. 우리의 코딩 표준을 준수해야 하며, 다른 코드와 마찬가지로 테스트가 필요합니다. 그러나 Dangerfile을 직접 테스트할 수는 없습니다! 따라서 테스트 커버리지를 최대화하기 위해 danger/의 코드 라인 수를 최소화하는 것이 좋습니다. 복잡한 Dangerfile은 대부분 Danger에서 제공하는 메소드에서 유도된 인수를 이용하여 플러그인 코드를 호출해야 합니다. 플러그인 코드 자체에 대한 단위 테스트가 있어야 합니다.

현재, 이 기능은 tooling/danger/...에 코드를 넣고 해당 코드를 일치하는 danger/plugins/... 파일에 포함시킴으로써 수행합니다. 그런 다음 spec/tooling/danger/...에 스펙을 추가할 수 있습니다.

귀하의 Dangerfile이 작동하는지 여부를 결정하려면 해당 파일이 포함된 브랜치를 GitLab에 푸시하세요. 이 작업은 새로운 작업을 개발하거나 기존 작업을 디버깅하려는 경우 주요 사이클 시간을 상당히 증가시키므로 다소 실망스러울 수 있습니다. 위에서 제시된 가이드라인을 따랐다면, 대부분의 코드는 로컬에서 RSpec으로 실행할 수 있으므로 CI에서 거쳐야 하는 사이클 수를 최소화할 수 있습니다. 그러나 MR에 있는 .gitlab/ci/rails.gitlab-ci.yml 파일을 비워둠으로써 이러한 사이클을 다소 빠르게 할 수 있습니다. 다만 병합하기 전에 변경 사항을 되돌리는 것을 잊지 마세요!

Danger를 통해 레이블 추가

Danger는 종종 Dangerfile을 사용하여 MR 허위를 개선하는 데 사용됩니다. Dangerfile에서 API를 직접 호출하는 대신, helper.labels_to_add 배열에 레이블을 추가하면 (helper.labels_to_add << label 또는 helper.labels_to_add.concat(array_of_labels)) gitlab-dangerfiles가 모든 규칙이 helper.labels_to_add에 추가하도록 한 다음에 MR에 레이블을 추가합니다.

공유된 규칙 및 플러그인

구현한 규칙이나 플러그인이 다른 프로젝트에 유용하다면 gitlab-dangerfiles 프로젝트에 추가하는 것을 고려해 보세요.

프로젝트에서 Danger 활성화하기

기존 GitLab 프로젝트에 Dangerfile을 활성화하려면 다음 단계를 완료하세요:

1. Gemfile에 gitlab-dangerfiles을 추가합니다.

2. 다음 내용으로 Dangerfile을 작성합니다.

   require "gitlab-dangerfiles"
   
   Gitlab::Dangerfiles.for_project(self, &:import_defaults)
   

3. 다음을 CI/CD 구성에 추가합니다.

   include:
     - component: ${CI_SERVER_FQDN}/gitlab-org/components/danger-review/danger-review@1.2.0
       rules:
         - if: $CI_SERVER_HOST == "gitlab.com"
   

4. api 범위, Developer 권한(레이블을 추가할 수 있도록), 만료 날짜 없음(실제로 1년을 의미)으로 프로젝트 액세스 토큰을 생성합니다.
5. DANGER_GITLAB_API_TOKEN이라는 CI/CD 프로젝트 변수로 토큰을 추가합니다.

병합 요청을 보내기 전에 ~"Danger bot" 레이블을 추가해야 합니다.

현재 사용 사례

지금까지 GitLab에서 Danger가 사용된 사용 사례(비내구성 목록)입니다:

• 코딩 스타일
• 데이터베이스 검토
• 문서 검토
• 병합 요청 지표
• 심사원 룰렛
• 단일 코드베이스 노력

제약 사항

개인 포크에서 작업하는 경우 Danger는 실행되지만 출력이 병합 요청 코멘트에 추가되지 않고 레이블이 적용되지 않습니다. 이는 대개의 프로젝트에서의 비밀 변수가 포크로 공유되지 않기 때문에 발생합니다.

가장 좋고 권장하는 방법은 커뮤니티 포크에서 작업하는 것입니다.

개인 포크용으로 Danger 구성하기

기여자는 다음 단계로 자신의 포크에 Danger를 구성할 수 있습니다:

1. api 범위가 설정된 개인 API 토큰을 생성합니다(클립보드에 복사하는 것을 잊지 마세요).
2. 포크에 이전 단계에서 복사한 토큰으로 DANGER_GITLAB_API_TOKEN이라는 프로젝트 CI/CD 변수를 추가합니다.
3. 변수를 가리기로 설정하여 작업 로그에 표시되지 않도록 합니다. 이 변수는 모든 브랜치에 대해 필요하기 때문에 보호 상태로 설정할 수 없습니다.