위험 봇

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

Danger는 RuboCop와 같은 다른 분석 도구와 마찬가지로 CI 환경에서 실행되는 젬입니다.

그러나 Danger는 코드 또는 변경 사항의 속성을 테스트하기 위해 임의의 코드를 쉽게 작성할 수 있도록 설계되었습니다. 이를 위해 일반적인 헬퍼 집합과 환경에서 실제로 변경된 내용에 대한 정보에 대한 접근을 제공합니다. 그런 다음 코드를 실행합니다!

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 dofooding에 대한 약속을 인식하십시오.

Danger를 위해 작성한 코드는 GitLab 전용이며, 여기서 겪는 필요를 해결하는 기능을 구현하는 가장 적절한 장소가 아닐 수 있습니다.

우리의 사용자, 고객, 심지어 우리의 위성 프로젝트인 Gitaly와 같은 경우에 비슷한 문제에 직면하기도 합니다. 모든 사람이 작업의 혜택을 받을 수 있도록 하는 방법에 대해 생각하고, 가능하다면 대신 그렇게 하십시오.

작업을 위해 표준 도구(예: RuboCop)가 존재하는 경우, Danger를 사용하여 호출하기보다는 직접 사용하는 것이 좋습니다. Danger가 관련되지 않은 경우 이러한 도구의 결과를 실행하고 디버깅하는 것이 더 쉽습니다. 별도의 Danger 전용 기능을 사용하지 않는 한, Danger 실행에 포함하는 혜택이 없습니다.

Danger는 프로토타입을 만들고 해결책을 신속하게 반복하는 데 적합하므로, 구축하려는 것이 불분명한 경우 Danger에서의 솔루션을 제품 영역에 대한 정보를 수집하기 위한 시험 실행으로 생각할 수 있습니다. 이렇게 하는 경우 해결하고자 하는 문제와 이 프로토타입의 결과가 진행하는 동안 이슈나 에픽에 포함되도록 하십시오. 이는 우리가 GitLab의 미래 버전에서 제품의 일부로 필요를 해결하는 데 도움이 됩니다!

구현 세부사항

각 작업을 독립적인 기능 조각으로 구현하고, 이를 danger 아래의 자체 디렉토리에 danger/<task-name>/Dangerfile로 배치합니다.

각 작업은 서로 격리되어야 하며, 독립적으로 기능할 수 있어야 합니다.

여러 작업 간에 공유해야 할 코드가 있다면, 이를 danger/plugins/...에 플러그인으로 추가하고 필요한 각 작업에서 요구해야 합니다. 또한, 특정 작업에만 해당되는 플러그인을 생성할 수 있으며, 이는 해당 작업과 관련된 복잡한 논리를 위한 자연스러운 장소입니다.

Danger 코드는 단순히 Ruby 코드입니다. 이는 우리의 코딩 표준을 준수해야 하며, 코드베이스의 다른 Ruby와 마찬가지로 테스트가 필요합니다. 그러나 Dangerfile을 직접 테스트할 수는 없습니다! 따라서 테스트 커버리지를 극대화하기 위해 danger/의 코드 줄 수를 최소화하려고 노력하세요. 비트리비얼(non-trivial) 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 위생을 개선하기 위해 레이블을 추가하는 데 자주 사용됩니다. 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을 활성화하려면 다음 단계를 수행하세요:

Gemfile에 gitlab-dangerfiles를 추가합니다.

다음 내용을 가진 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가 사용된 것들의 (비포괄적인) 목록이 있습니다:

코딩 스타일
데이터베이스 검토
문서 검토
Merge Request 지표
리뷰어 루렛
단일 코드베이스 노력

한계

개인 포크에서 작업할 경우, Danger는 실행되지만 그 출력이 Merge Request 댓글에 추가되지 않고 레이블이 적용되지 않습니다.

이는 기본 프로젝트의 비밀 변수가 포크와 공유되지 않기 때문입니다.

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

개인 포크에 대한 Danger 구성

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

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