ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

GitHub Actionsのワークフロー構文

リポジトリにワークフローファイルを追加すると、ソフトウェア開発のライフサイクルを自動化するカスタムの自動プロセスを作成することができます。

GitHub Actions is currently in limited public beta and is subject to change. We strongly recommend that you do not use this feature for high-value workflows and content during the beta period. For more information about the beta, see "About GitHub Actions."

For more information about using GitHub Actions, see "Automating your workflow with GitHub Actions."

ここには以下の内容があります:

ワークフロー用のYAML構文について

ワークフローファイルはYAML構文を使用し、ファイル拡張子が.ymlまたは.yamlである必要があります。 YAMLについて詳しくなく、学んでいきたい場合は、「Learn YAML in five minutes (5分で学ぶYAML)」をお読みください。

ワークフローファイルは、リポジトリの.github/workflowsディレクトリに保存する必要があります。

使用制限

利用制限を超えると、ジョブのキューイング、実行の失敗、完了の失敗といったことが起こるかもしれません。制限は変更されることがあります。

name

ワークフローの名前。 GitHubでは、リポジトリのアクションページにワークフローの名前が表示されます。 このフィールドを省略した場合、GitHubはnameをワークフローのファイル名に設定します。

on

必須 ワークフローをトリガーするGitHubイベントの名前。 指定できるのは、1つのイベントstring、複数イベントのarray、イベントtypesarrayです。あるいは、ワークフローをスケジュールする、またはワークフロー実行を特定のファイルやタグ、ブランチ変更に限定するイベント設定mapも指定できます。 使用可能なイベントの一覧は、「ワークフローをトリガーするイベント」を参照してください。

1つのイベントを使用する例

# プッシュでトリガー
on: push

イベントのリストを使用する例

# プッシュあるいはプルリクエストでワークフローをトリガー
on: [push, pull_request]

on.<event_name>.types

ワークフローの実行をトリガーする特定のアクティビティ。 ほとんどの GitHub イベントは、2 つ以上のアクティビティタイプからトリガーされます。 たとえば、releaseリソースに対するイベントは、release が publishedunpublishedcreatedediteddeleted、または prereleased の場合にトリガーされます。 typesキーワードを使用すると、ワークフローを実行させるアクティブの範囲を狭くすることができます。 webhook イベントをトリガーするアクティビティタイプが1つだけの場合、typesキーワードは不要です。

イベントtypesの配列を使用できます。 各イベントとそのアクティビティタイプの詳細については、「ワークフローをトリガーするイベント」を参照してください。

# Trigger the workflow on pull request activity
on:
  release:
    # Only use the types keyword to narrow down the activity types that will trigger your workflow.
    types: [published, created, edited]

on.<push|pull_request>.<branches|tags>

pushおよびpull_requestイベントを使用する場合、特定のブランチまたはタグで実行するワークフローを設定できます。 tagsbranchesのうちの1つのみを定義すると、定義されていないGit refに影響するイベントに対して、ワークフローが実行されません。

branchesbranches-ignoretags、および tags-ignoreのキーワードは、***のワイルドカード文字を使って複数のブランチやタグ名と一致させるglobパターンを受け付けます。 詳しい情報については、「フィルタパターンのチートシート」を参照してください。

ブランチとタグを含める例

branchesおよびtagsで定義されているパターンは、Git refの名前と照らし合わせて評価されます。 たとえば、branchesmona/octocatとパターンを定義すると、refs/heads/mona/octocatというGit refにマッチします。 releases/**というパターンは、refs/heads/releases/10というGit refにマッチします。

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches:    
      - master         # Push events on master branch
      - 'mona/octocat' # Push events to branches matching refs/heads/mona/octocat
      - 'releases/**'  # Push events to branches matching refs/heads/releases/10
    # Sequence of patterns matched against refs/tags
    tags:        
      - v1             # Push events to v1 tag
      - v1.*           # Push events to v1.0, v1.1, and v1.9 tags

ブランチとタグを無視する例

パターンがbranches-ignoreまたはtags-ignoreとマッチする場合は常に、ワークフローは実行されません。 branches-ignoreおよびtags-ignoreで定義されているパターンは、Git refの名前と照らし合わせて評価されます。 たとえば、branchesmona/octocatとパターンを定義すると、refs/heads/mona/octocatというGit refにマッチします。 branchesのパターンreleases/**-alphaは、refs/releases/beta/3-alphaというGit refにマッチします。

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches-ignore:
      - 'mona/octocat'      # Push events to branches matching refs/heads/mona/octocat
      - 'releases/**-alpha' # Push events to branches matching refs/heads/releases/beta/3-alpha
    # Sequence of patterns matched against refs/tags
    tags-ignore:
      - v1.*           # Push events to tags v1.0, v1.1, and v1.9

ブランチとタグを除外する

タグやブランチへのプッシュおよびプルリクエストでワークフローが実行されることを防ぐために、2 種類のフィルタを使うことができます。

肯定と否定のパターンを使用する例

"!" の文字を使うことで、tagsbranches を除外できます。 パターンを定義する順序により、結果に違いが生じます。

以下のワークフローは、releases/10releases/beta/mona へのプッシュで実行されますが、releases/10-alphareleases/beta/3-alpha へのプッシュでは実行されません。肯定のマッチングパターンの後に、否定のマッチングパターン !releases/**-alpha が続いているからです。

on:
  push:
    branches:    
    - 'releases/**'
    - '!releases/**-alpha'

on.<push|pull_request>.paths

push および pull_request イベントを使用する場合、1 つ以上の変更されたファイルが paths-ignore にマッチしない場合や、1 つ以上の変更されたファイルが、設定された paths にマッチする場合にワークフローを実行するように設定できます。 タグへのプッシュに対して、パスのフィルタは評価されません。

paths-ignore および paths キーワードは、*** のワイルドカード文字を使って複数のパス名と一致させる glob パターンを受け付けます。 詳しい情報については、「フィルタパターンのチートシート」を参照してください。

バスを無視する例

パス名が paths-ignore のパターンとマッチする場合は常に、ワークフローは実行されません。 GitHub は、paths-ignore に定義されているパターンを、パス名に対して評価します。 A workflow with the following path filter will only run on push events that include at least one file outside the docs directory at the root of the repository.

on:
  push:
    paths-ignore:
    - 'docs/**'

Example including paths

If at least one path matches a pattern in the paths filter, the workflow runs. To trigger a build anytime you push a JavaScript file, you can use a wildcard pattern.

on:
  push:
    paths:
    - '**.js'

Excluding paths

You can exclude paths using two types of filters. You cannot use both of these filters for the same event in a workflow.

肯定と否定のパターンを使用する例

You can exclude paths using the ! character. パターンを定義する順序により、結果に違いが生じます:

This example runs anytime the push event includes a file in the sub-project directory or its subdirectories, unless the file is in the sub-project/docs directory. For example, a push that changed sub-project/index.js or sub-project/src/index.js will trigger a workflow run, but a push changing only sub-project/docs/readme.md will not.

on:
  push:
    paths:
    - 'sub-project/**'
    - '!sub-project/docs/**'

Git diff comparisons

Note: If you push more than 1,000 commits, or if GitHub does not generate the diff due to a timeout (diffs that are too large diffs), the workflow will always run.

The filter determines if a workflow should run by evaluating the changed files and running them against the paths-ignore or paths list. If there are no files changed, the workflow will not run.

GitHub generates the list of changed files using two-dot diffs for pushes and three-dot diffs for pull requests:

For more information, see "About comparing branches in pull requests."

on.schedule

この例ではワークフローを15分ごとにトリガします:

on:
schedule:
- cron:  */15 * * * *

クーロン構文に関する詳しい情報については、「ワークフローをトリガーするイベント」を参照してください。

env

A map of environment variables that are available to all jobs and steps in the workflow. You can also set environment variables that are only available to a job or step. For more information, see jobs.<job_id>.env and jobs.<job_id>.steps.env.

When more than one environment variable is defined with the same name, GitHub uses the most specific environment variable. For example, an environment variable defined in a step will override job and workflow variables with the same name, while the step executes. A variable defined for a job will override a workflow variable with the same name, while the job executes.

jobs

1つのワークフロー実行は、1つ以上のジョブからなります。 デフォルトでは、ジョブは並行して実行されます。 ジョブを逐次的に実行するには、jobs.<job_id>.needsキーワードを使用して他のジョブに対する依存関係を定義します。

各ジョブは、runs-onで指定した仮想環境の新しいインスタンスで実行されます。

ワークフローの利用制限以内であれば、実行できるジョブ数には制限がありません。詳しい情報については「利用制限」を参照してください。

jobs.<job_id>

各ジョブには、対応するIDがあります。 job_idキーは文字列型で、その値はジョブの設定データのマップとなるものです。 <job_id>は、jobsオブジェクトごとに一意の文字列に置き換える必要があります。 <job_id>は、英字または_で始める必要があり、英数字と-_しか使用できません。

サンプル

jobs:
  my_first_job:
    name: My first job
  my_second_job:
    name: My second job

jobs.<job_id>.name

GitHubに表示されるジョブの名前。

jobs.<job_id>.needs

このジョブの実行前に正常に完了する必要があるジョブを示します。 文字列型または文字列の配列です。 1つのジョブが失敗した場合、失敗したジョブを続行するような条件文を使用していない限り、そのジョブを必要としている他のジョブはすべてスキップされます。

サンプル

jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]

この例では、job1が正常に完了してからjob2が始まり、job3job1job2が完了するまで待機します。

つまり、この例のジョブは逐次実行されるということです。

  1. job1
  2. job2
  3. job3

jobs.<job_id>.runs-on

必須 ジョブを実行する仮想マシンの種類。 Each job runs with a fresh instance of the virtual environment specified by runs-on.

使用可能な仮想マシンの種類は、次のとおりです。

詳細については、GitHub Actionsの仮想環境を参照してください。

サンプル

runs-on: ubuntu-18.04

jobs.<job_id>.env

A map of environment variables that are available to all steps in the job. You can also set environment variables for the entire workflow or an individual step. For more information, see env and jobs.<job_id>.steps.env.

When more than one environment variable is defined with the same name, GitHub uses the most specific environment variable. For example, an environment variable defined in a step will override job and workflow variables with the same name, while the step executes. A variable defined for a job will override a workflow variable with the same name, while the job executes.

サンプル

jobs:
  job1:
    env:
      FIRST_NAME: Mona

jobs.<job_id>.if

You can use the if conditional to prevent a job from running unless a condition is met. 条件文を作成するには、サポートされている任意のコンテキストや式が使えます。

条件文のif内の式には、${{ }}構文は不要です。 詳しい情報については、「GitHub Actions のコンテキストと式構文」を参照してください。

jobs.<job_id>.steps

1つのジョブには、steps (ステップ) と呼ばれる一連のタスクがあります。 ステップでは、コマンドを実行する、設定タスクを実行する、あるいはリポジトリやパブリックリポジトリ、Dockerレジストリで公開されたアクションを実行することができます。 すべてのステップでアクションを実行するとは限りませんが、すべてのアクションはステップとして実行されます。 各ステップは、仮想環境のそれ自体のプロセスで実行され、ワークスペースとファイルシステムにアクセスします。 ステップはそれ自体のプロセスで実行されるため、環境変数を変更しても、ステップ間では反映されません。 GitHubには、ジョブを設定して完了するステップが組み込まれています。

ワークフローの利用限度内であれば、実行するステップ数に限度はありません。 詳細については「利用限度」を参照してください。

サンプル

name: Greeting from Mona

on: push

jobs:
  my-job:
    name: My Job
    runs-on: ubuntu-latest
    steps:
    - name: Print a greeting
      env:
        MY_VAR: Hi there! My name is
        FIRST_NAME: Mona
        MIDDLE_NAME: The
        LAST_NAME: Octocat
      run: |
        echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.

jobs.<job_id>.steps.id

ステップの一意の識別子。 idを使って、コンテキストのステップを参照することができます。 詳しい情報については、「GitHub Actions のコンテキストと式構文」を参照してください。

jobs.<job_id>.steps.if

条件文のifを使って、条件が満たされなければステップを実行しないようにできます。 条件文を作成するには、サポートされている任意のコンテキストや式が使えます。

条件文のif内の式には、${{ }}構文は不要です。 詳しい情報については、「GitHub Actions のコンテキストと式構文」を参照してください。

コンテキストの使用例

このステップは、イベントの種類がpull_requestでイベントアクションがunassignedの場合にのみ実行されます。

steps:
 - name: My first step
   if: github.event_name == 'pull_request' && github.event.action == 'unassigned'
   run: echo This event is a pull request that had an assignee removed.
ステータスチェック関数の使用例

my backup stepは、ジョブの前のステップが失敗した場合にのみ実行されます。 詳しい情報については「ステータスチェック関数」を参照してください。

steps:
  - name: My first step
    # Use an action (`my-action`) in your repository
    uses: ./.github/actions/my-action
  - name: My backup step
    if: failure()
    uses: actions/heroku@master

jobs.<job_id>.steps.name

GitHubで表示されるステップの名前。

jobs.<job_id>.steps.uses

ジョブでステップの一部として実行されるアクションを選択します。 アクションとは、再利用可能なコードの単位です。 ワークフロー、パブリックリポジトリ、または公開されているDockerコンテナイメージと同じリポジトリで定義されているアクションを使用できます。

Git ref、SHA、またはDockerタグ番号を指定して、使用しているアクションのバージョンを含めることを強く推奨します。 バージョンを指定しないと、アクションのオーナーがアップデートを公開したときに、ワークフローが中断したり、予期せぬ動作をしたりすることがあります。

入力が必要なアクションもあり、入力をwithキーワードを使って設定する必要があります。 必要な入力を判断するには、アクションのREADMEファイルをお読みください。

アクションは、JavaScriptのファイルもしくはDockerコンテナです。 使用するアクションがDockerコンテナの場合は、Linux仮想環境で実行する必要があります。 詳細については、runs-onと「GitHub Actionsの仮想環境」を参照してください。

バージョンされたアクションを使用する例
steps:    
  - uses: actions/setup-node@74bc508 # Reference a specific commit
  - uses: actions/setup-node@v1      # Reference the major version of a release   
  - uses: actions/setup-node@v1.2    # Reference a minor version of a release  
  - uses: actions/setup-node@master  # Reference a branch
パブリックアクションを使用する例

{owner}/{repo}@{ref}

パブリックGitHubリポジトリのブランチ、ref、SHAを指定できます。

jobs:
  my_first_job:
    steps:
      - name: My first step
      # Uses the master branch of a public repository
        uses: actions/heroku@master
      # use a specific version tag of a public repository
      - name: My second step
        uses: actions/aws@v2.0.1
サブディレクトリのパブリックアクションを使用する例

{owner}/{repo}/{path}@{ref}

パブリックGitHubリポジトリで特定のブランチ、ref、SHAにあるサブディレクトリ。

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: actions/aws/ec2@master
ワークフローと同じリポジトリにあるアクションを使用する例

./path/to/dir

ワークフローのリポジトリにあるアクションを含むディレクトリのパス。

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: ./.github/actions/my-action
Docker Hubアクションを使用する例

docker://{image}:{tag}

Docker Hubで公開されているDockerイメージ。

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: docker://alpine:3.8
Dockerパブリックレジストリアクションを使用する例

docker://{host}/{image}:{tag}

パブリックレジストリのDockerイメージ。

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: docker://gcr.io/cloud-builders/gradle

jobs.<job_id>.steps.run

Runs command-line programs using the operating system's shell. If you do not provide a name, the step name will default to the text specified in the run command.

コマンドは、デフォルトでは非ログインシェルを使用して実行されます。 You can choose a different shell and customize the shell used to run commands. For more information, see "Using a specific shell."

runキーワードは、それぞれが仮想環境での新しいプロセスとシェルです。 When you provide multi-line commands, each line runs in the same shell. 例:

Using the working-directory keyword, you can specify the working directory of where to run the command.

- name: Clean temp directory
  run: rm -rf *
  working-directory: ./temp
特定のシェルを使用する

shellキーワードを使用して、仮想環境のオペレーティングシステムのデフォルトシェルを上書きできます。 組み込みのshellキーワードを使用するか、カスタムセットのシェルオプションを定義することができます。

サポートされているプラットフォーム shell パラメータ 説明 内部で実行されるコマンド
すべて bash 非Windowsプラットフォームのデフォルトシェルで、shへのフォールバックがあります。 Windowsでbashシェルを指定すると、Windows用Gitに含まれるbashシェルが使用されます。 bash --noprofile --norc -eo pipefail {0}
すべて pwsh PowerShell Coreです。 GitHubはスクリプト名に拡張子.ps1を追加します。 pwsh -command "& '{0}'"
すべて python Pythonのコマンドを実行します。 python {0}
Linux / macOS sh 非Windowsプラットフォームにおいてシェルが提供されておらず、パス上でbashが見つからなかった場合のフォールバック動作です。 sh -e {0}
Windows cmd これはWindowsで使われるデフォルトのシェルです。 GitHubはスクリプト名に拡張子.cmdを追加し、{0}を置き換えます。 %ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}"".
Windows powershell デスクトップPowerShellです。 GitHubはスクリプト名に拡張子.ps1を追加します。 powershell -command "& '{0}'".
bashを使用してスクリプトを実行する例
steps:
  - name: Display the path
    run: echo $PATH
    shell: bash
Example running a script using Windows cmd
steps:
  - name: Display the path
    run: echo %PATH%
    shell: cmd
Example running a script using PowerShell Core
steps:
  - name: Display the path
    run: echo ${env:PATH}
    shell: pwsh
Example running a python script
steps:
  - name: Display the path
    run: |
      import os
      print(os.environ['PATH'])
    shell: python
カスタムシェル

command […options] {0} [..more_options]を使用すると、テンプレート文字列にshell値を設定できます。 GitHubは、空白区切りで最初の文字列をコマンドとして解釈し、{0}にある一時的なスクリプトのファイル名を挿入します。

終了コードとエラーアクションの環境設定

組み込みのshellキーワードについては、GitHubがホストする実行環境で以下のデフォルトが提供されます。 シェルスクリプトを実行する際には、以下のガイドラインを使ってください。

jobs.<job_id>.steps.with

アクションによって定義される入力パラメータのmap。 各入力パラメータはキー/値ペアです。 入力パラメータは環境変数として設定されます。 変数の前にはINPUT_が付けられ、大文字に変換されます。

サンプル

hello_worldアクションで定義される3つの入力パラメータ (first_namemiddle_namelast_name) を定義します。 hello-worldアクションからは、これらの入力変数はINPUT_FIRST_NAMEINPUT_MIDDLE_NAMEINPUT_LAST_NAMEという環境変数としてアクセスできます。

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: actions/hello_world@master
        with:
          first_name: Mona
          middle_name: The
          last_name: Octocat      

jobs.<job_id>.steps.with.args

Dockerコンテナへの入力を定義する文字列。 GitHubは、コンテナの起動時にargsをコンテナのENTRYPOINTに渡します。 このパラメータは、文字列の配列をサポートしません。

サンプル
steps:
  - name: Explain why this job ran
    uses: monacorp/action-name@master
    with:
      entrypoint: /bin/echo
      args: The ${{ github.event_name }} event triggered this step.

argsは、Dockerfile中のCMD命令の場所で使われます。 Dockerfile中でCMDを使うなら、以下の優先順位順のガイドラインを利用してください。

  1. 必須の引数をアクションのREADME中でドキュメント化し、CMD命令から除外してください。
  2. argsを指定せずにアクションを利用できるよう、デフォルトを使ってください。
  3. アクションが--helpフラグやそれに類するものを備えている場合は、アクションを自己ドキュメント化するためのデフォルトとして利用してください。

jobs.<job_id>.steps.with.entrypoint

Dockerfile中のDockerのENTRYPOINTをオーバーライドします。あるいは、もしそれが指定されていなかった場合に設定します。 shellやexec形式を持つDockerのENTRYPOINT命令とは異なり、entrypointキーワードは実行する実行可能ファイルを定義する単一の文字列だけを受け付けます。

サンプル
steps:
  - name: Run a custom command
    uses: monacorp/action-name@master
    with:
      entrypoint: /a/different/executable

このentrypointキーワードはDockerコンテナのアクションを使おうとしていますが、これは入力を定義しないJavaScriptのアクションにも使えます。

jobs.<job_id>.steps.env

仮想環境でステップが使う環境変数を設定します。 You can also set environment variables for the entire workflow or a job. For more information, see env and jobs.<job_id>.env.

When more than one environment variable is defined with the same name, GitHub uses the most specific environment variable. For example, an environment variable defined in a step will override job and workflow variables with the same name, while the step executes. A variable defined for a job will override a workflow variable with the same name, while the job executes.

パブリックなアクションは、READMEファイル中で期待する環境変数を指定できます。 環境変数に秘密情報を設定しようとしている場合、秘密情報はsecretsコンテキストを使って設定しなければなりません。 詳しい情報については「GitHub Actionsの仮想環境」及び「GitHub Actionsのコンテキストと式構文」を参照してください。

サンプル
steps:
  - name: My first action
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      FIRST_NAME: Mona
      LAST_NAME: Octocat

jobs.<job_id>.steps.continue-on-error

ステップが失敗してもジョブが失敗にならないようにします。 trueに設定すれば、このステップが失敗した場合にジョブが次へ進めるようになります。

jobs.<job_id>.steps.timeout-minutes

プロセスがkillされるまでにステップが実行できる最大の分数。

jobs.<job_id>.timeout-minutes

GitHubで自動的にキャンセルされるまでワークフローを実行する最長時間 (分)。 デフォルト: 360

jobs.<job_id>.strategy

Strategy (戦略) によって、ジョブのビルドマトリクスが作成されます。 各ジョブを実行する環境のバリエーションを定義できます。

jobs.<job_id>.strategy.matrix

1つのビルドマトリクスが、仮想環境の異なる設定のセットです。 たとえば、サポート対象の複数の言語、オペレーティングシステム、ツールに対してジョブを実行することもできます。 それぞれの設定は、実行されてステータスをレポートするジョブのコピーです。

設定オプションに配列を指定すると、マトリクスを指定できます。 たとえば、GitHubの仮想環境がNode.jsのバージョン6、8、10をサポートしている場合、これらのバージョンの配列をmatrixで指定できます。

オペレーティングシステムのマトリクスを定義する際には、現在のジョブのオペレーティングシステムにはオペレーティングシステム名をハードコーディングするのではなく、必須のruns-onキーワードを設定しなければなりません。オペレーティングシステム名にアクセスするには、コンテキストパラメータのmatrix.osを使ってruns-onを設定できます。詳しい情報については「GitHub Actionsのコンテキストと式構文」を参照してください。

ワークフローの利用制限以内であれば、実行できるジョブ数には制限がありません。詳しい情報については「利用制限」を参照してください。

サンプル

この例は3つのジョブのマトリクスを生成し、それぞれに異なる値を変数のnodeに設定し、この変数をsetup-nodeアクションへの入力として使っています。 その結果、それぞれのジョブは異なるnodeのバージョンを使うことになります。

strategy:
  matrix:
    node: [6, 8, 10]
steps:
  - uses: actions/setup-node@v1
    with:
      node-version: ${{ matrix.node }}

これらのジョブは、matrixの変数をruns-onの指定子への入力として使い、2つの異なるバージョンのLinuxで実行させ、合計で6つのジョブ(3つのnodeのバージョン×2つのLinuxのバージョン)を生成できます。

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [ubuntu-16.04, ubuntu-18.04]
    node: [6, 8, 10]
steps:
  - uses: actions/setup-node@v1
    with:
      node-version: ${{ matrix.node }}

GitHubの仮想環境でサポートされている設定オプションについては、「GitHub Actionsの仮想環境」を参照してください。

マトリクスビルドに設定を含める例

既存のビルドマトリクスジョブに、設定オプションを追加できます。 include を使ってビルドマトリクスに新しいジョブを追加することはできません。 たとえば、windows-2016 を使い、node のバージョン 4 を実行しているときに、npm の特定のバージョンを使いたい場合は、include を使って追加のオプションを指定できます。

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [macOS-10.14, windows-2016, ubuntu-18.04]
    node: [4, 6, 8, 10]
    include:
      # includes a new variable of npm with a value of 2 for the matrix leg matching the os and version
      - os: windows-2016
        node: 4
        npm: 2
マトリクスから設定を除外する例

exclude オプションを使って、ビルドマトリクスに定義されている特定の設定を削除できます。 exclude を使うと、ビルドマトリクスにより定義されたジョブが削除されます。 ジョブの数は、指定する配列に含まれるオペレーティングシステム (os) の外積から、任意の減算 (exclude) で引いたものです。

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [macOS-10.14, windows-2016, ubuntu-18.04]
    node: [4, 6, 8, 10]
    exclude:
      # excludes node 4 on macOS
      - os: macos-10.14
        node: 4

jobs.<job_id>.strategy.fail-fast

trueに設定すると、いずれかのmatrixジョブが失敗した場合にGitHubは進行中のジョブをすべてキャンセルします。 デフォルト: true

jobs.<job_id>.strategy.max-parallel

matrixジョブ戦略を使用するとき、同時に実行できるジョブの最大数。 デフォルトでは、GitHubはGitHubがホストしている仮想マシン上で利用できるrunnerに応じてできるかぎりの数のジョブを並列に実行します。

strategy:
  max-parallel: 2

jobs.<job_id>.container

ジョブの中で、まだコンテナを指定していない手順を実行するコンテナ。 スクリプトアクションとコンテナアクションの両方を使うステップがある場合、コンテナアクションは同じボリュームマウントを使用して、同じネットワーク上にある兄弟コンテナとして実行されます。

containerを設定しない場合は、コンテナで実行されるよう設定されているアクションを参照しているステップを除くすべてのステップが、runs-onで指定したホストで直接実行されます。

サンプル

jobs:
  my_job:
    container:
      image: node:10.16-jessie
      env:
        NODE_ENV: development
      ports:
        - 80
      volumes:
        - my_docker_volume:/volume_mount
      options: --cpus 1

コンテナイメージのみを指定する場合、imageは省略できます。

jobs:
  my_job:
    container: node:10.16-jessie

jobs.<job_id>.container.image

アクションを実行するコンテナとして使用するDockerイメージ。 値はDocker Hubイメージ名か、パブリックDockerレジストリ名です。

jobs.<job_id>.container.env

コンテナで環境変数のarrayを設定します。

jobs.<job_id>.container.ports

コンテナで公開するポートのarrayを設定します。

jobs.<job_id>.container.volumes

使用するコンテナにボリュームのarrayを設定します。 volumes (ボリューム) を使用すると、サービス間で、または1つのジョブのステップ間でデータを共有できます。 指定できるのは、名前付きDockerボリューム、匿名Dockerボリューム、またはホスト上のバインドマウントです。

ボリュームを指定するには、ソースパスとターゲットパスを指定してください。

<source>:<destinationPath>.

<source>は、ホストマシン上のボリューム名または絶対パス、<destinationPath>はコンテナでの絶対パスです。

サンプル
volumes:
  - my_docker_volume:/volume_mount
  - /data/my_data
  - /source/directory:/destination/directory

jobs.<job_id>.container.options

追加のDockerコンテナリソースのオプション。 オプションの一覧は、「docker createのオプション」を参照してください。

jobs.<job_id>.services

ワークフローでジョブのサービスをホストする追加のコンテナ。 データベースや、Redisなどのキャッシュサービスを作成するときに便利です。 The runner on the virtual machine will automatically create a network and manage the life cycle of the service containers.

ジョブにサービスコンテナを使用している場合、またはステップでコンテナアクションを使用する場合、サービスにアクセスする際にポート情報は必要ありません。 Dockerが同じネットワーク上のコンテナ間ですべてのポートを自動的に公開します。

ジョブとアクションのどちらもコンテナで実行される場合は、ホスト名でコンテナを直接参照できます。 ホスト名は自動的にサービス名にマップされます。

ステップでコンテナアクションを使用しない場合、localhostを使用してサービスにアクセスして、ポートをバインドする必要があります。

localhostを使用する例

次の例では、NginxとRedisに2つのサービスを作成します。 GitHubが仮想ホスト上で空きポートを選択し、Redisのデフォルトポートをバインドします。 GitHubはバインドされたホストポートを${{ job.services.<service_name>.ports[<port>] }}ジョブコンテキストで設定します。 For example, the redis port will be set in the ${{ job.services.redis.ports['6379'] }} environment variable.

services:
  nginx:
    image: nginx
    ports:
      - 8080:80
    env:
      NGINX_PORT: 80
  redis:
    image: redis
    ports:
      - 6379/tcp

jobs.<job_id>.services.image

アクションを実行するサービスコンテナとして使用するDockerイメージ。 値はDockerベースイメージ名か、パブリックDocker Hubまたはレジストリです。

jobs.<job_id>.services.env

サービスコンテナで環境変数のarrayを設定します。

jobs.<job_id>.services.ports

サービスコンテナで公開するポートのarrayを設定します。

jobs.<job_id>.services.volumes

使用するサービスコンテナにボリュームのarrayを設定します。 volumes (ボリューム) を使用すると、サービス間で、または1つのジョブのステップ間でデータを共有できます。 指定できるのは、名前付きDockerボリューム、匿名Dockerボリューム、またはホスト上のバインドマウントです。

ボリュームを指定するには、ソースパスとターゲットパスを指定してください。

<source>:<destinationPath>.

<source>は、ホストマシン上のボリューム名または絶対パス、<destinationPath>はコンテナでの絶対パスです。

サンプル
volumes:
  - my_docker_volume:/volume_mount
  - /data/my_data
  - /source/directory:/destination/directory

jobs.<job_id>.services.options

追加のDockerコンテナリソースのオプション。 オプションの一覧は、「docker createのオプション」を参照してください。

フィルタパターンのチートシート

You can use special characters in path, branch, and tag filters.

The characters *, [, and ! are special characters in YAML. If you start a pattern with *, [, or !, you must enclose the pattern in quotes.

- '**/README.md' # valid
- **/README.md   # INVALID - creates a parse error that prevents your workflow from running

For more information about branch, tag, and path filter syntax, see "on.<push|pull_request>.<branches|tags>" and "on.<push|pull_request>.paths."

Patterns to match branches and tags

Pattern 説明 Example matches
機能/* The * wildcard matches any character, but does not match slash (/). -feature/my-branch
-feature/your-branch
機能/** The ** wildcard matches any character including slash (/) in branch and tag names. -feature/beta-a/my-branch
-feature/your-branch
-feature/mona/the/octocat
-master
-releases/mona-the-octcat
Matches the exact name of a branch or tag name. -master
-releases/mona-the-octocat
'*' Matches all branch and tag names that don't contain a slash (/). The * character is a special character in YAML. When you start a pattern with *, you must use quotes. -master
-releases
'**' Matches all branch and tag names. This is the default behavior when you don't use a branches or tags filter. -all/the/branches
-every/tag
'*機能' The * character is a special character in YAML. When you start a pattern with *, you must use quotes. -mona-feature
-feature
-ver-10-feature
v2* Matches branch and tag names that start with v2. -v2
-v2.0
-v2.9
v[12].[0-9]+.[0-9]+ Matches all semantic versioning tags with major version 1 or 2 -v1.10.1
-v2.0.0

Patterns to match file paths

Path patterns must match the whole path, and start from the repository's root.

Pattern Description of matches Example matches
'*' The * wildcard matches any character, but does not match slash (/). The * character is a special character in YAML. When you start a pattern with *, you must use quotes. -README.md
-server.rb
'*.jsx?' The ? character matches zero or one of the preceding character. -page.js
-page.jsx
'**' The ** wildcard matches any character including slash (/). This is the default behavior when you don't use a path filter. -all/the/files.md
'*.js' The * wildcard matches any character, but does not match slash (/). Matches all .js files at the root of the repository. -app.js
-index.js
'**.js' Matches all .js files in the repository. -index.js
-js/index.js
-src/js/app.js
ドキュメント/* All files within the root of the docs directory, at the root of the repository. -docs/README.md
-docs/file.txt
ドキュメント/** Any files in the /docs directory at the root of the repository. -docs/README.md
-docs/mona/octocat.txt
docs/**/*.md A file with a .md suffix anywhere in the docs directory. -docs/README.md
-docs/mona/hello-world.md
-docs/a/markdown/file.md
'**/ドキュメント/**' Any files in a docs directory anywhere in the repository. -/docs/hello.md
-dir/docs/my-file.txt
-space/docs/plan/space.doc
'**/README.md' A README.md file anywhere in the repository. -README.md
-js/README.md
'**/*src/**' Any file in a folder with a src suffix anywhere in the repository. -a/src/app.js
-my-src/code/js/app.js
'**/*-post.md' A file with the suffix -post.md anywhere in the repository. -my-post.md
-path/their-post.md
'**/migrate-*.sql' A file with the prefix migrate- and suffix .sql anywhere in the repository. -migrate-10909.sql
-db/migrate-v1.0.sql
-db/sept/migrate-v1.sql
-*.md
-!README.md
Using an exclamation mark (!) in front of a pattern negates it. When a file matches a pattern and also matches a negative pattern defined later in the file, the file will not be included. -hello.md
Does not match
-README.md
-docs/hello.md
-*.md
-!README.md
-README*
Patterns are checked sequentially. A pattern that negates a previous pattern will re-include file paths. -hello.md
-README.md
-README.doc

担当者にお尋ねください

探しているものが見つからなかったでしょうか?

弊社にお問い合わせください