Github Actionsの「テンション上がるところ」と「注意点」

きっかけ

仕事で9ヶ月ほどGithub Actionsを触るようになり，細かいTipsが身につきました．同僚がGithub Actionsをこれから触るということで，Jenkinsとの比較で，自分的Github Actionsの「テンション上がるところ」と「注意点」を書いてみます．

Github actionsとは

Github Actionsは，超有名Gitサーバーである"Github"に統合されたCI/CDホスティングサービスです．CI/CDは，ソフトウェア開発中の様々な過程で発生する「ビルド」や「テスト」のようなつまらない仕事を自動化するシステムのことですが，結局「ビルド」や「テスト」という作業は現代のソフトウェア開発では大抵の場合，gitのイベントに紐づくことになります (例えばコードをmasterブランチに更新をマージしたい時には，事前に「テスト」を回して動作を確認したいでしょう)．

これまで，CI/CDサービスはJenkinsのような独立したツールがGitサーバーを監視する形で実現してきましたが，どうせGitと密結合するならば，いっそのことGitサーバーがその機能を担ってしまえばいい！という発想なのがGithub Actionsです．処理の設定をyamlファイルでレポジトリに放り込むだけでよく，syntaxをミスってもすぐにgithubが教えてくれるので，結構スムーズに開発できます．

Github ActionsとJenkinsで実現できること自体は大して変わりませんが，「誰がメインユーザーか」と言う点で思想が大きく異なっており，使い勝手には大きな違いを感じました(個人の感想)．その辺りを書いていこうと思います．

Github Actionsの「テンション上がるところ」

Github Actionsは，Developerが自分でCI/CDを組み込んで使っていくことを主眼に作られており，開発者にとって非常に気持ちよく使えるようにできているように感じます．

ログが見やすい

下の図は，実際のGithub Actionsの実行例ですが，実行時のログが大変読みやすく整理されています．Developerが問題を素早く把握し対処できるように，配慮されていると感じました．

私が上手い方法を知らないだけかもしれませんが，Jenkinsではrawなログを見れるだけで，なぜ失敗したかを把握するのが大変な印象があります．問題が起きたことに気づくのは簡単ですが，どんな問題が起きているのかを把握するのはめんどくさいイメージがあります．

ドキュメントが整理されている

公式レファレンスがしっかりしています．Github Actionsの仕組みをある程度理解しておく必要はありますが，慣れれば必要な情報にしっかりアクセスできます．文法もyamlベースになっているので大変シンプルです．

CI/CDを実行するインスタンスを超超超簡単に作れる

JenkinsはもともとJenkinsサーバーで処理を実行する仕組みになっているせいか，処理を他マシンに任せる仕組みが煩雑です．SSHを使ってSlaveマシンを操作する仕組みは通信の方向的にセキュリティが問題になりそうですし，Javaを使ってクライアントを作るのもちょっと気合を入れてやる必要があります．

Github Actionsでは，Slaveマシンを作る際はコマンドをそのままコピペするだけで完了します．なんの事前準備も不要です．必要なバイナリをインストールするところから，ワンタイムキーを入力するところまで，下の図のように全部その都度コマンドを生成してくれるので，本当にコマンドのコピペだけでセットアップが完了します．この簡便さは病みつきになります．

Github Actionsの注意点

一方で，Jenkinsは開発全体をマネージする人向けに作られているので，大規模な自動化や開発全体を俯瞰するためのUIが優れており，この点ではGithub Actionsは工夫したり割り切ったりする必要があります．

大規模化するには工夫が必要

例えば，Github Actionsでレポジトリをまたがって大規模な自動化を実現しよう場合，いかにも使えそうな名前の「Repository Dispatch」という機能があります．しかし，これを使って別の処理をトリガーすると全く独立して処理を始めてしまうので，トリガー元は成功したのか失敗したのかがわかりません(結果を監視するような仕組みは作れるでしょうが，トリガー元にログが残らないのでは結局片手落ちです)．

したがって，レポジトリを跨る場合にはgit submoduleのような機能を使ってソースコードを1つレポジトリにまとめ，1つのワークフローで全てを実行できるような工夫が必要になるはずです．Jenkinsの場合はそもそもジョブが1つのレポジトリに紐づかないので，pipeline機能などを使って，様々なレポジトリを跨った処理を書くことはとても自然なことです．

プロジェクト全体を俯瞰できない

また，Jenkinsのダッシュボードのお天気マークは大規模開発をマネージする上で大変優れたUIだと思います．ダッシュボードを開けば，どのソフトウェアでトラブルが起きているかを把握することができるのは開発をマネージする側にとっては嬉しいでしょう．

一方，GithubActionsでは，レポジトリの中にあるActionsのページを開き，さらにお目当てのタスクでフィルタリングしなければ最新の実行結果がどうなっているかわかりません．プロジェクトを統括している立場からすると開発状況が不透明になりがちです．

トリガーしたイベントの情報が残っていない

もう一つ，Github Actionsで気になるのは，トリガーした際のイベント情報がデフォルトではまとまった形で残らないことです．手動実行した際などはパラメタを設定するのですが，これがデフォルトで残らないのは，後で問題を分析するときに課題になります．この辺りもトリガーした人はその状況を覚えているからそれほど困らないだろう，という開発者目線で機能追加が後回しになっているのではと感じます (自分でprint文を書けば良いのでそれほど手間ではないですが，もともとsetup時のログが残る仕様になっているのでそこにトリガーしたイベントの情報も残して欲しいものです)．

一応GithubActions側の肩を持っておくと，パラメタに使った情報を処理の中で使う場合，実際の処理コマンドの中にマクロ的に埋め込まれて記録されるので，全く分からなくなるわけではないです (しかし"if"のようなログで残らない箇所で使う場合，やはり残りません)．

Jenkinsではきちんと実行時のパラメタ情報が残っているので，この心配はありません．

まとめ

結構ネガティブな意見も多く書いてしまいましたが，なんだかんだGithub Actionsは直感的で最高に使いやすいです．大規模な開発の場合であっても，先にあげたGithub Actionsの弱いところを理解しておけば事前に手を打つこともできるでしょう．

ぜひ私の同僚にもはやいところJenkinsからGithub Actionsに移行してもらいたいです．