Danger 봇

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

Danger는 기타 분석 도구와 마찬가지로 CI 환경에서 실행되는 gem입니다. (예를 들어 RuboCop과 같은) 일반적인 도구와 달리 Danger는 코드 또는 변경 사항의 속성을 테스트하기 위한 임의의 코드를 쉽게 작성할 수 있도록 설계되었습니다. 이를 위해 Danger는 일련의 일반적인 도우미와 환경에서 실제로 변경된 정보에 대한 액세스를 제공하고 코드를 실행합니다!

만약 Danger가 Merge Request에 대해 어떤 변경 사항을 요청한다면 해당 변경을 가장 쉽게 수락하는 것이 좋습니다. Danger가 작동하는 방식을 배우거나 기존 규칙을 변경하려면 이 문서가 적합합니다.

Merge Request에서의 Danger 코멘트

Danger는 단 하나의 코멘트를 게시하고 이후의 danger-review 실행에서 해당 코멘트의 내용을 업데이트합니다. 이에 따라, 이는 일반적으로 Merge Request에서 처음 몇 개의 코멘트 중 하나이며 첫 번째 코멘트일 수도 있습니다. 이를 못 봤다면 Merge Request의 시작부터 살펴보시기 바랍니다.

장점

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

단점

  • 예전 코멘트를 업데이트하는 방식이 명시적이지 않으므로 업데이트되었는지에 대해 주의를 기울여야 합니다.
  • Danger 토큰이 회전되면 이는 혼란 및 혼란을 야기합니다 (예전 코멘트를 업데이트할 수 없음).

로컬에서 Danger 실행하기

현재의 일부 확인 사항은 다음 Rake 작업을 사용하여 로컬에서 실행할 수 있습니다: 

bin/rake danger_local

운영

시작할 때, Danger는 프로젝트 루트에서 Dangerfile을 읽습니다. GitLab의 Danger 코드는 모두 danger/ 하위 디렉터리에 포함된 도우미 및 플러그인으로 분해되므로 우리의 Danger는 이 모두를 로드하도록 Danger에 지시합니다. 그런 다음, Danger는 각 플러그인을 Merge Request에 실행하여 각각의 출력을 수집합니다. 플러그인은 알림, 경고 또는 오류를 출력할 수 있으며, 이는 모두 CI 작업 로그로 복사됩니다. 오류가 발생하면 CI 작업(그리고 따라서 전체 파이프라인)이 실패합니다.

Merge Request에서 Danger는 또한 출력을 MR의 코멘트에 복사하여 시각성을 높입니다.

개발 가이드라인

Danger 코드는 Ruby 코드이므로 평소의 백엔드 가이드라인을 계속 적용합니다. 그러나 특별한 강조가 필요한 몇 가지 사항이 있습니다.

Danger를 사용해야 하는 경우

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

먼저, GitLab의 자체 사용에 대한 헌신을 인식하세요. 우리가 Danger를 위해 작성하는 코드는 GitLab에 특화되어 있으며, 우리가 직면한 필요를 해결하는 기능을 구현하기 가장 적합한 곳이라는 보장은 없습니다. 결국, 우리 사용자, 고객, 그리고 우리 자신의 Gitaly와 같은 위성 프로젝트들도 종종 유사한 도전에 직면합니다. 모든 사람들이 해당 작업에서 혜택을받을 수 있도록 작업을 수행하는 방법에 대해 고려하고 가능하다면 그것을 다른 방법으로 수행하세요.

작업에 대한 표준 도구(예를 들어 RuboCop)가 존재하는 경우에는, Danger를 사용하는 대신 직접 사용하는 것이 더 좋습니다. Danger를 사용하지 않고 해당 도구의 결과를 로컬에서 실행하고 디버깅하는 것이 쉽습니다. Danger 특정 기능을 사용하지 않는 한, Danger를 포함하는 것에 이익은 없으며, 이럴 경우에는 해당 도구를 호출하는 것이 더 좋습니다.

Danger는 프로토타입 프로덕션 및 솔루션에 대한 빠른 반복에 적합하므로 구축하려는 것이 불명확한 경우, Danger에서의 해결책은 제품 영역에 대한 정보를 수집하기 위한 시도로 볼 수 있습니다. 이를 수행하는 경우, 해결하려는 문제 및 해당 프로토타입의 결과를 작업 중에 이슈 또는 에픽에 포착하여야 합니다. 이는 GitLab의 향후 버전에서 제품의 일부로 해당 필요를 해결하는 데 도움이 됩니다!

구현 세부 정보

각 작업을 독립된 기능 조각으로 구현하고 danger/<task-name>/Dangerfile로 자체 디렉터리에 배치합니다.

각 작업은 다른 작업들로부터 격리되어야 하며 독립적으로 기능하도록하여야 합니다. 여러 작업 사이에서 공유되어야하는 코드가 있을 경우, danger/plugins/...에 플러그인을 추가하고 필요로하는 각 작업에서 이를 요구하시기 바랍니다. 또한 해당 작업에 관련된 복잡한 로직을 자연스럽게 포함하는 하나의 단일 작업에 대한 특정 플러그인을 생성할 수도 있습니다.

Danger 코드는 그냥 Ruby 코드입니다. 우리 코드베이스에서의 다른 Ruby 작업과 마찬가지로 우리의 코딩 표준에 준수해야하며, 다른 Ruby 코드 조각과 마찬가지로 테스트가 필요합니다. 그러나 우리는 직접 Dangerfile을 테스트할 수 없습니다! 따라서 테스트 커버리지를 극대화하기 위해 danger/에 있는 코드 라인의 수를 최소화하도록 노력하십시오. 복잡하지 않은 Dangerfile은 주로 Danger에서 제공하는 메소드로부터 유도된 인수를 사용하여 플러그인 코드를 호출해야합니다. 플러그인 코드 자체는 단위 테스트가 있어야합니다.

현재 우리는 이를 수행하기 위해 tooling/danger/...에 코드를 배치하고 해당 일치하는 danger/plugins/... 파일에 포함합니다. 그런 다음 spec/tooling/danger/...에 스펙을 추가할 수 있습니다.

귀하의 Dangerfile이 작동하는지 확인하려면 해당 파일이 포함된 브랜치를 GitLab에 푸시하여야합니다. 새로운 작업을 개발하거나 기존 작업에 대해 디버깅하는 경우, 이는 사이클 타임을 상당히 늘리므로 꽤 손이 가는 작업일 수 있습니다. 위의 가이드라인을 따랐다면 대부분의 코드는 로컬에서 RSpec에서 실행할 수 있으므로 CI에서 여러 번 검사를 수행할 필요성을 최소화할 수 있습니다. 그러나 해당 사이클을 어느 정도 빠르게 진행할 수도 있으므로, 당사의 .gitlab/ci/rails.gitlab-ci.yml 파일을 비울 수 있습니다. 그때는 Merge Request 전에 수정을 되돌리지 않도록 주의하십시오!

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에 추가할 레이블을 가져가고 나서 단일 API 호출로 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:
  - project: 'gitlab-org/quality/pipeline-common'
    file:
      - '/ci/danger-review.yml'
    rules:
      - if: $CI_SERVER_HOST == "gitlab.com"
  4. api 스코프, Developer 권한(레이블을 추가할 수 있도록) 및 만료 날짜 없음(실제로 1년을 의미함)을 가진 프로젝트 접근 토큰을 생성하십시오.
  5. DANGER_GITLAB_API_TOKEN이라는 CI/CD 프로젝트 변수로 해당 토큰을 추가하십시오.

관련 MR을 리뷰하기 전에 Merge Request에 ~"Danger 봇" 레이블을 추가하십시오.

현재 사용 사례

다음은 GitLab에서 Danger가 지금까지 사용된 사례의 (불완전한) 디렉터리입니다:

  • 코딩 스타일
  • 데이터베이스 검토
  • 문서 검토
  • Merge Request 지표
  • 리뷰어 룰렛
  • 단일 코드베이스 작업

제약 사항

개인 포크에서 작업하는 경우 Danger가 실행되지만 그 출력물이 Merge Request 코멘트에 추가되지 않고 레이블이 적용되지 않습니다. 이는 근본 프로젝트의 시크릿 변수가 포크로 공유되지 않기 때문에 발생합니다.

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

개인 포크용 Danger 구성

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

  1. api 스코프가 설정된 개인 API 토큰을 생성합니다 (클립보드에 복사하는 것을 잊지 마세요).
  2. 포크에서 앞서 복사한 토큰을 가진 프로젝트 CI/CD 변수인 DANGER_GITLAB_API_TOKEN을 추가합니다.
  3. 변수를 마스킹하여 작업 로그에 표시되지 않도록 합니다. 변수는 모든 브랜치에 대해 필요하기 때문에 보호되지 않아야 합니다.