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

このガイドでは、シークレット管理、依存ジョブ、キャッシング、ビルドマトリックス、環境、ラベルなど、GitHub Actions のより高度な機能を使用する方法を説明します。

概要

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 条件ステートメントを使用してこれを定義できます。

この例では、setupbuild、および test ジョブが連続して実行され、buildtest は、それらに先行するジョブが正常に完了したかどうかに依存します。

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 を参照してください。

依存関係のキャッシング

GitHub ホストランナーは各ジョブの新しい環境として開始されるため、ジョブが依存関係を定期的に再利用する場合は、これらのファイルをキャッシュしてパフォーマンスを向上させることを検討できます。 キャッシュが作成されると、同じリポジトリ内のすべてのワークフローで使用できるようになります。

この例は、~/.npm ディレクトリをキャッシュする方法を示しています。

jobs:
  example-job:
    steps:
      - name: Cache node modules
        uses: actions/cache@v2
        env:
          cache-name: cache-node-modules
        with:
          path: ~/.npm
          key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-build-${{ env.cache-name }}-

詳しい情報については、「ワークフローを高速化するための依存関係のキャッシュ」を参照してください。

データベースとサービスコンテナの利用

ジョブにデータベースまたはキャッシュサービスが必要な場合は、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".

Reusing workflows

You can call one workflow from within another workflow. This allows you to reuse workflows, avoiding duplication and making your workflows easier to maintain. For more information, see "Reusing workflows."

環境の使用

保護ルールとシークレットを持つ環境を設定できます。 ワークフロー内の各ジョブは、1つの環境を参照できます。 この環境を参照するとジョブがランナーに送信される前に、環境に設定された保護ルールをパスしなければなりません。 For more information, see "Using environments for deployment."

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

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

actions/starter-workflows リポジトリ。

  1. GitHubで、リポジトリのメインページにアクセスしてください。
  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."

このドキュメントは役立ちましたか?

プライバシーポリシー

これらのドキュメントを素晴らしいものにするのを手伝ってください!

GitHubのすべてのドキュメントはオープンソースです。間違っていたり、はっきりしないところがありましたか?Pull Requestをお送りください。

コントリビューションを行う

OR, コントリビューションの方法を学んでください。

問題がまだ解決していませんか?