GitHub Actionsを調べてみた

背景・目的

GitHub Actionsについて、あまり理解してなかったので、GitHub Actions のドキュメントをもとに整理し、簡単に動作確認してみます。

まとめ

GitHub Actionは、下記の特徴があります。

• CI/CDプラットフォーム

• イベント発生時に様々なワークフローが実行可能

• 実行環境は様々なOSのマシンが提供される。

• 下記のコンポーネントを有します。

  コンポーネント	概要
  Workflows	1つ以上のジョブを実行する。 イベント、スケジュール、手動で実行が可能
  Runner	ワークフローが実行される環境
  Job	1つ以上のステップで構成される

概要

GitHub Actions を理解する

GitHub Actions を理解するを元に整理します。

概要

GitHub Actions は、ビルド、テスト、デプロイのパイプラインを自動化できる継続的インテグレーションと継続的デリバリー (CI/CD) のプラットフォームです。 リポジトリに対するすべての pull request をビルドしてテストしたり、マージされた pull request を運用環境にデプロイしたりするワークフローを作成できます。

• CI/CDのプラットフォームである。

GitHub Actions は、DevOps であるだけでなく、リポジトリで他のイベントが発生したときにワークフローを実行できます。 たとえば、リポジトリで新しい issue が作成されるたびに、適切なラベルを自動的に追加するワークフローを実行できます。

• イベント発生時にワークフローを実行できる。

GitHub では、ワークフローを実行するための Linux、Windows、macOS 仮想マシンが提供されます。また、自身のデータセンターまたはクラウド インフラストラクチャで独自のセルフホスト ランナーをホストすることもできます。

• ワークフロー実行のための様々なOSの仮想マシンが提供される。

GitHub Actions のコンポーネント

リポジトリで、pull request のオープンや issue の作成などの イベント が発生したときにトリガーされるように GitHub Actions ワークフロー を構成できます。 ワークフローには、1 つ以上の ジョブ が含まれており、ジョブは順次にまたは並列で実行できます。 各ジョブは、専用の仮想マシン ランナー 内、またはコンテナー内で実行され、定義した スクリプト を実行するか、または アクション (ワークフローを簡略化できる再利用可能な拡張機能) を実行する 1 つ以上のステップで構成されます。

• イベントトリガーでGitHub Actionsワークフローを実行できる
• ワークフローには1つ以上のジョブが含まれる。
• ジョブ
  • 1つ以上のステップで構成される。
  • 順次、または並列で実行される
  • 専用の仮想マシンランナー内、またはコンテナー内で実行される
• ステップ
  • 下記が実行可能である。
    • 定義したスクリプト
    • アクションを実行する1つ以上のステップ

Workflows

ワークフローは、1 つ以上のジョブを実行する構成可能な自動化プロセスです。 ワークフローは、リポジトリにチェックインされる YAML ファイルによって定義され、リポジトリ内のイベントによってトリガーされたときに実行されます。また、手動でトリガーしたり、定義されたスケジュールでトリガーしたりすることもできます。

• 1つ以上のジョブを実行する構成可能な自動化プロセス。
• YAMLファイルで定義。
• 下記のトリガーで実行が可能である
  • イベント
  • 手動
  • スケジュール

ワークフローはリポジトリ内の .github/workflows ディレクトリで定義され、リポジトリには複数のワークフローを含めることができます。各ワークフローは、それぞれ異なる一連のタスクを実行できます。 たとえば、あるワークフローでは、pull request をビルドしてテストし、別のワークフローでは、リリースが作成されるたびにアプリケーションをデプロイし、さらに別のワークフローでは、新しい issue が開かれるたびにラベルを追加することができます。

イベント

イベントは、ワークフロー実行をトリガーする、リポジトリ内の特定のアクティビティです。 たとえば、pull request が作成されたとき、issue が開かれたとき、またはリポジトリにコミットがプッシュされたときに、GitHub からアクティビティを発生させることができます。 また、スケジュールに従って、REST API に投稿して、または手動で、ワークフロー実行をトリガーすることもできます。

• リポジトリ内の特定のアクティビティ

ジョブ

ジョブは、同じランナーで実行される、ワークフロー内の一連の ステップ です。 各ステップは、実行されるシェル スクリプト、または実行される アクション のいずれかです。 ステップは順番に実行され、相互に依存します。 各ステップは同じランナーで実行されるため、あるステップから別のステップにデータを共有できます。 たとえば、アプリケーションをビルドするステップの後に、ビルドされたアプリケーションをテストするステップを続けることができます。

• ワークフロー内の一連のステップ
• 各ステップは、スクリプト or アクション
• ステップ間は、データ共有できる

ジョブと他のジョブとの依存関係を構成できます。既定では、ジョブに依存関係はなく、相互に並列で実行されます。 ジョブが別のジョブに依存する場合、依存ジョブが完了するまで待ってから実行されます。 たとえば、異なるアーキテクチャ用で依存関係のない複数のビルド ジョブがあり、それらのジョブに依存するパッケージ化ジョブがあるとします。 ビルド ジョブは並列で実行され、それらがすべて正常に完了したら、パッケージ化ジョブが実行されます。

• ジョブ間で依存関係を構成できる

アクション

アクション は、GitHub Actions 用のカスタム アプリケーションであり、複雑で頻繁に繰り返されるタスクを実行します。 アクションを使用すると、ワークフロー ファイルに記述する繰り返しコードの量を削減するのに役立ちます。 アクションでは、GitHub からの Git リポジトリのプル、ビルド環境に適したツールチェーンの設定、またはクラウド プロバイダーに対する認証の設定を実行できます。

独自のアクションを記述することも、GitHub Marketplace で、ワークフローで使用するアクションを見つけることもできます。

• カスタムアプリケーション

ランナー

ランナーは、ワークフローがトリガーされると実行されるサーバーです。 各ランナーでは、一度に 1 つのジョブを実行できます。 GitHub では、ワークフローを実行するために、Ubuntu Linux、Microsoft Windows、macOS ランナーが提供されます。各ワークフロー実行は、新しくプロビジョニングされた仮想マシンで実行されます。 GitHub には、より大きな構成で使うことができる より大きなランナー も用意されています。 詳しくは、「より大きなランナーの概要」を参照してください。 別のオペレーティング システムまたは特定のハードウェア構成が必要な場合、独自のランナーをホストできます。 セルフホステッド ランナーについて詳しくは、「自分のランナーをホストする」をご覧ください。

• ワークフローがトリガーされると実行されるサーバ
• 様々なOSのランナーが提供される

実践

前提

1. リポジトリを作成します。

サンプルワークフローを作成する

サンプルワークフローを作成するを元に試してみます。

1. 作成したリポジトリをcloneします。

2. ディレクトリを作成します。

   $ mkdir -p .github/workflows
   

3. 下記のファイルを作成します。

   $ cat learn-github-actions.yml 
   name: learn-github-actions
   run-name: ${{ github.actor }} is learning GitHub Actions
   on: [push]
   jobs:
     check-bats-version:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - uses: actions/setup-node@v3
           with:
             node-version: '14'
         - run: npm install -g bats
         - run: bats -v
   
   $ 
   

   • それぞれの項目の意味は、下記の通りです。

   項目	説明
   name	アクションタブに表示されるワークフロー名
   run-name	ワークフローを実行したユーザ名
   on: [push]	ワークフローのトリガー。この場合、Pushイベントが指定されている
   jobs:	ワークフローで実行される全てのジョブをグループ化する
   runs-on: ubuntu-latest	実行するジョブのマシン
   steps:	check-bats-versionジョブで実行される全てのステップをグループ化する。この下に欠かされていいる各項目は、個別のアクション or シェルスクリプト
   uses: actions/checkout@v4	usesキーワード。ワークフローでリポジトリのコードを使用する場合は、常にチェックアウトアウトアクションを使用する必要がある。
   uses: actions/setup-node@v3 　with: 　　node-version: '14'	指定されたバージョンの　Node．jsをインストールする
   - run: npm install -g bats	batsをインストールしている。

   ※batsとは？

4. commit後、git push します。

   $ git push origin main
   Enumerating objects: 6, done.
   Counting objects: 100% (6/6), done.
   Delta compression using up to 8 threads
   Compressing objects: 100% (4/4), done.
   Writing objects: 100% (5/5), 600 bytes | 300.00 KiB/s, done.
   Total 5 (delta 0), reused 0 (delta 0)
   To github.com:zumastee/test-githubaction.git
      5d1e528..b331f43  main -> main
   $
   

ワークフロー実行のアクティビティの表示

1. GitHubにログインし、当該リポジトリに遷移します。

2. 「Actions」タブをクリックします。
   

3. ナビゲーションペインで、作成したワークフローをクリックします。
   

4. check-bats-versionをクリックします。
   

5. 一通り実行されていることがわかります。
   

考察

今回、GitHubアクションについて簡単に試してみました。今後も継続して試してみます。

参考