• マージリクエストにおけるDangerコメント
  • 利点
  • デメリット
• ローカルでDangerを実行
• オペレーション
• 開発者ガイドライン
  • いつDangerを使うべきか
  • 実装の詳細
    • 危険によるラベルの追加
    • 共有ルールとプラグイン
    • プロジェクトでDangerを有効化
• 現在の用途
• 制限事項
  • フォーク用のDangerの設定

危険なボット

GitLab CI/CD パイプラインには、Danger を使ってテスト対象のコードに対して様々な自動チェックを行うdanger-review ジョブが含まれています。

Dangerは他の解析ツールと同じようにCI環境で動作するgemです。(例えばRuboCopと)異なる点は、コードや変更のプロパティをテストするために任意のコードを簡単に書けるように設計されていることです。この目的のために、一般的なヘルパーのセットと、実際に環境で何が変更されたかについての情報へのアクセスを提供し、コードを実行します！

もしDangerがあなたのマージリクエストについて何かを変更するように要求してきたら、変更するのが一番です。もしDangerがどのように動作するかを学びたい、あるいは既存のルールに変更を加えたいのであれば、この文書はあなたのためのものです。

マージリクエストにおけるDangerコメント

Dangerは1つのコメントのみを投稿し、その後のdanger-review 。このことから、通常マージリクエストの最初のコメントではないにしても、最初の数個のコメントの一つです。もし表示されなかった場合は、マージリクエストの最初から見てみてください。

利点

• danger-review が実行されるたびにEメールで通知されることはありません。

デメリット

• Dangerが古いコメントを更新しているかは明らかではないので、更新されているかどうかに注意を払う必要があります。

ローカルでDangerを実行

現在のチェックのサブセットは、以下のRakeタスクでローカルに実行できます：

bin/rake danger_local

オペレーション

起動時に、DangerはプロジェクトルートからDangerfile 。GitLab の Danger のコードは、danger/ サブディレクトリ内のヘルパーやプラグインのセットに分解されています。そして Danger はそれぞれのプラグインをマージリクエストに対して実行し、それぞれの出力を収集します。プラグインは通知、警告、エラーを出力し、そのすべてがCIジョブのログにコピーされます。エラーが発生した場合、CIジョブ（そしてパイプライン全体）は失敗します。

マージリクエストでは、Danger は MR 自体のコメントにも出力をコピーし、可視性を高めます。

開発者ガイドライン

DangerのコードはRubyのコードなので、通常のバックエンドのガイドラインはすべてそのまま適用されます。しかし、特に強調すべきことがいくつかあります。

いつDangerを使うべきか

Dangerは強力で柔軟なツールですが、与えられた問題やワークフローを解決するのに最も適切な方法とは限りません。

まず、GitLabのドッグフーディングへのコミットメントを意識してください。私たちがDangerのために書くコードはGitLab固有のものであり、私たちが遭遇したニーズに対応する機能を実装する場所として最も適切であるとは限りません。私たちのユーザー、顧客、そしてGitalyのような私たち自身のサテライトプロジェクトでさえも、結局のところ、しばしば同じような課題に直面しています。どのようにすれば同じニーズを満たすことができ、かつ誰もがその作業から利益を得ることができるかを考えてみてください。

あるタスクに対して標準的なツール（例えば、rubocop ）が存在する場合、Dangerを使ってそれを呼び出すのではなく、直接それを使う方が良いでしょう。これらのツールの結果をローカルで実行したりデバッグしたりするのは、Dangerが関与していない方が簡単ですし、Danger特有の機能を使用していない限り、Dangerの実行に含めるメリットはありません。

Dangerはプロトタイピングとソリューションの迅速な反復に適しているので、構築したいものが不明確な場合、Dangerでのソリューションは製品領域に関する情報を収集するための試運転と考えることができます。その場合、解決しようとしている問題と、そのプロトタイピングの結果を、イシューやエピックにまとめながら進めてください。そうすることで、GitLabの将来のバージョンで製品の一部としてそのニーズにアドレスすることができます！

実装の詳細

各タスクを独立した機能として実装し、danger/<task-name>/Dangerfileとして、danger の下の独自のディレクトリに配置します。

各タスクは他のタスクから分離され、分離された状態で機能する必要があります。複数のタスクの間で共有されるべきコードがある場合、danger/plugins/... にプラグインを追加し、それを必要とするそれぞれのタスクでそれを必須にします。1つのタスクに特化したプラグインを作成することもでき、そのタスクに関連する複雑なロジックのための自然な場所です。

危険なコードは単なるRubyコードです。コードベースの他のRubyと同じように、私たちのコーディング標準に従うべきですし、テストも必要です。しかし、Dangerfile を直接テストすることはできません！ですから、テストカバレッジを最大にするために、danger/のコード行数を最小にするようにしましょう。自明でないDangerfile は、Danger が提供するメソッドから派生した引数でプラグインのコードを呼び出すことがほとんどです。プラグインのコード自体にはユニットテストが必要です。

現在のところ、tooling/danger/... のモジュールにコードを入れ、danger/plugins/... ファイルにそれを含めることでこれを行います。その後、spec/tooling/danger/... に仕様を追加することができます。

Dangerfile が動くかどうかを判断するには、それを含むブランチを GitLab にプッシュします。新しいタスクを開発するときや、既存のタスクで何かをデバッグしようとするときのサイクルタイムが大幅に増加するため、これはかなりイライラさせるかもしれません。上記のガイドラインに従えば、ほとんどのコードはRSpecでローカルに実行することができ、CIで必要なサイクルの数を最小限に抑えることができます。しかし、マージリクエストで.gitlab/ci/rails.gitlab-ci.yml ファイルを空にすることで、これらのサイクルを多少早めることができます。マージする前に変更を戻すことを忘れないでください！

危険によるラベルの追加

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に追加された後、1回の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. プロジェクトがgitlab-org グループに属している場合、DANGER_GITLAB_API_TOKEN 変数はグループレベルで利用できるので、トークンを設定する必要はありません。そうでない場合は、最後のステップに従ってください：
   1. プロジェクトのアクセストークンを作成します。
   2. トークンを CI/CD プロジェクト変数DANGER_GITLAB_API_TOKEN として追加します。

レビュアーに送る前に、マージリクエストに~"Danger bot "ラベルを追加してください。

現在の用途

DangerがこれまでGitLabでどのようなことに使われてきたかを（網羅的ではないものの）挙げてみましょう：

• コーディングスタイル
• データベースレビュー
• ドキュメンテーションレビュー
• マージリクエストのメトリクス
• レビュアー・ルーレット
• 単一のコードベースへの取り組み

制限事項

フォークで作業している場合、Danger は実行されますが、その出力はマージリクエストコメントに追加されません。これは、正規プロジェクトの秘密変数がフォークに共有されないために起こります。

フォーク用のDangerの設定

コントリビューターは以下の手順でフォークにDangerを設定することができます：

1. api スコープを設定した個人用 API トークンを作成します（クリップボードにコピーするのを忘れないでください）。
2. フォークで、DANGER_GITLAB_API_TOKEN というプロジェクト CI/CD 変数に、前のステップでコピーしたトークンを追加します。
3. この変数はジョブログに表示されないようにマスクしてください。変数はすべてのブランチに存在する必要があるため、保護することはできません。