GitHub Actions チート シート

GitHub Actions を使用すると、コードの保存やコラボレーションを行うのと同じ場所でソフトウェア開発のワークフローを自動化できます。個々のアクションはコードの一部であり、再利用が可能なため、それらを使用することで GitHub でのプロジェクトのビルド、テスト、パッケージ化、導入を行うことができます。また、アクションを使用してワークフローの任意のステップを自動化することもできます。

次の 4 つのシンプルなステップで開始できます。

1. リポジトリ内で、GitHub Actions を示すタブをクリックする
   GitHub Actions は、ユーザーのコード、および GitHub の他のエクスペリエンスと緊密に統合されています。
2. プロジェクトのタイプに最適なワークフローを選択する
   GitHub Actions には、Node.js、Rust、.NET Core 用のテンプレートなど、手軽に使用できるワークフロー テンプレートが用意されています。
3. ワークフローをカスタマイズする
   当社が提供するワークフロー テンプレートから開始して、プロジェクトの厳密な要件に合わせてカスタマイズできます。
4. ワークフローを選択したら、コミットを開始するためのボタンを押す
   ワークフロー設定はリポジトリ内に存在しているため、ビルド定義は完成したコードと一緒にバージョン管理されます。

GitHub Actions ガイド: https://help.github.com/en/actions
GitHub Actions に関する質疑応答: github.community

知っておくべき役立つ用語

アクション
再利用可能なコンポーネントとしてワークフロー内で使用されるプログラム。アクションでは、環境へのソフトウェアのインストール、認証の設定、複雑なタスクセットの自動化を行うことができます。アクションは GitHub Marketplace で見つけることができます。または、独自のアクションを作成してコミュニティと共有することもできます。

ワークフロー
プロジェクトをビルド、テスト、パッケージ化、リリース、または導入するためにリポジトリ内で使用できる、設定可能な自動化されたプロセス。ワークフローは 1 つ以上の "ジョブ" で構成されており、GitHub イベントによってトリガーできます。

継続的インテグレーション (CI)
小さなコード変更を共有リポジトリに頻繁にコミットするソフトウェア開発プラクティス。GitHub Actions では、コードを自動的にビルドおよびテストするカスタム CI ワークフローを作成できます。リポジトリから、コード変更のステータス、ワークフロー内の各アクションの詳細なログを確認できます。CI はバグを迅速に検出および解決できるように、コード変更に関するフィードバックを即時に提供することで、開発者の時間を節約します。

YAML
YAML は "Yet Another Markup Language" を表しています。構成ファイルに一般的に使用される、人間が解読可能なマークアップ言語です (特に CI および DevOps を重視したソフトウェアツールによって)。GitHub Actions では、YAML を構成ワークフローの基本として使用します。

ワークフロー ファイル
GitHub Actions のワークフローを定義する構成ファイル。YAML で記述され、.github/workflows ディレクトリの GitHub リポジトリ内に存在します。そのディレクトリ内にある、拡張子 .yaml が付いた名前を持つ各ファイルは、固有のワークフローを定義します。

ワークフロー ファイルの例

name: CI for Node.js Project
on:
 push:
 branches: [ master ]
 pull_request:
 branches: [ master ]
jobs:
 build:
 runs-on: ubuntu-latest
 name: Build and Test
 steps:
 - uses: actions/checkout@v2
 name: Check out repository
 - uses: actions/setup-node@v1
 name: Set up Node.js
 with:
 node-version: 12
 - run: |
 npm ci
 npm run build
 npm test
 name: Build and Test

このワークフロー例の説明:

name
ワークフローの名前がリポジトリのアクションページに表示されます。

on
GitHub 上で発生し、ワークフローを実行させるイベント。たとえば、プッシュ リクエストやプル_リクエストのトリガーでワークフローを実行することで、継続的インテグレーションのワークフローでコードをビルドし、テストを実行できます。これらのトリガーには、特定のファイルが変更されたときや、特定のブランチがプッシュされたときに実行するといった制約を追加できます。

jobs
ワークフローの一部として実行されるジョブのリスト。各ジョブはその他のジョブから独立して実行され、さまざまな仮想環境で実行されます。ジョブには UI またはログ内で簡単に識別できる 名前を付けることができます。ジョブには実行される一連のステップが順番に含まれています。このワークフローには 1 つのジョブ (build ジョブ) が含まれています。

jobs.<job-id>.runs-on
特定のジョブを実行するために使用するランナーのタイプ。GitHub が提供するランナーまたはユーザーが構成するセルフホステッド ランナーのいずれかです。GitHub は Linux (ubuntu-latest)、Windows (windows-latest)、macOS (macos-latest) の 3 つの主要タイプのランナーを提供しています。

jobs.<job-id>.steps
ジョブの一部として実行されるステップのリスト。各ステップは全て同じ仮想環境で次々に実行されます。既定では、いずれかのステップが失敗すると、ジョブ全体が停止します。このワークフローでは、build ジョブに次の 3 つのステップが含まれています。

1. 最初のステップでは actions/checkout@v2 という名前のアクションを使用します。これは GitHub によって提供されるアクションであり、ビルドおよびテストできるようにリポジトリをランナーにチェックアウトします。
2. 2 番目のステップでは actions/setup-node@v1 という名前のアクションを使用します。これは GitHub によって提供されるアクションであり、ランナー上で特定バージョンの Node.js をセットアップします。with セクションのアクションに引数を提供できます。この例では、node-version 引数が 12 に設定されています。これは、後続のステップの PATH に Node.js バージョン 12 を指定するようにアクションに指示しています。
3. 最後のステップでは、コマンドラインでプログラムを実行します。既定では、これらのプログラムは bash (Linux および macOS 上) または PowerShell (Windows 上) を使用して実行されます。単一のコマンドを指定できます。または、先頭にパイプ (|) 記号を付けてコマンドを開始することで、複数のコマンドを指定することもできます。
   
   このケースでは、npm ci を実行して npm リポジトリからパッケージをダウンロードおよびインストールし、次に npm run build を実行してプロジェクトで指定されたビルドスクリプトを実行し、最後に npm test を実行してプロジェクト内で任意のユニットテストを実行することで、継続的インテグレーション Node.js のビルドが実行されます。