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는 각 플러그인을 병합 요청에 대해 실행하고 각각의 출력을 수집합니다. 플러그인은 알림, 경고 또는 오류를 출력할 수 있으며, 모든 것들은 CI 작업 로그로 복사됩니다. 만약 오류가 발생하면 CI 작업(따라서 전체 파이프라인)이 실패합니다.

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

개발 지침

Danger 코드는 Ruby 코드이므로 모든 표준 백엔드 지침이 계속 적용됩니다. 그러나 특별히 강조되어야 할 몇 가지 사항이 있습니다.

Danger 사용 시기

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

먼저, GitLab이 Dogfooding에 헌신하는 것을 인식해야 합니다. 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에서 거치는 사이클을 줄일 수 있습니다. 그러나 해당 사이클을 어느 정도 속도를 올려줄 수 있습니다. 단, 병합 요청에서 .gitlab/ci/rails.gitlab-ci.yml 파일을 비워두면 됩니다. 단, 병합하기 전에 변경사항을 되돌리지 않도록 주의하세요!

Danger를 통한 라벨 추가

참고: gitlab-dangerfiles gem을 사용하는 모든 프로젝트에 적용됩니다.

Danger는 종종 MR(Merge Request)의 품질을 향상시키기 위해 라벨을 추가하는 데 사용됩니다. 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에 단일 API 호출로 추가합니다.

공유 규칙과 플러그인

구현하는 규칙 또는 플러그인이 다른 프로젝트에서 유용하다고 생각되면 gitlab-dangerfiles 프로젝트에 업스트림으로 추가하는 것을 고려해보세요.

프로젝트에서 Danger 활성화

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

Gemfile에 gitlab-dangerfiles를 추가하세요.

다음 내용으로 Dangerfile을 생성하세요:

require "gitlab-dangerfiles"

Gitlab::Dangerfiles.for_project(self, &:import_defaults)

다음을 CI/CD 구성에 추가하세요:

include:
  - project: 'gitlab-org/quality/pipeline-common'
    file:
      - '/ci/danger-review.yml'
    rules:
      - if: $CI_SERVER_HOST == "gitlab.com"

프로젝트 액세스 토큰을 생성하세요. api 스코프, Developer 권한(라벨 추가 가능) 및 만료 날짜 없음(실제로 1년을 의미)으로 설정하세요.
토큰을 DANGER_GITLAB_API_TOKEN이라는 CI/CD 프로젝트 변수로 추가하세요.

병합 요청을 검토하기 전에 ~"Danger bot" 라벨을 추가하세요.

현재 사용 사례

지금까지 GitLab에서 Danger가 사용된 것들의 (완전한 것이 아닌) 목록은 다음과 같습니다:

코딩 스타일
데이터베이스 검토
문서 검토
Merge request 메트릭
리뷰어 룰렛
단일 코드베이스 노력

제한 사항

개인 포크에서 작업하는 경우, Danger는 실행되지만 출력이 MR 코멘트에 추가되지 않으며 라벨이 적용되지 않습니다. 이는 정식 프로젝트의 시크릿 변수가 포크에 공유되지 않기 때문에 발생합니다.

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

개인 포크용 Danger 구성

기여자들은 개인 포크에서 다음 단계로 Danger를 구성할 수 있습니다:

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