はじめに
本記事はiOSプロジェクトにDangerを導入し、GithubActionsによってPRが作成された際に自動でPRのチェックやlintを走らせるための導入の記事です。
実行環境
- Xcode 12
- Swift 5.3
- Ruby 2.7.1
- bundler 2.1.4
- danger 8.0.5
なぜGithubActionsなのか
dangerをCIでまわす手段はいくつかあります。(GithubActions、Sider、CircleCI, Bitrize, Jenkinsなど)
ただ新規の導入かつ会社的な制限がないのであれば、2020年10月現在はGithubActionsがベストプラクティスなような気がします。
理由は以下です。
- githubで全てが完結する。
- 即ちAPIトークンの発行とかCIサービス用のアカウント作成とか要らないのでめっちゃ楽。
- おまけに安い。Publicリポジトリはまさかの時間無制限で無料。Privateリポジトリで比較してもその他のCIサービスより安いらしい。
導入手順
1. bundlerをインストール(なければ)
gem install bundler
docker使うとかグローバルに入れるとかはご自由に。GemfileができればOK。
2. Gemfileを作成
bundle init
GemfileができたらOK
3. Gemfileにインストールするgemを記述
# frozen_string_literal: true
source "https://rubygems.org"
gem 'danger'
gem 'danger-swiftlint'
# gem "rails"
終わったらGemをインストール
bundle install
vender/bundleにするしないは実行する方の思想に合わせます。どっちでもOK。
4. dangerfileの作成
bundle exec danger init
色々チュートリアルが表示されるけど全部スキップ。
Dangerfileが生成されたらOK。
注意
- 自動生成されるので大丈夫だと思いますが、名前が
Dangerfile以外になっていると動かないので注意。
5. Dangerfileの編集
好きな内容で編集。
-
APIReference
- 公式。ここ見ればどんな値が使えるか分かります。
-
受託開発での iOS アプリプロジェクト新規作成プラクティス（下編：Bitrise 編）
- めちゃくちゃdanger使い込んでるプロジェクトのdangerfileが載ってます。受託に限らずdangerでチェックしたいことはこちらのdangerfileを参考にすれば大抵できる気がする。
以下は僕が動作確認に使ったdangerfileの例です。
# Check PR
warn("PRがWIPになってるよ！🐶") if github.pr_title.include? "[WIP]"
warn("PRのタイトルが短すぎるよ！🐶") if github.pr_title.length < 5
warn("PRにタイトルが書かれてないよ！🐶") if github.pr_title.length == 0
warn("PRの説明が短すぎるよ！レビュアーが見て分かる説明を書いてね！🐶") if github.pr_body.length < 5
warn("PRにassigneeが設定されてないよ！🐶") unless github.pr_json["assignee"]
pr_has_screenshot = github.pr_body =~ /https?:\/\/\S*\.(png|jpg|jpeg|gif){1}/
warn("UIレビューの時はスクリーンショットを添付してね！🐶") if !pr_has_screenshot
# 修正範囲外をチェック対象から外します。
github.dismiss_out_of_range_messages
# Swiftlint
swiftlint.config_file = '.swiftlint.yml'
swiftlint.lint_files inline_mode: true
補足
swiftlint.config_file = '.swiftlint.yml'でswiftlint.ymlのディレクトリを指定しています。
プロジェクトのルートに.swiftlint.ymlがない場合はそのディレクトリを上記で指定して下さい。
6. swiftlin用のymlを作成(なければ)
touch .swiftlint.yml
.swiftlint.ymlの中身はお任せ。この辺参考にどうぞ。
ここまでできたら以下のコマンドを打ってみて動作確認する。
danger pr https://github.com/danger/swift/pull/95
動いてdangerのログがターミナルに出力されたらOK
7. githubAction用のymlを作成
mkdir .github/workflows
touch danger_swift.yml
ymlの名前は他の名前にしてもOK。
.github/workflowsにymlがあるのが大事。
GithubのレポジトリからActionsを選んでGUI上で作ってもOK。
Set up this workflowを選択したら勝手に.github/workflowsのディレクトリとymlファイルを生成してくれます。
8. danger_swift.ymlの編集
以下の内容でPRの作成をトリガーにdangerを走らせることができます。
name: Danger Swift
on: [pull_request]
jobs:
danger:
name: Danger
runs-on: macos-latest
steps:
- uses: actions/checkout@master
- name: Setup Ruby
uses: actions/setup-ruby@v1
with:
ruby-version: '2.x'
- name: cache bundle
uses: actions/cache@v2
with:
path: vendor/bundle
key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}
restore-keys: |
${{ runner.os }}-gems-
- name: setup bundle
run: |
gem install bundler
bundle config path vendor/bundle
bundle install --jobs 4 --retry 3
- name: Run Danger
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
bundle exec danger
やってること
- Rubyのインストール
- Gemのキャッシュがあれば使用
- bundlerのインストール
- Gemのインストール
- dangerの実行
- キャッシュできたらキャッシュ(
actions/cache@v2で勝手にやってくれる。)
注意
-
uses: actions/cache@v2を間違えてuses: actions/cache@v1にしていたらNo such directoryみたいに表示されてキャッシュに失敗しました。
9. リモートリポジトリに配置
ここまでできたらプッシュします。
注意
- PRのbaseBranchに実行ファイルが配置されていないとPRを出してもアクションが始まりませんでした。
- baseBranchへ上記の各種実行ファイルがマージされた次のPRから動作確認ができます。
あとはPRを作成した時にgithubActionsが実行されてDangerが走るはず。
実行時間
こんな感じです。
おわりに
GithubActionsでdangerをまわすまでのロードマップでした。
swiftlintはbuildPhaseでスクリプト書いとけばビルドの時に走らせたりはできるんですが、修正したかどうかはプログラマ次第なので結局レビューする時は気になっちゃったりするんですよね。
けどdangerで引っかかってるところを自動でPRにコメントしてくれるようにしておけば、レビュアーは細かいとこ気にしなくて良くなるのでレビューがずっと楽になります。
今回はCIでリントを回すだけでしたが、GithubActionsでdangerの書き込みをslackに通知したり、dangerの充実したプラグインを使ってCIを拡充したりもしたいです。
※ 僕の環境では上記のセットアップでエラーなどは出ていませんが、もし手順通りにやっても上手くいかないとかあれば是非コメントお願いします
参考
- 公式
- github actionsでRailsをCIして結果をslackに流す(キャッシュあり)
- GitHub ActionsでCacheを使ってみた
- 受託開発での iOS アプリプロジェクト新規作成プラクティス（下編：Bitrise 編）
訂正
- [7. githubAction用のymlを作成]でymlを配置するディレクトリを
.github/workflowと記載していましたが、正しくは.github/workflowsでした。申し訳ございません。