GitHub Actions 実践入門が安くなってたのでメモを取りながら流し読みしています。基本的にこの本に書いてあることのまとめ+αです。かなりいろいろできるんだなぁという印象。
実行環境
- ジョブに
container
を指定しないとVM上で直接実行される - VM
- AzureのStandard_DS2_v2
- vCPU: 2
- メモリ: 7GiB
- SSD: 14GiB
- LinuxはUbuntu
- パスワードなしでsudo可
- インストール済みソフト一覧
- AzureのStandard_DS2_v2
コンテナの実行
container
を指定するとジョブ内の全ステップがそのコンテナ上で実行される- ファイルシステムのマウントもできる
$HOME
と$GITHUB_WORKSPACE
がデフォルトでマウントされる
- サービスコンテナを立ち上げることも可能
- テスト用のDBコンテナ等
セルフホストランナー
- 自前のマシン、VM、コンテナなどで実行できる
- 使いどころ
- CPU やメモリを激しく消費するジョブを実行したい
- プライベートネットワーク内でジョブを実行したい
- GitHub が提供していない OS 上でジョブを実行したい
- リポジトリ、オーガナイゼーション単位で追加できる
- actions/runnerから取得できる
- 中にあるスクリプトを実行したら起動する
- 通常のVMとの違い
- 複数のジョブ実行間で環境を持ち越すことができる
- 実行毎のクリーンな環境とはならないので注意
- プライベートリポジトリでも完全無料
- 複数のジョブ実行間で環境を持ち越すことができる
- セキュリティ上パブリックリポジトリではセルフホストランナーは非推奨
- 危険なコードが実行される恐れがあるため
構成要素
- ワークフロー
- ジョブ
- ステップ
- アクション
- ステップ
- ジョブ
ワークフロー
- .github/workflows/xxx.yamlと1対1で対応
- 複数のジョブから構成される
ジョブ
- 複数のステップから構成される
- ジョブ毎に実行されるVMが変わる
- ジョブ間でのファイルのやりとりはアーティファクトを利用する
ステップ
- 複数のアクションから構成される
- ステップ内は同じVMで実行される
- ステップ間でのファイルのやり取りはファイルシステムを利用できる
アクション
- 具体的な処理
- shellコマンドやpythonスクリプトなどで自分で書ける
- ENTRYPOINTつきのDockerfileとaction.ymlを用意するとコンテナアクションを作れる
- 再利用、配布が可能な形でも記述できる
- 自リポジトリの相対パス: ./.github/actions/
- 外部リポジトリ直下: https://github.com/actions/checkout
- 外部リポジトリのサブディレクトリ: GoogleCloudPlatform/github-actions/setup-gcloud
- Dockerイメージ: docker://gcr.io/cloud-builders/gcloud
- 公式のアクション集が github.com/actions
- そのほかはマーケットプレイスで探せそう
- https://github.com/marketplace/actions/assign-to-one-project
- 機密情報とかの扱いもあるから公式以外のものを使うときは注意した方が良さそう
- そのほかはマーケットプレイスで探せそう
その他
秘密情報
- リポジトリの Settings -> Secrets から登録できる
- 100個まで
- 64KBまで
${{ secrets.NAME }}
で参照可能
- マスクされるけどJSONとかはマスクされない可能性も
- 複雑な情報は外部サービスや暗号化も併用した方がいい
- GCPなら Secret Manger かな
- 複雑な情報は外部サービスや暗号化も併用した方がいい
- AdminならOrganization 単位でもSecretsを登録できる
GITHUB_TOKEN
${{ secrets.GITHUB_TOKEN }}
はワークフロー実行時に自動で設定される--header 'Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}'
のように使うとリポジトリにアクセスできる- forkしたときはread権限になる
キャッシュ
- actions/cacheを使うとキャッシュを利用できる
- pushとpull_requestでのみ利用可能
- ファイルパスを指定する
- 内容の一致するかどうかはkeyが一致するかどうかで判定される
- keyが一致したら書き込みはスキップされる
- つまり上書きや削除はできない
- ジョブの成功時のみ保存される
- forkしてPRを投げた際にもキャッシュは利用される
- 機密情報をキャッシュに保存するのはNG
- キャッシュの保存期間
- 7日間
- 1つあたり2GBまで
- リポジトリ全体で50GBまで
アーティファクト
- actions/upload-artifactを使うとアーティファクトに成果物を保存できる
- 指定したディレクトリ以下のファイルがzip形式で保存される
- 同一ビルド内で名前が同じだと上書きされる
- マトリクスビルド利用時などは注意
- actions/download-artifactでダウンロードも可能
- ジョブ間でのデータの受け渡しに利用できる
- actions/download-artifactではワークフローは跨げない
- REST APIなどを利用する必要あり
- 無理にアーティファクトを使わずに、gsutilでアップロードしたりreleasesを使う方が良い場合も多そう
- コードのバージョンと1対1で紐づくものはrelease、ビルド毎の成果物はアーティファクトがいいかも
ワークフローの実行
- pushやPRだけでなくIssueの作成などもトリガーにできる
- ブランチ、タグ、ファイルパスでワークフローが実行されるタイミングをコントロールできる
- 正規表現が使える
- イベントによっては types でアクティビティを指定可能(例.
on: issue_comment: types: ['created', 'edited']
)
on: repository_dispatch
で web API から実行可能- 昨日(2020/07/06)の公式ブログでweb UIから実行できる機能が紹介されてた
その他
defaults
でワークフローやジョブ単位でデフォルトの挙動を指定可能env
でワークフローやジョブ単位で環境変数を指定可能- GITHUB_XXX環境変数は定義済み(GITHUB_REPOSITORY, GITHUB_SHA...etc)
- コンテキスト経由でステップのアウトプットにアクセス可能
- if文で使うと条件によるジョブのスキップなども可能
- ジョブ間の依存関係は needs で指定可能
- echo "::<COMMAND> ..."でコマンドを実行できる
- 環境変数の設定、アウトプットの設定、ログのマスクなど