※ 12/19 以前、githubのアクセストークンの設定のところを自分のアカウントと書いてて、リンクしていただいた@chamaoさんの記事を見て、　「あっ」って、なったので文章を一部修正、スクリーンショットの追加をしました。

導入した理由

プロジェクトによって「この作業やった時は、必ず前に〜つけて」みたいなルールが違うところがあったり、覚えるのが大変。。。
「お前それ、あげる前にちゃんと動かした？」、「TODO残ってるんだけど？？？」みたいなことを逐一言うのは正直疲れるし、実装以外の部分の指摘をするためにコミット内容に目を通すのも時間がかかる。

少しでも「何か忘れてない？」チェックの負担を軽減できないかと思い、DengerFileと言うファイルで設定したルールの通りに自動チェックをしてくれる Dangerを導入をしてみた。

※この記事は、CircleCI2.0が扱えると言う前提として書いてるので、CIについての解説はないです。

導入

1. Danger動かすためにconfig.ymlにdanger用のjobを追加する

下記を.circleci配下の.config.ymlに記述する。

version: 2

# Define the jobs for the current project.
jobs:
  danger:
    docker:
      - image: dantoml/danger:latest
        environment:
         - TZ: "/usr/share/zoneinfo/Asia/Tokyo"
         - LANG: ja_JP.UTF-8
         - LC_ALL: C.UTF-8
         - LANGUAGE: ja_JP.UTF-8
    steps:
      - checkout
      - run: gem install danger-todoist
      - run: danger

このJobでやっていること
- dockerを使ってDangerが動く環境を丸っと持ってくる
- コードをチェックアウトしてくる
- dangerを実行

※ DangerのDockerImageはロケールがjaになっていない・文字コードがASCⅡになっているので、
environmentに下記設定をする必要がある。

environment:
         - TZ: "/usr/share/zoneinfo/Asia/Tokyo"
         - LANG: ja_JP.UTF-8
         - LC_ALL: C.UTF-8
         - LANGUAGE: ja_JP.UTF-8

2. Dagnerfileを生成する

Dangerfileとは

PullRequest時にチェックする項目(ルール)を記述するファイルである。

ファイルを生成

$ danger コマンド実行時に、このDangerfileと言う設定ファイルを見に行くので、基本的にはプロジェクトのRootに(サブディレクトリでも行けるような情報もちらっとみた気がする)
テキストファイルを作成し、名前をDangerfileに変更する。

3. DangerFileにルールを記述する

DangerfileにはRubyを使ってルールを記述していく。
※danger-jsとういうjavascript版も存在する

ルールには警告「warn」と失敗[failure]又は[fail]がある。

以下は、チェック時に、PullReqを出した先がmasterだった場合Buildを失敗扱いにすると言う記述。

fail("The merge destination is not a `develop branch`") if github.branch_for_base == "master"

以下は、チェック時に、PullRequestのDescriptionが書かれていないのを警告扱いにすると言う記述。

warn("There is no description for PullRequest. Please enter a description.") if !github.pr_body.include?

とりあえずルールざっくりと設定。
あくまでお試しなので、実際に使うときは条件を変える必要がある。


#Ciスキップ
if git.commits.first.message =~ /\[ci skip\]/ || github.pr_body =~ /\[ci skip\]/
  warn "Test stage is skipped"
  File.open(".ci_skip", "w")
end

#developブランチではなく、masterブランチにマージしようとしていなかの確認
fail("The merge destination is not a `develop branch`") if github.branch_for_base == "master"

#PullRequestのDescription有無を確認
warn("There is no description for PullRequest. Please enter a description.") if !github.pr_body.include? "Description"

#PullRequestにラベルが貼られているかを確認
fail "Please add labels to this PR" if github.pr_labels.empty?

#PullRequestのタイトルにfeat(client)が含まれているか確認
if github.pr_title =~ /\[feat(client)\]/

else
  fail("PullRequest's title is not in the specified format")
end

4. GithubApiを使うための準備

Dangerfileに記述したルールに、githubのApiを使っているためアクセストークンを生成する必要がある。
（github.pr_body.includeとか　 github.pr_labels.emptyとか）

※12/19　修正と追加

まず、Dangerを扱うにあたって専用のGithubアカウントを用意する。
(公式に以下のような記載がったので修正しました。)

次に、Dangerに使用するGithubアカウントの自分のプロフィールページを開く。
プロフィールの左側にメニューが表示されているので、一番下の Developer settingsをクリックする。

OAuth Appsに切り替わるので、次に Personal acces tokensをクリックする。

AccessToken 一覧が表示され、ページの右上辺りに[Generate new token]と言う名前でボタンが
表示されるのでクリックする。

次に下記の公式の引用を元に、アクセストークンに必要な権限を付与する。
権限付与に関しては以下のように公式から推奨されているものがある。

TOKENS FOR OSS PROJECTS

We recommend giving the token the smallest scope possible. This means just public_repo, this scopes limits Danger’s abilities to just writing comments on OSS projects. Because the token can be quite easily be extracted from the CI environment, this minimizes the chance for bad actors to cause chaos with it.

TOKENS FOR CLOSED SOURCE PROJECTS

We recommend giving access to the whole repo scope, and its children.

引用元 : Danger Getting Set Up
引用元URL :https://danger.systems/guides/getting_started.html

簡単に要約すると、
公開リポジトリについては可能な限り最小限の権限を付与するpublic_repoを、
非公開リポジトリについては、repoを付与することを推奨とする。

作成が完了すると、以下のようにトークンが生成される。

次に、生成したtokenをCircleCiのEnvironment VariablesにDANGER_GITHUB_API_TOKENと言う名前で登録する。

Environment Variablesへの登録の仕方は、
まず、CircleCiのプロジェクト画面の左上にある歯車マークをクリックする。

プロジェクトの設定画面が表示され、左側にメニューが表示される。
メニューからEnvironment Variablesを選択する。

環境変数一覧の画面に遷移後、「add Variable」ボタンをクリックする。

NameにDANGER_GITHUB_API_TOKEN
ValueにToken生成時に表示された値を入れる。
忘れてしまった場合は、忘れたTokenの編集画面の「Regenerate token」で新しいtoken生成することができる。

確認

実際にPullReqestを出して動作を確認する。

まずは、CircleCiの方を見る。

DangerFileで設定した、Failに設定した項目3つと、warnで出力するようにした項目1つが出力されていることが確認できる。

次に、githubの方を確認する。

こちらでも、設定した通りに、failで設定した項目には「禁止マーク」がつき、warnに設定した項目には「注意マーク」がついて出力される。

次に、Dangerにて指摘されている部分を一個、修正してみる。

まずは、PRにラベルがついていないので、適当にLabelをつける。

そして、再度CIを回す

CicleCi側

Github側

上記のスクリーンショットのように修正されると、確認が取れたものから指摘項目が消えていく。

Workflowの組み方次第では、Dangerによってチェックされた項目を全て修正しないとBuildさせないマンとかできるので、細かい指摘事項修正してPushするごとに長時間のBuildが走るなんてことを防ぐことができそう。
(生産性が下がらない程度に程々に設定しよう)

色々試してみよう

Dangerには、色々プラグインが用意されていて、LGTMが出せるやつや・Shellスクリプトをチェックしてくれるやつ、
TODOとついた箇所を探して、リスト化、警告してくれるもの等が存在する。

以下、公式サイトのPluginから確認できる。
https://danger.systems/ruby/

Dangerのプラグインを使うときは、実行する前に

steps:
  - run: gem install `プラグイン名`

を実行してれば使える。(本当はdangerのimageをforkして追加 or 自作した方がいいのだろうけど。。。)

また、DagnerのPluginは自作することも可能なので、DangerFileに大量に書いてたものを、メソッドの呼び出しで一括でチェックを走らせるプラグインとか、プロジェクト毎にこのプラグイン入れて、DangerFileに書いておけば良いといといったことが出来るので便利。

公式にてプラグインのテンプレートは用意されている。
https://github.com/danger/danger-plugin-template

最後に

DangerFileに記載するルールについては、結構色々な人がブログに書いていたり、
勉強会のスライドも存在していたのでその辺を参考にしたり、周りの人によく注意される部分などを、設定してみるところから
始めみてはいかがでしょうか。(自分の場合、昔はよく某vvさんとか、某egskさんにべしべしされてたなと、懐かしみを得ながら設定ファイルを書いていました。)

やりようによっては、テストが実行されていたか？みたいなテストの実行時の成果物が新しいかどうか、コードスタイルもチェックできるだとか。

それでは、良い継続的インテグレーションライフを。

CircleCI2.0上でDangerを使ってみる