Danger bot

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

Danger는 다른 분석 도구와 마찬가지로 CI 환경에서 실행되는 gem입니다. 예를 들어 RuboCop과는 다르게 코드나 변경 사항의 속성을 테스트하기 위해 임의의 코드를 쉽게 작성할 수 있도록 설계되었습니다. 이를 위해 일반적인 도우미 세트와 환경에서 실제로 변경된 내용에 대한 정보에 접근한 후 코드를 실행합니다.

만약 Danger가 Merge Request에 대해 무언가를 변경하도록 요청한다면, 변경 사항을 가하는 것이 가장 좋습니다. Danger가 어떻게 작동하는지 알고 싶거나 기존 규칙을 변경하려면 이 문서가 도움이 됩니다.

Merge Request에서의 Danger 코멘트

Danger는 단 하나의 코멘트를 올리고 이후의 danger-review 실행에서 내용을 업데이트합니다. 따라서 보통 Merge Request에서 처음 몇 개의 코멘트 중 하나이며, 아니면 첫 번째입니다. 만약 보이지 않는다면, Merge Request의 시작 부분부터 확인해보세요.

장점

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

단점

  • Danger가 이전 코멘트를 업데이트한다는 사실이 명확하지 않으므로, 업데이트 되었는지에 대해 주의를 기울여야 합니다.
  • Danger 토큰이 회전되면 (이전 코멘트를 업데이트할 수 없기 때문에) 혼란이나 지저분함을 야기합니다.

Danger 로컬에서 실행하기

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

bin/rake danger_local

운영

시작 시, Danger는 프로젝트 루트에서 Dangerfile을 읽습니다. GitLab의 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 코드 조각과 마찬가지로 저희 코딩 규칙을 준수해야 합니다. 그러나 Dangerfile을 직접 테스트할 수 없습니다! 따라서 테스트 범위를 최대화하기 위해 danger/에서 코드 줄 수를 최소화하려고 노력해야 합니다. 비단순한 Dangerfile은 대부분 Danger에서 제공하는 메서드를 통해 파생된 인자를 사용하여 플러그인 코드를 호출해야 합니다. 플러그인 코드 자체는 단위 테스트가 있어야 합니다.

현재 이를 tooling/danger/... 모듈에 코드를 넣고 일치하는 danger/plugins/... 파일에 포함함으로써 수행합니다. 스펙은 spec/tooling/danger/...에 추가할 수 있습니다.

자신의 Dangerfile이 작동하는지 확인하려면 해당 파일을 포함하는 브랜치를 GitLab에 푸시하세요. 이 작업은 새로운 작업을 개발하거나 기존 작업을 디버깅하려고 할 때 사이클 시간을 크게 늘리므로 꽤 괴로울 수 있습니다. 위의 지침을 따랐다면 대부분의 코드를 로컬에서 RSpec에서 실행하여 CI에서 거친 작업을 최소화할 수 있습니다. 그러나 MR에서 .gitlab/ci/rails.gitlab-ci.yml 파일을 비워 빠르게 실행할 수 있습니다. 단지 Merge하기 전에 이 변경 사항을 되돌리지 않도록 주의하세요!

Danger를 통한 레이블 추가

note
이것은 gitlab-dangerfiles gem을 사용하는 모든 프로젝트에 적용됩니다.

Danger는 종종 gitlab-dangerfiles gem을 사용하여 MR 정리를 향상시킵니다. Dangerfile에서 API를 직접 호출하는 대신, helper.labels_to_add 배열에 레이블을 추가하세요 (helper.labels_to_add << label 또는 helper.labels_to_add.concat(array_of_labels)). 모든 규칙이 helper.labels_to_add에 추가한 후 gitlab-dangerfiles가 한 번의 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 변수로 토큰을 추가합니다.

Merge Request을 검토하기 전에 ~"Danger bot" 레이블을 추가해야 합니다.

현재 사용 사례

지금까지 GitLab에서 Danger가 사용된 사례(전부가 아님)는 다음과 같습니다:

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

제한 사항

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

가장 좋고 권장되는 접근 방식은 이미 Danger가 구성된 커뮤니티 포크에서 작업하는 것입니다.

개인 포크용 Danger 구성

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

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