はじめに

GitHub Actionsに入門する際、知っとくといい最低限の内容をまとめてみた。

GitHub Actionsとは

GitHubだけでCI/CD的な機能を実現するもの。 CI/CDの処理は、GitHubが提供するサーバー上の仮想マシン内で実行できるため、ユーザーが独自にサーバーを準備する必要はない。

CI/CDとは

CIはContinuous Integration(継続的インテグレーション)のことで、ソフトウェアのビルドやテストを自動化して頻繁に実行することでソフトウェアの品質向上や開発効率化を目指す手法。

CDはContinuous Delivery(継続的デリバリー)のことで、CIに加えてリリースやデプロイまでも自動化する手法。 CI/CDは、基本的にはGitなどのバージョン管理システムと組み合わせての利用が前提となっている。

たとえば、多くのCI/CDツールではリポジトリへのプッシュやマージ、プルリクエストなどをトリガーにしている。

ワークフロー作成の方法

ワークフローの作成は以下の二つの方法で行えそう

  • GitHub Actions関連の設定は、リポジトリの「Actions」タブから行う
  • リポジトリのルートディレクトリ直下にある.github/workflowsディレクトリ内にYAML形式のファイルに記述することでワークフローを定義する

ワークフローファイルの中身

下記では最低限のワークフローファイルの書き方を説明する。 詳しいファイルの書き方はWorkflow syntax for GitHub Actionsを参照する。

ワークフローを起動するトリガーの指定(on要素)

  • ワークフローを起動するトリガーとなるイベント、もしくはワークフローを起動する時刻を記述するもの

    • リポジトリへのプッシュが行われた際にワークフローを起動したい場合、次のように「push」を指定する。

      on: push

  • ここで指定できるイベントはEvents that trigger workflowsに記載されている

  • 特定のイベントではなく、決まった日、時刻にワークフローを実行させたい場合は、「on.schedule」要素で日時の指定を行う。

    on:
  schedule:
    - cron: '30 * * * *'

ワークフローを実行する仮想マシン環境の指定(runs-on要素)

  • ワークフローを実行する仮想マシン環境を指定する
  • 「GitHubホストランナー」と「セルフホストランナー」のいずれかを設定する

GitHubホストランナー

  • GitHubがあらかじめ用意している実行環境でワークフローを実行する

    • たとえばUbuntu 18.04環境でワークフローを実行したい場合は下記のようにする

      runs-on: ubuntu-18.04
  • 2020/06/17時点で利用可能なものは下記(GitHub Actionsのワークフロー構文より)

セルフホストランナー

  • ユーザーが独自に用意した実行環境でワークフローを実行する
  • 詳しくはAbout self-hosted runners を参照

実行する処理を記述する(jobs要素)

  • 1つのワークフロー実行は、1つ以上のジョブからなる
  • それぞれのジョブはruns-onで指定された環境で実行される

jobs内の要素

  • job id
    • ジョブを参照する際などに使われる一意な文字列
  • job name
    • 管理画面などに表示される名前として使われる文字列
  • steps
    • 各ジョブで実行する処理を記述するオブジェクトのリスト
    • stepの「name」
      • 処理内容を示す名前
    • stepの「run」
      • （シェル経由で)実行するコマンドを指定
jobs:
  <job id>:
    name: <job name>
    steps:
      - name: <step name1>
        run:
      - name: <step name2>
        run:
  • uses
    • steps以下ではrun要素ではなくuses要素を指定することで、任意のActionを実行したり、指定したDockerコンテナを起動してその中で指定した処理を実行したりできる。

逐次的なジョブの実行

デフォルトでは、ジョブは並行して実行される。 ジョブを逐次的に実行するには、jobs.<job_id>.needsなどとして他のジョブに対する依存関係を定義

jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]

秘匿情報などはSECRETで管理する

GitHub Actionsでは、リポジトリやワークフロー設定ファイル中に認証情報などの秘密情報を格納することは避けるべきだとされている。 そういった秘密情報をワークフロー内で扱いたい場合、「encrypted secrets」という仕組みを利用する。

encrypted secrets

encrypted secretsは、事前にリポジトリの設定画面から秘密情報（「secret」）を登録しておくことで、この情報に安全にアクセスするための手段を提供する仕組みである。 登録した秘密情報は、ワークフロー設定ファイル内からはコンテキスト（「{{ Secrets.＜名前＞ }}」）を使って参照できる。

encrypted secretsの利用

encrypted secretsを利用するには、まずリポジトリの設定画面内の「Secrets」から使用したい情報を登録する。 なお、一度入力した情報はその後は閲覧・編集できないので注意。 対応する値を変更したい場合は、一度削除してもう一度同じ「Name」を指定して再作成する。 登録できるデータは最大64KBまでという制約がある。それ以上のデータを登録したい場合は、ファイルを暗号化してリポジトリ内に格納しておき、それを復号するためのキーをSecrets経由で与えてワークフロー内で復号する、という手法がある。 詳しくはドキュメントのCreating and storing encrypted secretsに書かれている。

最後に

ソースコードのバージョン管理に多くの人が用いているであろうGitHubで容易にCI/CD導入ができてしまうのは、非常にありがたいことである。

参考