with Android版 の CI を Bitrise から GitHub Actions に移行しました

はじめに

with で Android エンジニアをしている 石田 です。 with-android では CI でビルド、テスト、Lint、内部テスト用バイナリの配布等を自動化しています。

最近 with では GitHub のプランを変更しました。それに伴い GitHub Actions を使える環境になったので、 with-android では CIを Bitrise から GitHub Actionsに乗り換えました。本記事では GitHub Actions への移行理由、よいところ、ハマったところなどを簡単に紹介します。

※ 本記事は2022年4月時点での GitHub Actions の仕様に基づく内容になっています。最新の仕様は 公式ドキュメント を参照してください。

なぜ GitHub Actions に移行したか

Bitrise を使っていた頃は iOS チームと Android チームで 2つのマシンを共用していました。そのため、 時おり CI が詰まる(なかなかビルドが実行されない)状況が発生していました。一方で GitHub Actions は並列稼働数に制限がないため、この課題を解決できると考えました。 ¹

さらに GitHub Actions であれば GitHub 1つでもろもろ完結する のは大きいです。

気になる料金ですが、with-android では 1か月 あたり 約7000分 Ubuntu で CIが動くという想定で見積もりをしました²。料金は Bitrise と比べてほぼ同じくらいで済みそうだと判断しました。 一方 iOS は Mac でビルドする必要がありますが、GitHub Actions では Mac のビルドが Ubuntu の 10倍 課金されるため導入を諦めました。

GitHub Actions には無料枠もありますが、あまり多くはないのでおまけ程度と考えるくらいがよさそうです。

GithHub Actions のよいところ

GitHub Actions に移行してみてよかったなと感じたことを紹介します。

並列で何個でもビルドが動く

Bitrise では前述の課題がありましたが、GitHub Actions に移行して無制限に並列でビルドが動くようになり、待ちが全く発生しなくなりました。CIの結果をすぐに確認できることで心理的にも余裕が出来たような気がします。

Workflow

ワークフローは YAML で記述しますが、GitHub 上のエディタが中々使いやすくサクサク入力できます。間違いがあればその場で教えてくれるのでとても助かります。

またワークフローはリポジトリの .github/workflows ディレクトリに置くので、変更履歴がしっかりと残ります。CIの設定は職人技(特定の人だけが関わる状態)になりがちなので、履歴が残るのは心強いです。

Checks

GitHub Actions には テストレポートなどを出力するための機能があります。テストで落ちている箇所をすばやく確認できるので作業効率が上がりました。

GitHub Actions でハマったこと

次に GitHub Actions でハマった部分を紹介します。

dependabot との連携

with-androidでは dependabot を使用してライブラリを定期的に更新しています。 ここで注意しなければいけないのが、dependabot からワークフローが発火される場合には read-only の permissions が適用されることです。 write 権限が必要な場合は permissions の設定が必要です。

また、secretsも通常のものとは別の Dependabot secrets が参照されるため別途設定しておく必要があります。

参考: Automating Dependabot with GitHub Actions

ワークフローの分割

GitHub Actions には Reusable workflow というワークフローを分割して再利用する機能があります。 Reusable workflow には入力と secrets を渡すことができます。 secrets はデフォルトで引き継がれないので、必要なものは明示的に渡してあげる必要があります。ところが最近 secrets: inherit と書くだけで secrets を引き継げるようになったらしいので、こちらの方が楽かもしれません。

参考: GitHub Actions: Simplify using secrets with reusable workflows

ストレージ容量

成果物 (Android の場合は APK や mapping.txt 等) を Artifact として保存する場合はストレージ容量に注意が必要です。ストレージは GitHub Packages と合算の容量で計算されますが、無料枠がわずかしかないためあっという間に上限に達してしまいます。

ストレージ容量の上限を余裕をもたせて設定したり、不要な Artifact を定期的に削除するワークフローを設定したりするなどの対応が必要です。

参考: About billing for GitHub Packages

まとめ

モバイルアプリ の CI は Bitrise というイメージが何となくある中での GitHub Actions 移行でしたが、とても満足して日々使っています。特に無制限に並列でビルドが動く点や GitHub 1つで完結する点を評価しています。 GitHub Actions には頻繁に改善や新機能が入っているので、これからの進化も期待できそうです。

1. 2022年4月現在、Bitrise ではクレジットベースのプランが登場しています。そのため Bitrise でも並列稼働数の制限を気にすることなく利用することができます。Faster, more flexible plans on Bitrise: Introducing Teams ↩

2. 料金シミュレーターが利用可能です。 (後になって存在を知りました) ↩