GitHub Actions

GItHubのbuilt-in CI/CDツール。

GitHub Actions では、エンドツーエンドの継続的インテグレーション (CI) と継続的デプロイメント (CD) 機能をリポジトリに直接ビルドすることができます

Containerを実行することができる。

ワークフローは、Linux、macOS、Windows、コンテナで、’ランナー’と呼ばれるGitHubがホストするマシン上で実行できます

独自ホストでも動作する。

自分が所有もしくは管理するマシン上でワークフローを実行するために、独自にランナーをホストすることもできます

アクションのエコシステムと公開リポジトリのコンテナイメージを利用することができる。

ワークフローの作成には、リポジトリで定義されているアクション、GitHubのパブリックリポジトリにあるオープンソースのアクション、または公開されているDockerコンテナイメージを使用できます。フォークされたリポジトリのワークフローは、デフォルトでは動作しません。

すべてのリポジトリでGitHub Actionsはデフォルトで有効

By default, GitHub Actions is enabled on all repositories.

課金

Public repogitory

無料！

Private repository

デフォルトでは無料枠を越えると利用できない設定になっている。

デフォルトでは料金の上限は$0になっており、この上限に達した後に追加で分やストレージが使われないようになっています

無料枠

GitHubプラン ストレージ Minutes (per month)
GitHub Free 500 MB 2,000
GitHub Pro 1 GB 3,000

同時実行制限

GitHubプラン 最大同時ジョブ 最大同時macOSジョブ
GitHub Free 20 5
GitHub Pro 40 5

ワークフロー

.github/workflowsに保存する

1つのリポジトリに複数のワークフローを作成できます。 ワークフローは、リポジトリのルートにある.github/workflowsディレクトリに保存する必要があります。

YAMLで記述する

ワークフローは YAML 構文で設定し、リポジトリ内にワークフローファイルとして保存する必要があります。

ワークフローファイルの作成

  1. .github/workflowsという名前のディレクトリを作成
  2. .github/workflowsに、ワークフローのため.ymlまたは.yamlファイルを追加
  3. YAMLファイルをカスタマイズ（トリガーイベントとアクション）
  4. ワークフローを実行するブランチにコミット

トリガーイベント

PushやPull RequestのWeb Hookをトリガーに設定できる。

GitHub 上のアクティビティから webhook イベントが作成された際にワークフローを実行するよう設定できます。 ワークフローは、ワークフローの実行をトリガーするための webhook イベントを複数使用できます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
on:
  # プッシュもしくはプルリクエストでワークフローを起動する
  # ただしmasterブランチに対してのみ
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
  # page_buildとリリース作成イベントでも起動
  page_build:
  release:
    types: # この設定は上のpage_buildイベントには影響しない
      - created

Pull RequestのOpen/Closeをトリガーにした記述できる。

たとえば、プルリクエストが assigned、opened、synchronize、または reopened だったときにワークフローを実行できます。

1
2
3
on:
  pull_request:
    types: [assigned, opened, synchronize, reopened]

同一リポジトリ内でファイルマッチを指定してトリガーできる。

push および pull_request イベントを使用する場合、1 つ以上の変更されたファイルが paths-ignore にマッチしない場合や、1 つ以上の変更されたファイルが、設定された paths にマッチする場合にワークフローを実行するように設定できます。

1
2
3
4
on:
  push:
    paths-ignore:
    - 'docs/**'
1
2
3
4
on:
  push:
    paths:
    - '**.js'
1
2
3
4
5
on:
  push:
    paths:
    - 'sub-project/**'
    - '!sub-project/docs/**'

タスクスケジューリングも可能。

POSIX クーロン構文を使用して、特定の UTC 時間にワークフローを実行できるようスケジュール設定できます。 スケジュールしたワークフローは、デフォルトまたはベースブランチの直近のコミットで実行されます。 スケジュールされたワークフローを実行できる最短のインターバルは5分ごとです。

1
2
3
4
on:
  schedule:
    # * はYAMLに置ける特殊文字なので、この文字列は引用符で囲まなければならない
    - cron:  '*/15 * * * *'

ランナー

ジョブの実行環境を選択できる。

Linux、Windows、macOSなど、タイプとバージョンの異なる仮想ホストマシンを選択できます。 ワークフロー内の各ジョブは仮想環境の新しいインスタンスで実行され、1つのジョブ内のステップはファイルシステムを使って情報を共有できます。

1
runs-on: ubuntu-latest

ランナーの環境は/virtual-environmentsで確認することができる。

ビルドマトリクスの設定

複数のランタイムを記述できる。

複数のオペレーティングシステム、プラットフォーム、言語バージョンにまたがって同時にテストするときは、ビルドマトリクスを設定できます。

1
2
3
4
5
runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [ubuntu-16.04, ubuntu-18.04]
    node: [6, 8, 10]

チェックアウトアクション

チェックアウトアクションを使ってリポジトリのコードをコピーする。

リポジトリをビルドしてテストするとき、または継続的インテグレーションを使用するとき、ワークフローにリポジトリのコードのコピーが必要な場合。

1
- uses: actions/checkout@v2

DockerHubのContainerを参照する

DockerHubで公開されているコンテナイメージを利用することができる。

Dockerハブで公開されているDockerコンテナイメージで定義されているアクションは、ワークフローファイルのdocker://{image}:{tag}構文を使用して参照する必要があります。 コードとデータを保護するには、ワークフローで使用する前にDocker HubからのDockerコンテナイメージの整合性を確認してください。

1
2
3
4
5
jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: docker://alpine:3.8

アクションを定義して再利用することもできる。

ワークフローのステータスバッジをリポジトリに追加する

ワークフローがnameキーワードを使用している場合、ワークフローは名前で参照しなければなりません。 ワークフローの名前に空白文字が含まれている場合、その文字をURLエンコードした文字列「%20」に置換する必要があります。

https://github.com/<OWNER>/<REPOSITORY>/workflows/<WORKFLOW_NAME>/badge.svg

Actionによるパブリッククラウド連携

主要なパブリッククラウドプロバイダーが公式のモジュールを公開している。

AWS

Azure

Google Cloud Platform