複雑なワークフローを管理する

概要

This article describes some of the advanced features of GitHub Actions that help you create more complex workflows.

シークレットを保存する

ワークフローでパスワードや証明書などの機密データを使用する場合は、これらを 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@v2 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 

詳しい情報については、「データベースおよびサービスコンテナを使用する」を参照してください。

ラベルを使用してワークフローを転送する

この機能では、特定のホストランナーにジョブを割り当てることができます。 特定のタイプのランナーがジョブを処理することを確認したい場合は、ラベルを使用してジョブの実行場所を制御できます。 You can assign labels to a self-hosted runner in addition to their default label of self-hosted. Then, you can refer to these labels in your YAML workflow, ensuring that the job is routed in a predictable way. GitHub-hosted runners have predefined labels assigned.

この例は、ワークフローがラベルを使用して必要なランナーを指定する方法を示しています。

jobs: example-job: runs-on: [self-hosted, linux, x64, gpu] 

A workflow will only run on a runner that has all the labels in the runs-on array. The job will preferentially go to an idle self-hosted runner with the specified labels. If none are available and a GitHub-hosted runner with the specified labels exists, the job will go to a GitHub-hosted runner.

To learn more about self-hosted runner labels, see "Using labels with self-hosted runners." To learn more about GitHub-hosted runner labels, see "Supported runners and hardware resources".

ワークフロー テンプレートの使用

GitHubは、カスタマイズして独自の継続的インテグレーションワークフローを作成できる、事前設定されたワークフローテンプレートを提供します。 GitHub Enterprise Serverはコードを分析し、そのリポジトリで役に立つであろうCIテンプレートを提示します。 たとえばリポジトリにNode.jsのコードが含まれているなら、Node.jsプロジェクトのためのサジェッションが提示されます。 ワークフローテンプレートは、カスタムワークフローの構築の出発点として利用することも、そのまま利用することもできます。

GitHub Enterprise Serverのインスタンス の actions/starter-workflows リポジトリで、ワークフローテンプレートの完全なリストを閲覧できます。

1. GitHub Enterprise Serverで、リポジトリのメインページにアクセスしてください。
2. リポジトリ名の下でActions（アクション）をクリックしてください。
3. リポジトリに既存のワークフローが既に存在する場合: 左上隅にある [New workflow（新しいワークフロー）] をクリックします。
4. 使いたいテンプレート名の下で、Set up this workflow（このワークフローをセットアップする）をクリックしてください。

次のステップ

To continue learning about GitHub Actions, see "Sharing workflows, secrets, and runners with your organization."