「GitHub Actions」で何をする？ 先行ユーザーたちの使いどころ
続いて、GitHub Actionsを使って実際にどんなワークフローが実現できるのか、いくつかの企業によるデモが行われた。
デプロイ前に自動でチェックが走り、テストも実行―Hashicorp
VagrantやTerraformなど、クラウドやインフラ自動化のためのオープンソースソフトウェアを開発している「Hashicorp」。現在、開発環境からセキュリティーツールまで、7つのプロダクトを持つ。
登壇したFounder and co-CTOのMitchell Hashimoto氏は、TerraformとGitHub Actionsを連携させたワークフローを使って、デモを行った。Terraformは、インフラをコードとして構築・管理するツールで、AWSやAzureなど多数のクラウドサービスに対応している。
Hashicorp Founder and co-CTO Mitchell Hashimoto氏によるデモの動画
このデモではページが存在しない場合のエラーメッセージ（デフォルトでは404）を修正した。まずTerraformの設定コードを書いたリポジトリを用意。これは静的サイトをAmazon S3上にセットアップしている。
ファイルを編集して、インデックスページのコードをコピー＆ペーストし、"index"を"error"に修正してエラーページを作成する。完了したら新しいブランチにコミットして、プルリクエストを送る。すると、すぐにチェック項目がスタートした。これはGitHub Actionsで定義したワークフローで、プルリクエストが送られたら、構文の確認や検証など、いくつかのチェックを走らせるように設定している。
しばらくすると、「github-actions bot」がプルリクエストに返信する。アクションに間違いがあった場合には、そのエラーメッセージとともに返信が返ってくるのだ。
今回、構文が間違っていることが指摘されたので、差分を確認してみると、カッコの手前で改行するべきなのにできていないことが分かった。メインブランチに戻って修正し、再びコミットする。今度は「validate」にエラーが出た。validateコマンドはクラウドに行く前にコードが問題ないか検証するもの。今回のエラーメッセージでは、error_pathが定義されていないことが指摘されていたので、構文のエラー同様に修正すると、今度はエラーは全くでなかった。
全てのチェックを通過して次にgithub-actions botが表示したのは「terraform plan」だ。これはいわゆるdry runで、本番環境のクラウドに移る前に、意図した通りのリソースが生成されるかテストできる。Terraformの特徴の1つだ。
ここで、"key"がerror.htmlではなく誤ってindex pageに変更されてしまっていることが分かったので、修正を加えた。変更をマージしてブランチを1つにしたら、これでついにapply（作成した設定コードを適用してクラウド上に生成）を実行できる。
現時点ではapplyとGitHub Actionsとの連携は難しいようだが、「将来的にはGitHub Actionsからapplyもできるようにする予定」と話した。なので今回はTerraformのページに移り、まずgit pullを実行した。変更を取得したら、terraform applyを実行。すると、もう一度planが表示される。ここで最終確認をして問題なければyesと回答し実際に適用する。Webのエラーページを更新すると、意図した通り変更されていることが確認できた。
Hashimoto氏は、「先述のようなシンプルで一般的なミスはTerraformが教えてくれるので、レビュワーはそういった点に気を回す必要がなくなる。また、自分の手で検証したりコードを実行したりすることなく、インフラがどう変化するのか確認できる。これによってインフラとの連携を簡単に、シームレスにできる」とGitHub ActionsとTerraformを組み合わせて活用する利点を語った。
Hashicorpの公式サイトでは、Terraform's GitHub Actionsのスタートガイド（英語）が公開されている。
Dockerイメージを3つの異なるレジストリに同時にポスト―Microsoft
続いてMicrosoftのエンジニアであり、Azureのデベロッパー・アドボケートであるJessie Frazelle氏が登壇した。以前はDockerのメンテナーを務めていた同氏は、個人のエンジニアとしてどうGitHub Actionsを活用したかを発表した。なおこの後Frazelle氏は11月末よりGitHubに正式に移籍することが決定した。
Microsoft Jessie Frazelle氏によるデモの動画
GitHub Actionsを利用する前から、GitHub上で複雑なワークフローを構成していたという同氏。いくつかのリポジトリのボットで複数のツールを組み合わせて動作を実行していた。
これらのボットはGitHub Actionsで置き換えることができる。例えば、プルリクエストがマージされたらブランチを削除する作業や、プロジェクトのイシューを管理するAirtableと各イベントとの同期についても、GitHub Actionsが役立つ。
Frazelle氏は、複雑なワークフローをどう改善するのか、デモを行った。例として見せたのは、Dockerイメージを3つの異なるレジストリにポストする流れ。「こんなことは普通やらないので、マネする必要はない」と前置きしたうえで、まずDocker Hubの2種類のアカウントと、プライベートレジストリを見せた。Frazelle氏は、いくつかのDockerファイルを持っている。これらをGitHubのリポジトリにはもちろん、3つの異なるレジストリにプッシュしなければならない。Frazelle氏はそれを実行するために、GitHub Actionsでワークフローのツリーを構成した。
「GitHub Actionsは、モジュールになっているのがよい。小さなコンポーネントに分けて、このように（ツリーを形成）できる。これまでスクリプトを書いて行っていたことだが、この方法の方がクールだ」
これによって、イメージをビルドしたり、Docker Hubにログインしたり、Google Cloudにストアしたキーを取得したりといった作業が同時にできる。
そしてビルドが終わったあと、他のレジストリ用にイメージにタグ付けをした。全てのキーを取得したら、イメージに署名して、3つのレジストリに全てをプッシュできる。キーは念のためバックアップしておいた。最後に、脆弱性を診断できるように外部ツールを連携した。
「ここまで全てのワークフローをとても簡単に実現できた」とFrazelle氏。もう1つの活用方法として、リポジトリ上でmake-allを実行し、バイナリを生成したりクロスコンパイルしたりするのにも使えるとし、GitHub Actionsの拡張性を強調した。
その他にも、ペット用品専門のECサイト運営会社Chewyや、本番環境に変更をデプロイする際のリスクを抑える管理プラットフォームのLaunchDarklyが、それぞれの視点からGitHub Actionsの使いどころを発表した。詳細はGitHubのブログポストで確認できる。
すでにこうした先行ユーザーたちのワークフローが共有されているのはありがたい。後編では、及川卓也氏をはじめ、日本のエンジニアたちが意見を交わしたアフターイベントの様子をお伝えする。実際にGitHub Universe現地を訪れ、生の発表を聴いた彼らはGitHub Actionsをどう見たのだろうか。
