GitHub Actions を使用したワークフローの構築

このガイドでは、最初の GitHub Actions ワークフローを作成しながら、基本的なコンポーネントと方法を説明します。また、デモリポジトリのセットアップも行い、残りの GitHub Actions の基本モジュールでも使用します。その過程で、Amplifon が開発プロセスを改良するために CI/CD とワークフローオートメーションに GitHub Actions をどう活用したかについて、インサイトとヒントを確認します。

それでは始めましょう!

このガイドの学習内容

GitHub Actions ワークフローファイルを作成する方法
特定の GitHub イベントに応じてワークフローをトリガーする方法
再利用可能なアクションをワークフローで実行する方法
GitHub ホステッドランナーを使ってワークフローを実行する方法

デモリポジトリを使って進める

自動化ラーニングパスを進める場合、デモリポジトリのコピーを作成する必要があります。このデモリポジトリには、のちに GitHub Actions を使って GitHub Pages にデプロイするサンプル Web アプリケーションが含まれます。他には、このモジュールの間に demo-files ディレクトリで作成される全てのファイルのコピーも含まれます。

actions-learning-pathway リポジトリを新しいタブで開きます。
ファイルリストの上にある [このテンプレートを使用する] をクリックし、[新しいリポジトリを作成する] を選択します。
[オーナー] ドロップダウンメニューでリポジトリを所有するアカウントを選択します。
リポジトリに actions-learning-pathway と名前を付け、後で見つけやすいように簡単な説明を加えます。
リポジトリのデフォルトの可視性をパブリックに設定します。プライベートリポジトリは GitHub Actions の時間を消費しますが、パブリックリポジトリは無料の GitHub ホステッドランナーを使用できるからです。
[テンプレートからリポジトリを作成する] をクリックすれば、最初の GitHub Actions ワークフローを構築する準備は完了です!

最初の GitHub Actions ワークフローを作成する

GitHub Actions ワークフローは構成可能な自動化されたプロセスであり、YAML を使って定義される 1 つ以上のジョブでできています。ワークフローは特定の構造をとり、リポジトリの .github/workflows ディレクトリに保存されます。新しいワークフローを作成するには、.github/workflows ディレクトリに新しい YAML ファイルを作る方法と、リポジトリの GitHub Actions タブから作る方法の 2 つがあります。最初の方法はシンプルで分かりやすいものの、2 つ目のほうが有利な点がいくつかあります。今回は 2 つ目の方法を選択します。

リポジトリの [GitHub Actions] タブに移動し、[新しいワークフロー] をクリックします。

ひととおり画面を確認すると、リポジトリにあるコードの言語を基に GitHub がさまざまなスターターワークフローを提案していることが分かります。この例では、actions-learning-pathway リポジトリに JavaScript と Node.js のファイルが格納されているため、主にこれらの言語向けの提案になっています。

The Choose a workflow page shows suggestions for actions according to the languages used in the repository and allows a user to search for workflows.

また、デプロイメント、セキュリティ、継続的インテグレーション、自動化、GitHub Pages など、カテゴリー別に整理されたワークフローの一覧や、推奨事項を絞り込むための検索バーもあります。ゼロから構築する前に、ぜひこのページをよく調べることをお勧めします。

ただし、今回はワークフローファイルの基礎について学ぶことが目的のため、ゼロから始めましょう。

[自分でワークフローをセットアップする] をクリックして、リポジトリの .github/workflows ディレクトリにある空の YAML ファイルの編集を始めます。ファイルに次のように名前を付けます。hello-world.yml.

これで最初の GitHub Actions ワークフローを構築する準備ができました!

Actions は当社の CI/CD パイプラインを構築する上で大きな変革をもたらしてくれました。 当社は、予測不可能なデプロイ、作業グループ間で重複してしまうコード作成、非効率な手動プロセスという問題を抱えていました。ワークフローオートメーションを採用することにより、デプロイの迅速化、リリース管理の改善、コード再利用と知識共有の強化など、目覚ましい進歩が見られました。

今では、ブラウザから直接コーディング、構築、配布ができるようになりました。Actions は強力かつ柔軟なツールであり、当社のイノベーションとスケールの能力を押し広げています。

Bernat Nosas Comerma // Lead of Global DevOps // Amplifon

編集するファイルと、それを行う場所ができたので、誰かがリポジトリにプッシュするたびに自動的に「Hello World!」と言うワークフローを構築します。ファイルを記述し、その過程でステップについて説明します。コードは 1 行ずつ記述することも、最後にあるサンプルをコピーして他のステップに沿って行うこともできます。

ワークフローに名前を付ける

name: hello-world

ワークフローに内容を説明した name を付けることで、読みやすくなるだけでなく、他の人が各コンポーネントを調べなくてもワークフローの目的を理解しやすくなります。このケースでは、典型的な「Hello world」を記述しているので、これを名前にします。hello-world.

ワークフローのトリガーイベントを設定する

全てのワークフローファイルは、実行をトリガーする 1 つ以上のイベントが必要です。イベントは、プルリクエストのオープンから問題に対するコメント追加、他のワークフローの正常な完了まで、大半の GitHub アクティビティをカバーしています。その他にも、API コールを介して GitHub の外部からワークフローをトリガーし、repository-dispatch イベントをトリガーすることもできます。これらのイベントは他のツールとやり取りする柔軟性を維持しつつ、CI/CD パイプラインと開発を支えるプラットフォームとの間の緊密なインテグレーションのためのシンプルな手段を提供します。

今回の hello-world サンプルではシンプルに、次のワークフローイベントを設定します。push.

name: hello-world
on: push

ここでは push イベントは、コミットまたはタグをプッシュするか、テンプレートからリポジトリを作成するとワークフローを実行します。つまり、hello-world.yml の記述とコミットが完了したときに、ワークフローが実行されます。しかし、まずは何をするかを指示する必要があります。

ジョブを定義する

続いては、ジョブを作成することで、ワークフローを実行すると何が起きるかを定義する必要があります。全てのワークフローには 1 つ以上のジョブがあり、ジョブは相互に関連した実行可能なステップで構成されます。

ワークフローの jobs: セクションから始め、ジョブに次のように名前を付けます。hello-world-job.

name: hello-world
on: push
jobs: 
  hello-world-job:

デフォルトではジョブは独立して機能し、並行して実行されますが、他のジョブが完了してからジョブが開始するように構成することもできます。たとえば、異なるアーキテクチャに同時並行で実行される個別のビルドジョブを複数作成し、全てのビルドジョブが正常に完了するまで後続のパッケージ化ジョブが始まらないような構成が可能です。

ランナーを指定する

ランナーとは、ワークフローのジョブを実行するマシンです。GitHub ホステッドランナーとセルフホステッドランナーの基本の 2 種類があります。

セルフホステッドランナーは、ユーザーが GitHub Actions ジョブを実行するために自分のインフラストラクチャでデプロイし管理するシステムです。

GitHub ホステッドランナーは新たにプロビジョニングされる仮想マシンで、Ubuntu Linux、Microsoft Windows　または macOS を実行します。GitHub ホステッドランナーを選択する場合、特定の OS バージョンを指定するか、-latest と指定して最新の安定したイメージを使用できます。また、Organization 全体のアクセス制御向けのランナーグループなど、追加機能を備えたより大きなランナーバージョンも用意しています。

ほとんどの状況で GitHub ホステッドランナーを使用することをお勧めしますが (オーバーヘッドが不要になり、簡単になるため)、セルフホステッドランナーが役立つケースについてもガイドの後半で取り上げます。

今回は GitHub ホステッドランナーで Ubuntu-latest を使用します。

name: hello-world
on: push
jobs: 
  hello-world-job:
    runs-on: ubuntu-latest

セルフホステッドランナーは 14 日間ジョブを実行しないと停止します (一時的なセルフホステッドランナーは Actions に接続しない期間が 1 日を超えると自動的に GitHub から削除されます)。これに対応するするために、当社ではほとんどのリポジトリで 12 日ごとにジョブを開始するイベントを設定しています。このような定期的なメンテナンスタスクを行えば、セルフホステッドランナーを稼働した状態に保ち、必要なときに利用できます。

Bernat Nosas Comerma // Lead of Global DevOps // Amplifon

最初のアクションを実行するステップを追加する

すでに説明したとおり、ジョブはそれぞれ 1 つ以上のステップで構成されています。各ステップはユーザーが定義するスクリプトを実行するか、アクションを実行することができます。アクションはワークフローを簡素化できる再利用可能な拡張機能です。ユーザーはカスタムのアクションを記述することも、GitHub Marketplace にあるアクションを使用することもできます。GitHub Marketplace にはコードレビューから依存関係管理、セキュリティまで、ありとあらゆるアクションが何千個とそろっています。

サードパーティのアクションを使えばコードの繰り返しを減らせるだけでなく、広範な GitHub 開発者エコシステムを存分に活用できます。すでにあるものを利用すれば、わざわざカスタムインテグレーションを記述する必要はありません。

GitHub からスターターワークフローが提案されるのと同様に、役立つと考えられるアクションが GitHub.com のエディターから直接提案されるので、アクションをその場で簡単に採用できます。

今回の hello-world ワークフローでは、ワークフローにリポジトリのコンテンツへのアクセスを許可するチェックアウトアクションから始め、それに対してスクリプトや他のアクション (構築ツールやテストツールの実行など) を実行できるようにします。ワークフローがリポジトリのコンテンツへのアクセスを必要とするときは常に、checkout アクションを使います。

name: hello-world
on: push
jobs: 
  hello-world-job:
    runs-on: ubuntu-latest
    steps: 
      - name: Check out repository code
        uses: actions/checkout@v3

まずは、ステップに name を付けます。これは省略しても構いませんが、名前はログに記録され、ワークフローがさらに複雑になったときにエラーを追跡しやすくなるため、良い方法だと言えます。

次に、uses: actions/checkout@v3 と記述して、このステップで @v3 の checkout アクションを使うことを指定します。依存関係と同様に、アクションの更新を自動的に受け入れるかどうかに基づいて、使用するアクションのバージョンを指定してください。GitHub Marketplace でアクションを探せば、最新バージョンのアクションが見つかります。バージョンを指定しない場合、自動的に最新バージョンが使用されるため、アクションに互換性を破る変更が加えられた際にワークフローが壊れる可能性があります。

「Hello World」と発信する

最後に、actions-learning-pathway リポジトリのファイルに保存した「Hello World!」というフレーズをエコーする bash スクリプトを実行するためのステップを追加します。ここでは checkout アクションが bash スクリプトに hello-world.txt ファイルへのアクセスを許可することで、ファイルの内容をエコーできるようになっています。

name: hello-world
on: push
jobs: 
  hello-world-job:
    runs-on: ubuntu-latest
    steps: 
      - name: Check out repository code
        uses: actions/checkout@v3
      - run: echo "$(cat hello_world.txt)"

最後のステップを追加したら、ワークフローを保存し、GitHub Actions のアクションを見ることができます。

[変更をコミットする…] をクリックします
コミットメッセージを入力し、ダイアログボックスの [変更をコミットする] をクリックします。

画面がリポジトリの .github/workflows ディレクトリに変わり、新しく作成した hello-world.yml ワークフローファイルを確認できます。ファイルをリポジトリにプッシュしたばかりで、ワークフローが on: pushを実行するように設定されているので、うまくできているか見てみましょう!

[GitHub Actions] タブを選択します。
[Say hello world!] (最終ステップで付けた名前) をクリックして、正常に動作するか確認します。

The individual steps of the hello-world-job are listed out, with the "Say hello world!" step expanded to show the results.

全てが適切に設定できていれば、全てのジョブが画面にリストされ、その隣にジョブの実行にかかった時間がそれぞれ表示されます。エラーが発生した場合、記述したコードが今までに説明したコードと一致するか確認してください。空白の有無も区別され、YAML のスペーシングが誤っているとエラーになるので注意してください。

[Say hello world!] ステップを展開すると、ワークフローファイルが $(cat hello_world.txt)を実行し、「こんにちは! おめでとうございます。最初の GitHub Actions ワークフローファイルを正常に構築し、実行できました!」というログが返されます。

成功です!

次の項目: GitHub Actions でアプリケーションを構築する

これで GitHub Actions の基本的なビルドブロックについて学ぶことができたので、次はこれを生かして「Hello world!」メッセージをログに記述するよりも、もう少し楽しくて役に立つことをやってみましょう。シンプルな CI/CD ワークフローを記述して、Web アプリケーションを GitHub Actions を使って GitHub Pages にデプロイします。GitHub Actions を使ったアプリケーションの構築から始めます。

デモ リポジトリを使って進める