これは下記のブログざっと読んだメモです。
概要
PerilはDangerをホストするアプリケーションです。Dangerは通常CIサーバーで動かしますが、Perilを導入すると自らwebhookを受け取りPerilサーバー上でDangerスクリプトが実行されます。
PerilプロジェクトはCIサーバーからDangerの実行環境を独立させることを目的としています。これによってissueの更新などのイベントフックが可能になります。
PerilはGithubAppとして動きます。Herokuでの動作手順は下記に紹介されています。
peril/setup_for_org.md at master · danger/peril · GitHub
なぜPerilをつくったのか
作者のブログに色々と書いてありますが昔から構想はあったそうです。結局の所CIサーバー上で動かしている限り制約が多いので、独立したサーバーとして動かして多くの作業をDangerに任せたいからだと理解しました。 CocoaPods orgではissueとPRの管理で実際に運用されています。
Perilの設定ファイル
Artsy社で実際に使われているPerilの設定ファイルは下記のようです。Org単位で設定を書く形になります。任意のwebhookに任意のscriptを手軽に動かせるのがPerilの魅力のようです。
{ "settings": { "modules": [ "danger-plugin-spellcheck", "danger-plugin-yarn", "@slack/client" ], "env_vars": ["SLACK_RFC_WEBHOOK_URL"] }, "rules": { "pull_request": "artsy/artsy-danger@org/all-prs.ts" }, "repos" : { "artsy/reaction": { "pull_request": "danger/pr.ts" }, "artsy/positron": { "pull_request": "dangerfile.ts" }, "artsy/artsy-danger": { "issues.opened": "artsy/artsy-danger@danger/new_rfc.ts" } } }
おわり
Perilはまだ開発途中で問題をいくつか抱えています。またPerilはDanger.jsで動くのでGithub以外に対応していないほかDaner(Ruby)と比べると安定性に欠けます。それでもこういうものを求めていたという人はぜひ導入してみると良さそうです。