InfoGrab DocsInfoGrab Docs

Danger bot

요약

GitLab CI/CD 파이프라인에는 danger-review job이 포함되어 있으며, 이 job은 Danger를 사용하여 테스트 중인 코드에 대해 다양한 자동 검사를 수행합니다. Danger는 다른 분석 도구와 마찬가지로 CI 환경에서 실행되는 gem입니다.

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

Danger는 다른 분석 도구와 마찬가지로 CI 환경에서 실행되는 gem입니다. Danger가 (예를 들어, RuboCop과) 다른 점은, 코드나 변경 사항의 속성을 테스트하기 위한 임의의 코드를 쉽게 작성할 수 있도록 설계되어 있다는 것입니다. 이를 위해 Danger는 공통 헬퍼 세트와 실제로 환경에서 변경된 내용에 대한 접근을 제공하고, 작성한 코드를 실행합니다!

Danger가 머지 리퀘스트에서 무언가를 변경하도록 요청하는 경우, 그 변경을 수행하는 것이 가장 좋습니다. Danger의 작동 방식을 이해하거나 기존 규칙을 변경하려는 경우, 이 문서가 도움이 됩니다.

머지 리퀘스트에서의 Danger 코멘트#

Danger는 코멘트를 하나만 게시하고, 이후 danger-review 실행 시 해당 내용을 업데이트합니다. 따라서, Danger 코멘트는 일반적으로 머지 리퀘스트의 첫 번째 또는 초기 몇 개의 코멘트 중 하나입니다. 코멘트를 찾을 수 없다면 머지 리퀘스트의 처음부터 확인해 보세요.

장점#

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

단점#

  • Danger가 기존 코멘트를 업데이트한다는 것이 명확하지 않으므로, 업데이트 여부에 주의를 기울여야 합니다.

  • Danger 토큰이 교체되면 혼란/복잡성이 생깁니다(이전 코멘트를 업데이트할 수 없기 때문입니다).

Danger 로컬 실행#

현재 검사 중 일부는 다음 Rake 태스크를 사용하여 로컬에서 실행할 수 있습니다:

bin/rake danger_local

동작 방식#

시작 시, Danger는 프로젝트 루트에서 Dangerfile을 읽습니다. GitLab의 Danger 코드는 danger/ 하위 디렉터리 내의 헬퍼와 플러그인 집합으로 분리되어 있으므로, 우리의 Dangerfile은 Danger에게 이를 모두 불러오도록 지시합니다. Danger는 각 플러그인을 머지 리퀘스트에 대해 실행하고, 각각의 출력을 수집합니다. 플러그인은 알림, 경고 또는 오류를 출력할 수 있으며, 이 모두는 CI job 로그에 복사됩니다. 오류가 발생하면 CI job(및 전체 파이프라인)이 실패합니다.

머지 리퀘스트의 경우, Danger는 MR 자체의 코멘트에도 출력을 복사하여 가시성을 높입니다.

개발 가이드라인#

Danger 코드는 Ruby 코드이므로, 모든 일반 백엔드 가이드라인이 계속 적용됩니다. 그러나 특별히 강조할 만한 몇 가지 사항이 있습니다.

Danger를 언제 사용해야 하는가#

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

먼저, GitLab의 dogfooding 원칙을 인지하세요. Danger를 위해 작성하는 코드는 GitLab에 특화되어 있으며, 우리가 직면하는 필요를 해결하는 기능을 구현하기에 가장 적합한 위치가 아닐 수 있습니다. 우리의 사용자, 고객, 그리고 Gitaly와 같은 우리 자체 위성 프로젝트들도 비슷한 과제에 직면하기 때문입니다. 모든 사람이 작업의 혜택을 받을 수 있도록 동일한 필요를 충족하는 방법을 생각해 보고, 가능하다면 그렇게 하세요.

표준 도구(예: RuboCop)가 작업에 존재하는 경우, Danger를 통해 호출하는 것보다 직접 사용하는 것이 낫습니다. Danger가 관여하지 않으면 해당 도구의 결과를 로컬에서 실행하고 디버깅하기가 더 쉬우며, Danger 전용 기능을 사용하지 않는 한 Danger 실행에 포함해도 이점이 없습니다.

Danger는 프로토타이핑과 솔루션의 빠른 반복에 적합하므로, 구축하고자 하는 것이 불분명한 경우 Danger의 솔루션을 제품 영역에 대한 정보를 수집하기 위한 시험 실행으로 생각할 수 있습니다. 이를 진행하는 경우, 해결하려는 문제와 프로토타이핑 결과를 이슈나 에픽에 계속 기록하세요. 이를 통해 향후 GitLab 버전에서 제품의 일부로 필요를 해결할 수 있습니다!

구현 세부 사항#

각 태스크를 독립된 기능 단위로 구현하고, danger/<task-name>/Dangerfile로 danger 디렉터리 내의 자체 디렉터리에 배치하세요.

각 태스크는 다른 태스크와 독립적이어야 하며, 독립적으로 기능할 수 있어야 합니다. 여러 태스크 간에 공유되어야 하는 코드가 있는 경우, danger/plugins/...에 플러그인을 추가하고 이를 필요로 하는 각 태스크에서 요구(require)하세요. 단일 태스크에 특화된 플러그인을 만들 수도 있으며, 이는 해당 태스크와 관련된 복잡한 로직을 위한 자연스러운 위치입니다.

Danger 코드는 단순히 Ruby 코드입니다. 코딩 표준을 준수해야 하며, 코드베이스의 다른 Ruby 코드와 마찬가지로 테스트가 필요합니다. 그러나 Dangerfile을 직접 테스트할 수는 없습니다! 따라서 테스트 커버리지를 최대화하려면 danger/의 코드 줄 수를 최소화하세요. 비trivial한 Dangerfile은 주로 Danger가 제공하는 메서드에서 파생된 인수로 플러그인 코드를 호출해야 합니다. 플러그인 코드 자체는 유닛 테스트를 갖추어야 합니다.

현재 우리는 tooling/danger/...의 모듈에 코드를 넣고, 이를 매칭되는 danger/plugins/... 파일에 포함시킵니다. 스펙(Spec)은 spec/tooling/danger/...에 추가할 수 있습니다.

Dangerfile이 작동하는지 확인하려면 해당 브랜치를 GitLab에 푸시하세요. 이는 새로운 태스크를 개발하거나 기존 태스크에서 무언가를 디버깅할 때 사이클 타임이 크게 증가하므로 상당히 불편할 수 있습니다. 위의 가이드라인을 따랐다면, 대부분의 코드를 RSpec에서 로컬로 실행할 수 있어 CI에서 거쳐야 하는 사이클 수를 최소화할 수 있습니다. 그러나 머지 리퀘스트에서 .gitlab/ci/rails.gitlab-ci.yml 파일을 비워두면 이러한 사이클을 어느 정도 빠르게 할 수 있습니다. 단, 머지하기 전에 해당 변경 사항을 되돌리는 것을 잊지 마세요!

Danger를 통한 라벨 추가#

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

Danger는 종종 라벨을 추가하여 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을 활성화하려면 다음 단계를 완료하세요:

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

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

require "gitlab-dangerfiles"

Gitlab::Dangerfiles.for_project(self, &:import_defaults)
  • CI/CD 구성에 다음을 추가하세요:
include:
  - component: ${CI_SERVER_FQDN}/gitlab-org/components/danger-review/danger-review@1.2.0
    rules:
      - if: $CI_SERVER_HOST == "gitlab.com"

  • api 스코프, Developer 권한(라벨을 추가할 수 있도록), 그리고 만료일 없음(실제로는 1년을 의미)으로 프로젝트 액세스 토큰을 생성하세요.

  • DANGER_GITLAB_API_TOKEN이라는 이름의 CI/CD 프로젝트 변수로 토큰을 추가하세요.

리뷰를 위해 머지 리퀘스트를 제출하기 전에 ~"Danger bot" 라벨을 해당 머지 리퀘스트에 추가해야 합니다.

현재 사용 사례#

다음은 GitLab에서 지금까지 Danger를 사용한 항목들의 (전체 목록은 아닌) 예시입니다:

  • 코딩 스타일

  • 데이터베이스 리뷰

  • 문서 리뷰

  • 머지 리퀘스트 메트릭

  • 리뷰어 룰렛

  • 단일 코드베이스 노력

알려진 이슈#

개인 포크에서 작업할 때 Danger는 실행되지만, 출력이 머지 리퀘스트 코멘트에 추가되지 않고 라벨도 적용되지 않습니다. 이는 정규 프로젝트의 시크릿 변수가 포크에 공유되지 않기 때문입니다.

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

개인 포크에서 Danger 구성하기#

기여자는 다음 단계를 통해 포크에서 Danger를 구성할 수 있습니다:

  • api 스코프가 설정된 개인 API 토큰을 생성하세요(클립보드에 복사하는 것을 잊지 마세요).

  • 포크에서, 이전 단계에서 복사한 토큰을 사용하여 DANGER_GITLAB_API_TOKEN이라는 프로젝트 CI/CD 변수를 추가하세요.

  • job 로그에 표시되지 않도록 변수를 마스킹하세요. 변수는 모든 브랜치에서 존재해야 하므로 보호할 수 없습니다.

Danger bot

GitLab v19.1
원문 보기
요약

GitLab CI/CD 파이프라인에는 danger-review job이 포함되어 있으며, 이 job은 Danger를 사용하여 테스트 중인 코드에 대해 다양한 자동 검사를 수행합니다. Danger는 다른 분석 도구와 마찬가지로 CI 환경에서 실행되는 gem입니다.

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

Danger는 다른 분석 도구와 마찬가지로 CI 환경에서 실행되는 gem입니다. Danger가 (예를 들어, RuboCop과) 다른 점은, 코드나 변경 사항의 속성을 테스트하기 위한 임의의 코드를 쉽게 작성할 수 있도록 설계되어 있다는 것입니다. 이를 위해 Danger는 공통 헬퍼 세트와 실제로 환경에서 변경된 내용에 대한 접근을 제공하고, 작성한 코드를 실행합니다!

Danger가 머지 리퀘스트에서 무언가를 변경하도록 요청하는 경우, 그 변경을 수행하는 것이 가장 좋습니다. Danger의 작동 방식을 이해하거나 기존 규칙을 변경하려는 경우, 이 문서가 도움이 됩니다.

머지 리퀘스트에서의 Danger 코멘트#

Danger는 코멘트를 하나만 게시하고, 이후 danger-review 실행 시 해당 내용을 업데이트합니다. 따라서, Danger 코멘트는 일반적으로 머지 리퀘스트의 첫 번째 또는 초기 몇 개의 코멘트 중 하나입니다. 코멘트를 찾을 수 없다면 머지 리퀘스트의 처음부터 확인해 보세요.

장점#

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

단점#

  • Danger가 기존 코멘트를 업데이트한다는 것이 명확하지 않으므로, 업데이트 여부에 주의를 기울여야 합니다.

  • Danger 토큰이 교체되면 혼란/복잡성이 생깁니다(이전 코멘트를 업데이트할 수 없기 때문입니다).

Danger 로컬 실행#

현재 검사 중 일부는 다음 Rake 태스크를 사용하여 로컬에서 실행할 수 있습니다:

bin/rake danger_local

동작 방식#

시작 시, Danger는 프로젝트 루트에서 Dangerfile을 읽습니다. GitLab의 Danger 코드는 danger/ 하위 디렉터리 내의 헬퍼와 플러그인 집합으로 분리되어 있으므로, 우리의 Dangerfile은 Danger에게 이를 모두 불러오도록 지시합니다. Danger는 각 플러그인을 머지 리퀘스트에 대해 실행하고, 각각의 출력을 수집합니다. 플러그인은 알림, 경고 또는 오류를 출력할 수 있으며, 이 모두는 CI job 로그에 복사됩니다. 오류가 발생하면 CI job(및 전체 파이프라인)이 실패합니다.

머지 리퀘스트의 경우, Danger는 MR 자체의 코멘트에도 출력을 복사하여 가시성을 높입니다.

개발 가이드라인#

Danger 코드는 Ruby 코드이므로, 모든 일반 백엔드 가이드라인이 계속 적용됩니다. 그러나 특별히 강조할 만한 몇 가지 사항이 있습니다.

Danger를 언제 사용해야 하는가#

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

먼저, GitLab의 dogfooding 원칙을 인지하세요. Danger를 위해 작성하는 코드는 GitLab에 특화되어 있으며, 우리가 직면하는 필요를 해결하는 기능을 구현하기에 가장 적합한 위치가 아닐 수 있습니다. 우리의 사용자, 고객, 그리고 Gitaly와 같은 우리 자체 위성 프로젝트들도 비슷한 과제에 직면하기 때문입니다. 모든 사람이 작업의 혜택을 받을 수 있도록 동일한 필요를 충족하는 방법을 생각해 보고, 가능하다면 그렇게 하세요.

표준 도구(예: RuboCop)가 작업에 존재하는 경우, Danger를 통해 호출하는 것보다 직접 사용하는 것이 낫습니다. Danger가 관여하지 않으면 해당 도구의 결과를 로컬에서 실행하고 디버깅하기가 더 쉬우며, Danger 전용 기능을 사용하지 않는 한 Danger 실행에 포함해도 이점이 없습니다.

Danger는 프로토타이핑과 솔루션의 빠른 반복에 적합하므로, 구축하고자 하는 것이 불분명한 경우 Danger의 솔루션을 제품 영역에 대한 정보를 수집하기 위한 시험 실행으로 생각할 수 있습니다. 이를 진행하는 경우, 해결하려는 문제와 프로토타이핑 결과를 이슈나 에픽에 계속 기록하세요. 이를 통해 향후 GitLab 버전에서 제품의 일부로 필요를 해결할 수 있습니다!

구현 세부 사항#

각 태스크를 독립된 기능 단위로 구현하고, danger/<task-name>/Dangerfile로 danger 디렉터리 내의 자체 디렉터리에 배치하세요.

각 태스크는 다른 태스크와 독립적이어야 하며, 독립적으로 기능할 수 있어야 합니다. 여러 태스크 간에 공유되어야 하는 코드가 있는 경우, danger/plugins/...에 플러그인을 추가하고 이를 필요로 하는 각 태스크에서 요구(require)하세요. 단일 태스크에 특화된 플러그인을 만들 수도 있으며, 이는 해당 태스크와 관련된 복잡한 로직을 위한 자연스러운 위치입니다.

Danger 코드는 단순히 Ruby 코드입니다. 코딩 표준을 준수해야 하며, 코드베이스의 다른 Ruby 코드와 마찬가지로 테스트가 필요합니다. 그러나 Dangerfile을 직접 테스트할 수는 없습니다! 따라서 테스트 커버리지를 최대화하려면 danger/의 코드 줄 수를 최소화하세요. 비trivial한 Dangerfile은 주로 Danger가 제공하는 메서드에서 파생된 인수로 플러그인 코드를 호출해야 합니다. 플러그인 코드 자체는 유닛 테스트를 갖추어야 합니다.

현재 우리는 tooling/danger/...의 모듈에 코드를 넣고, 이를 매칭되는 danger/plugins/... 파일에 포함시킵니다. 스펙(Spec)은 spec/tooling/danger/...에 추가할 수 있습니다.

Dangerfile이 작동하는지 확인하려면 해당 브랜치를 GitLab에 푸시하세요. 이는 새로운 태스크를 개발하거나 기존 태스크에서 무언가를 디버깅할 때 사이클 타임이 크게 증가하므로 상당히 불편할 수 있습니다. 위의 가이드라인을 따랐다면, 대부분의 코드를 RSpec에서 로컬로 실행할 수 있어 CI에서 거쳐야 하는 사이클 수를 최소화할 수 있습니다. 그러나 머지 리퀘스트에서 .gitlab/ci/rails.gitlab-ci.yml 파일을 비워두면 이러한 사이클을 어느 정도 빠르게 할 수 있습니다. 단, 머지하기 전에 해당 변경 사항을 되돌리는 것을 잊지 마세요!

Danger를 통한 라벨 추가#

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

Danger는 종종 라벨을 추가하여 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을 활성화하려면 다음 단계를 완료하세요:

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

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

require "gitlab-dangerfiles"

Gitlab::Dangerfiles.for_project(self, &:import_defaults)
  • CI/CD 구성에 다음을 추가하세요:
include:
  - component: ${CI_SERVER_FQDN}/gitlab-org/components/danger-review/danger-review@1.2.0
    rules:
      - if: $CI_SERVER_HOST == "gitlab.com"

  • api 스코프, Developer 권한(라벨을 추가할 수 있도록), 그리고 만료일 없음(실제로는 1년을 의미)으로 프로젝트 액세스 토큰을 생성하세요.

  • DANGER_GITLAB_API_TOKEN이라는 이름의 CI/CD 프로젝트 변수로 토큰을 추가하세요.

리뷰를 위해 머지 리퀘스트를 제출하기 전에 ~"Danger bot" 라벨을 해당 머지 리퀘스트에 추가해야 합니다.

현재 사용 사례#

다음은 GitLab에서 지금까지 Danger를 사용한 항목들의 (전체 목록은 아닌) 예시입니다:

  • 코딩 스타일

  • 데이터베이스 리뷰

  • 문서 리뷰

  • 머지 리퀘스트 메트릭

  • 리뷰어 룰렛

  • 단일 코드베이스 노력

알려진 이슈#

개인 포크에서 작업할 때 Danger는 실행되지만, 출력이 머지 리퀘스트 코멘트에 추가되지 않고 라벨도 적용되지 않습니다. 이는 정규 프로젝트의 시크릿 변수가 포크에 공유되지 않기 때문입니다.

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

개인 포크에서 Danger 구성하기#

기여자는 다음 단계를 통해 포크에서 Danger를 구성할 수 있습니다:

  • api 스코프가 설정된 개인 API 토큰을 생성하세요(클립보드에 복사하는 것을 잊지 마세요).

  • 포크에서, 이전 단계에서 복사한 토큰을 사용하여 DANGER_GITLAB_API_TOKEN이라는 프로젝트 CI/CD 변수를 추가하세요.

  • job 로그에 표시되지 않도록 변수를 마스킹하세요. 변수는 모든 브랜치에서 존재해야 하므로 보호할 수 없습니다.