はじめに
皆さんこんにちは。GitHubの水谷です。GitHubでは、エンタープライズサポートエンジニアという肩書きで、GitHubの企業向け製品であるGitHub Enterpriseのテクニカルサポートをしています。
GitHubは、2018年10月に開催された開発者のためのカンファレンス、GitHub UniverseにてGitHub Actionsを発表しました。2019年4月2日現在、GitHub Actionsはまだ一般提供されている機能ではなく利用申請が必要なベータ版ですが、一般提供に向けて開発が進んでいます。この記事では、一般提供に先立ってGitHub Actionについて実例を交えて詳しく紹介します。
ベータ版について
利用申請の処理が進みベータ版の利用者になると、リポジトリのPull requestsタブの右にActionsタブが現れます。この記事ではActionの実例も紹介しますが、ベータ版の利用者ではない場合は直接閲覧できない画面があります。記事中ではなるべくスクリーンショットを付けて紹介していますが、まだベータ版の利用申請を行っていない方は、ぜひこの機会にGitHub Actionsのページから申請してみてください。
なお、正式なリリースまでに仕様が変わる可能性があるので、最新の情報はGitHub Actions changelogを参照して下さい。また、ベータ版での提供中は、本番環境などでの利用は非推奨です。まずは個人的なプロジェクトなどで試すようにしてください。
現在のソフトウェア開発における課題
ソフトウェア開発を取り巻く環境は日々変化し、様々なツールやライブラリが次々と登場する時代がやってきました。これまで人が行っていた作業やハードウェアが実行していたタスクは、どんどんソフトウェアに置き換えられ、我々はソフトウェアに覆われた世界に向かって加速しています。これは喜ばしいことですが、一方で新しいツールができることや、それらを正しく連携させるための設定はどんどん複雑化し、本来の目的だったソフトウェア開発のために十分な時間を取れないといったケースが増えています。
以下の図をご覧ください。これはCloud Native Computing Foundationが作成している、代表的なクラウド関連テクノロジーの一覧です。
CNCFが公開しているクラウド関連テクノロジーの一覧（出典：CNCF Cloud Native Interactive landscape）
ソフトウェアのソースコードを一定の品質に保ちつつ速いサイクルで開発・デプロイするために、現代ではこれだけ多様な技術が使われるようになりました。テスト、ビルド、デプロイのパターンだけでも多くの選択肢があり、その他のツールの利用も含めると組み合わせは無限にあります。苦労してプロジェクトに最適な組み合わせを見つけ、ワークフローを作り上げたとしても、今まではそれをコードとして記述するスタンダードな方法がなかったので、GitHub上で共有したり再利用することができないという問題がありました。
GitHubの利用形態について分析すると、全ユーザの約60％がリポジトリと何らかの外部ツールやサービスを連携させている、という結果がわかっていました。そこでGitHubでは、ソフトウェア開発のプラットフォームとしてこの問題を解決し、開発者の体験をより良いものにするにはどうしたらいいか考え、2018年10月にGitHub Actionsを発表しました。
GitHub Actionsとは
GitHub Actionsの概要（出典：Features・GitHub Actions）
GitHub Actionsを一言で説明するならば「GitHub上で動作するサーバレス実行環境」です。上記のブログ記事の英語版では "built by you, run by us" と謳っていますが、実はGitHubが自分たちのインフラ上でユーザの代わりにコマンドやコードを実行するのは本機能が初めてのことです。
GitHub上のサーバレス実行環境が上記の問題をどのように解決するのか、これから順を追って解説してきます。まず最初にGitHub Actionsの構成単位であるActionと、それを組み合わせるWorkflowについて紹介します。
Action
Actionの実体はDockerコンテナです。ユーザはGitHubのインフラ上で任意のDockerイメージからコンテナを起動し、その中で任意のコマンドやスクリプトを実行できます。どんなDockerイメージを使っても、リポジトリのデータがコンテナ内にマウントされた状態になるので、コマンドやスクリプトからソースコードに直接アクセス可能です。また、データ領域はAction間で共有されるので、あるActionで実行した結果を次のActionで利用できます。
Actionの利用方法は3つあります。
- GitHub上にすでに存在するActionを指定する
- 対象リポジトリ内にDockerfileを作成することで、独自のActionを定義する
- Dockerレジストリ上のDockerイメージを指定する
この利用方法からわかる通り、Actionは簡単に共有・再利用できる、一種のモジュールと呼べるでしょう。
Workflow
複数のActionを組み合わせ、実行する順番を定義することで独自のワークフローを構築できます。これをWorkflowと呼びます。Workflowは米HashiCorp社が開発した設定記述言語HCL （HashiCorp Configuration Language）をベースにした形式で記述します。コード化されることで、Infrastructure as CodeのようにWorkflow as Codeを実現でき、共有・再利用・コラボレーションが可能になります。下記は、1つのActionで構成される単純なWorkflowの例です。このWorkflowについては後の章で詳しく説明します。
workflow "Delete the branch on pull request merge" {
on = "pull_request"
resolves = ["branch cleanup"]
}
action "branch cleanup" {
uses = "jessfraz/branch-cleanup-action@master"
secrets = ["GITHUB_TOKEN"]
}
Workflowはリポジトリ直下の.githubディレクトリにmain.workflowというファイル名で配置する決まりになっています。テキストエディタで書いてもよいですが、GitHubはWorkflow用のビジュアルエディタを提供しているので、そちらを利用するのがお勧めです。
2019年4月現在、Workflowの動作トリガーは27種類のフックイベントから選べます。代表的なpushイベントだけでなく、GitHubで起きた様々なイベントをきっかけに任意のWorkflowを開始できます。特にRepositoryDispatchは少し特殊なイベントで、これによってGitHub上のフックイベントだけではなく外部からもWorkflowをトリガーできるので、様々なツールとの連携が可能です。
まずはHello Worldを試してみよう
今年1月、GitHubは無料アカウントでもプライベートリポジトリを無制限に作成できるようにプランの変更を行いました。この機会に、GitHub Actions試すためのプライベートリポジトリを作成し、まずはHello world workflow exampleを実践してみて下さい。感覚がつかめると思います。
