ノート: GitHub Actionsは現在GitHub AEでベータです。
概要
この記事では、より複雑なワークフローの作成に役立つ GitHub Actions の高度な機能の一部について説明します。
シークレットを保存する
ワークフローでパスワードや証明書などの機密データを使用する場合は、これらを GitHub に secrets として保存すると、ワークフローで環境変数として使用できます。 これは、YAML ワークフローに直接機密値を埋め込むことなく、ワークフローを作成して共有できることを示しています。
この例では、既存のシークレットを環境変数として参照し、それをパラメータとしてサンプルコマンドに送信する方法を示しています。
jobs:
example-job:
runs-on: ubuntu-latest
steps:
- name: Retrieve secret
env:
super_secret: ${{ secrets.SUPERSECRET }}
run: |
example-command "$super_secret"
詳しい情報については「暗号化されたシークレットの作成と保存」を参照してください。
依存ジョブを作成する
デフォルトでは、ワークフロー内のジョブはすべて同時並行で実行されます。 したがって、別のジョブが完了した後にのみ実行する必要があるジョブがある場合は、needs キーワードを使用してこの依存関係を作成できます。 ジョブのうちの 1 つが失敗すると、依存するすべてのジョブがスキップされます。ただし、ジョブを続行する必要がある場合は、if 条件ステートメントを使用してこれを定義できます。
この例では、setup、build、および test ジョブが連続して実行され、build と test は、それらに先行するジョブが正常に完了したかどうかに依存します。
jobs:
setup:
runs-on: ubuntu-latest
steps:
- run: ./setup_server.sh
build:
needs: setup
runs-on: ubuntu-latest
steps:
- run: ./build_server.sh
test:
needs: build
runs-on: ubuntu-latest
steps:
- run: ./test_server.sh
詳しい情報については、jobs.<job_id>.needs を参照してください。
ビルドマトリックスを使用する
ワークフローでオペレーティングシステム、プラットフォーム、および言語の複数の組み合わせにわたってテストを実行する場合は、ビルドマトリックスを使用できます。 ビルドマトリックスは、ビルドオプションを配列として受け取る strategy キーワードを使用して作成されます。 たとえば、このビルドマトリックスは、異なるバージョンの Node.js を使用して、ジョブを複数回実行します。
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node: [6, 8, 10]
steps:
- uses: actions/setup-node@v1
with:
node-version: ${{ matrix.node }}
詳しい情報については、jobs.<job_id>.strategy.matrix を参照してください。
データベースとサービスコンテナの利用
ジョブにデータベースまたはキャッシュサービスが必要な場合は、services キーワードを使用して、サービスをホストするための一時コンテナを作成できます。 この例は、ジョブが services を使用して postgres コンテナを作成し、node を使用してサービスに接続する方法を示しています。
jobs:
container-job:
runs-on: ubuntu-latest
container: node:10.18-jessie
services:
postgres:
image: postgres
steps:
- name: Check out repository code
uses: actions/checkout@v2
- name: Install dependencies
run: npm ci
- name: Connect to PostgreSQL
run: node client.js
env:
POSTGRES_HOST: postgres
POSTGRES_PORT: 5432
詳しい情報については、「データベースおよびサービスコンテナを使用する」を参照してください。
ラベルを使用してワークフローを転送する
この機能では、特定のホストランナーにジョブを割り当てることができます。 特定のタイプのランナーがジョブを処理することを確認したい場合は、ラベルを使用してジョブの実行場所を制御できます。 ホストランナーにラベルを割り当ててから、YAML ワークフローでこれらのラベルを参照して、ジョブが予測可能な方法で転送されるようにすることができます。
この例は、ワークフローがラベルを使用して必要なランナーを指定する方法を示しています。
jobs:
example-job:
runs-on: [AE-runner-for-CI]
詳しい情報については、「AEホストランナー でのラベルの利用」を参照してください。
ワークフロー テンプレートの使用
GitHubは、カスタマイズして独自の継続的インテグレーションワークフローを作成できる、事前設定されたワークフローテンプレートを提供します。 GitHub AEはコードを分析し、そのリポジトリで役に立つであろうCIテンプレートを提示します。 たとえばリポジトリにNode.jsのコードが含まれているなら、Node.jsプロジェクトのためのサジェッションが提示されます。 ワークフローテンプレートは、カスタムワークフローの構築の出発点として利用することも、そのまま利用することもできます。
Enterprise の actions/starter-workflows リポジトリで、ワークフローテンプレートの完全なリストを閲覧できます。
- GitHub AEで、リポジトリのメインページにアクセスしてください。
- リポジトリ名の下でActions（アクション）をクリックしてください。
- リポジトリに既存のワークフローが既に存在する場合: 左上隅にある [New workflow（新しいワークフロー）] をクリックします。
- 使いたいテンプレート名の下で、Set up this workflow（このワークフローをセットアップする）をクリックしてください。
次のステップ
GitHub Actions について詳しくは、「Organization とワークフローを共有する」を参照してください。