注: GitHub ホステッド ランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。
コンテキストについて
コンテキストは、ワークフローの実行、ランナーの環境、ジョブ、ステップに関する情� �にアクセスする方法です。 各コンテキストは、プロパティを含むオブジェクトであり、文字列またはその他のオブジェクトにすることができます。
コンテキスト、オブジェクト、プロパティは、ワークフローの実行条件によって大きく異なります。 たとえば、matrix
コンテキストはマトリックス内のジョブに対してのみ設定されます。
式構文を使用してコンテキストにアクセスできます。 詳細については、「式」を参照してく� さい。
${{ <context> }}
警告: ワークフローとアクションを作成するときは、コードが攻撃者からの信� �されていない入力を実行する可能性があるかどうかを常に考慮する必要があります。 攻撃者が悪意あるコンテンツを挿入してくるかもしれないので、特定のコンテキストは信� �できない入力として扱うべきです。 詳細については、「スクリプト インジェクションのリスクについて」を参照してく� さい。
コンテキスト名 | 型 | 説明 |
---|---|---|
github | object | ワークフロー実行に関する情� �。 詳しくは、「github コンテキスト」を参照してく� さい。 |
env | object | ワークフロー、ジョブ、ステップで設定された環境変数が含まれます。 詳しくは、「env コンテキスト」を参照してく� さい。 |
job | object | 現在実行中のジョブに関する情� �。 詳しくは、「job コンテキスト」を参照してく� さい。 |
式の一部として、2 つの構文のいずれかを使用してコンテキスト情� �にアクセスできます。
- インデックス構文:
github['sha']
- プロパティ逆参照構文:
github.sha
プロパティ逆参照構文を使うには、プロパティ名が文字または _
で始まっていて、英数字、-
、または _
のみを含んでいる必要があります。
存在しないプロパティを逆参照しようとすると、空の文字列として評価されます。
コンテキストを使用する� �合の判断
GitHub Actions には、 コンテキスト と呼ばれる変数のコレクションと、 既定の環境変数 と呼ばれる同様の変数のコレクションが含まれます。 これらの変数は、ワークフロー中の様々な� �所で利用されることを意図したものです。
- 既定の環境変数: これらの変数は、ジョブを実行しているランナーにのみ存在します。 詳細については、「既定の環境変数」を参照してく� さい。
- コンテキスト: 既定の環境変数 を使用できない� �合など、ワークフロー内の任意の時点でほとんどのコンテキストを使用できます。 たとえば、式を含むコンテキストを使って、ジョブが実行のためにランナーにルーティングされる前に初期処理を実行できます。これにより、条件付き
if
キーワードを含むコンテキストを使用して、ステップを実行するかどうかを決定できます。 ジョブが実行されると、runner.os
など、ジョブを実行しているランナーからコンテキスト変数を取得することもできます。 ワークフロー内でさまざまなコンテキストを使用できる� �所の詳細については、「コンテキストの可用性」を参照してく� さい。
以下の例は、様々な種類の環境変数をジョブの中で合わせて利用できることを示しています。
name: CI
on: push
jobs:
prod-check:
if: ${{ github.ref == 'refs/heads/main' }}
runs-on: ubuntu-latest
steps:
- run: echo "Deploying to production server on branch $GITHUB_REF"
この例では、if
ステートメントで github.ref
コンテキストをチェックして、現在のブランチ名を判別します。名前が refs/heads/main
の� �合、後続のステップが実行されます。 if
チェックは GitHub Actions によって処理され、結果が true
の� �合にのみジョブがランナーに送信されます。 ジョブがランナーに送信されると、ステップが実行され、ランナーから $GITHUB_REF
環境変数が参照されます。
コンテキストの可用性
ワークフローの実行を通して、さまざまなコンテキストを使用できます。 たとえば、secrets
コンテキストはジョブ内の特定の� �所でのみ使用できます。
また、一部の関数は特定の� �所でのみ使用できます。 たとえば、hashFiles
関数はどこにも使用できません。
次の表は、ワークフロー内で各コンテキストと特殊関数を使用できる� �所を示しています。 以下に一覧表示されている� �合を除き、任意の� �所で関数を使用できます。
パス | Context | 特殊な関数 |
---|---|---|
concurrency | github | |
env | github, secrets | |
jobs.<job_id>.concurrency | github, needs, strategy, matrix | |
jobs.<job_id>.container | github, needs, strategy, matrix | |
jobs.<job_id>.container.credentials | github, needs, strategy, matrix, env, secrets | |
jobs.<job_id>.container.env.<env_id> | github, needs, strategy, matrix, job, runner, env, secrets | |
jobs.<job_id>.continue-on-error | github, needs, strategy, matrix | |
jobs.<job_id>.defaults.run | github, needs, strategy, matrix, env | |
jobs.<job_id>.env | github, needs, strategy, matrix, secrets | |
jobs.<job_id>.environment | github, needs, strategy, matrix | |
jobs.<job_id>.environment.url | github, needs, strategy, matrix, job, runner, env, steps | |
jobs.<job_id>.if | github, needs | always, cancelled, success, failure |
jobs.<job_id>.name | github, needs, strategy, matrix | |
jobs.<job_id>.outputs.<output_id> | github, needs, strategy, matrix, job, runner, env, secrets, steps | |
jobs.<job_id>.runs-on | github, needs, strategy, matrix | |
jobs.<job_id>.services | github, needs, strategy, matrix | |
jobs.<job_id>.services.<service_id>.credentials | github, needs, strategy, matrix, env, secrets | |
jobs.<job_id>.services.<service_id>.env.<env_id> | github, needs, strategy, matrix, job, runner, env, secrets | |
jobs.<job_id>.steps.continue-on-error | github, needs, strategy, matrix, job, runner, env, secrets, steps | hashFiles |
jobs.<job_id>.steps.env | github, needs, strategy, matrix, job, runner, env, secrets, steps | hashFiles |
jobs.<job_id>.steps.if | github, needs, strategy, matrix, job, runner, env, steps | always, cancelled, success, failure, hashFiles |
jobs.<job_id>.steps.name | github, needs, strategy, matrix, job, runner, env, secrets, steps | hashFiles |
jobs.<job_id>.steps.run | github, needs, strategy, matrix, job, runner, env, secrets, steps | hashFiles |
jobs.<job_id>.steps.timeout-minutes | github, needs, strategy, matrix, job, runner, env, secrets, steps | hashFiles |
jobs.<job_id>.steps.with | github, needs, strategy, matrix, job, runner, env, secrets, steps | hashFiles |
jobs.<job_id>.steps.working-directory | github, needs, strategy, matrix, job, runner, env, secrets, steps | hashFiles |
jobs.<job_id>.strategy | github, needs | |
jobs.<job_id>.timeout-minutes | github, needs, strategy, matrix |
例: ログへのコンテキスト情� �の出力
デバッグのためにコンテキストの内容をログに出力できます。 JSON オブジェクトをログに整形出力するには、toJSON
関数が必要です。
警告: github
コンテキスト全体を使う� �合、github.token
などの機密情� �が含まれることに注意してく� さい。 GitHubは、シークレットがコンソールに出力される際にはマスクしますが、コンテキストをエクスポートしたりプリントしたりするときには注意が必要です。
name: Context testing
on: push
jobs:
dump_contexts_to_log:
runs-on: ubuntu-latest
steps:
- name: Dump GitHub context
id: github_context_step
run: echo '${{ toJSON(github) }}'
- name: Dump job context
run: echo '${{ toJSON(job) }}'
- name: Dump steps context
run: echo '${{ toJSON(steps) }}'
- name: Dump runner context
run: echo '${{ toJSON(runner) }}'
- name: Dump strategy context
run: echo '${{ toJSON(strategy) }}'
- name: Dump matrix context
run: echo '${{ toJSON(matrix) }}'
github
コンテキスト
github
コンテキストには、ワークフローの実行とその実行をトリガーしたイベントの情� �が含まれます。 ほとんどの github
コンテキスト データは環境変数で読み取ることができます。 環境変数について詳しくは、環境変数の使用に関するページを参照してく� さい。
警告: github
コンテキスト全体を使う� �合、github.token
などの機密情� �が含まれることに注意してく� さい。 GitHubは、シークレットがコンソールに出力される際にはマスクしますが、コンテキストをエクスポートしたりプリントしたりするときには注意が必要です。
警告: ワークフローとアクションを作成するときは、コードが攻撃者からの信� �されていない入力を実行する可能性があるかどうかを常に考慮する必要があります。 攻撃者が悪意あるコンテンツを挿入してくるかもしれないので、特定のコンテキストは信� �できない入力として扱うべきです。 詳細については、「スクリプト インジェクションのリスクについて」を参照してく� さい。
プロパティ名 | Type | 説明 |
---|---|---|
github | object | ワークフローのあらゆるジョブやステップにおいて使用できる最上位のコンテキスト。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。 |
github.action | string | 現在実行中のアクションの名前、またはステップの id 。 GitHub では特殊文字を削除し、現在のステップで id なしでスクリプトを実行するときに __run という名前を使用します。 同じジョブで同じアクションを複数回使う� �合、名前には、前にアンダースコアが付いたシーケンス番号で構成されるサフィックスが含まれます。 たとえば、実行する最初のスクリプトの名前は __run で、2 番目のスクリプトの名前は __run_2 となります。 同様に、actions/checkout の 2 番目の呼び出しは actionscheckout2 になります。 |
github.action_path | string | アクションが置かれているパス。 このプロパティは、複合アクションでのみサポートされます。 このパスを使用して、アクションと同じリポジトリにあるファイルにアクセスできます。 |
github.action_ref | string | アクションを実行するステップの� �合、これは実行中のアクションの参照です。 たとえば、v2 のようにします。 |
github.action_repository | string | アクションを実行するステップの� �合、これはアクションの所有者とリポジトリの名前です。 たとえば、actions/checkout のようにします。 |
github.action_status | string | 複合アクションの� �合は、複合アクションの現在の結果。 |
github.actor | string | ワークフローの実行を開始したユーザーのユーザー名。 |
github.api_url | string | GitHub REST API の URL。 |
github.base_ref | string | ワークフローの実行における base_ref または pull request のターゲット ブランチ。 このプロパティは、ワークフローの実行をトリガーしたイベントが pull_request または pull_request_target の� �合にのみ使用できます。 |
github.env | string | ワークフロー コマンドから環境変数を設定するファイルへのランナーのパス。 このファイルは現在のステップに固有であり、ジョブ内のステップごとに異なるファイルです。 詳細については、「GitHub Actions のワークフロー コマンド」を参照してく� さい。 |
github.event | object | webhook ペイロードの完全なイベント。 このコンテキストを使用して、イベントの個々のプロパティにアクセスできます。 このオブジェクトは、ワークフロー実行をトリガーしたイベントの Webhook ペイロードと同じであり、イベントごとに異なります。 各 GitHub Actions イベントの Webhook は、「ワークフローをトリガーするイベント」にリンクされています。 たとえば、push イベントによってトリガーされるワークフロー実行の� �合、このオブジェクトにはプッシュ Webhook ペイロードの内容が含まれます。 |
github.event_name | string | ワークフローの実行をトリガーしたイベントの名前。 |
github.event_path | string | 完全なイベント Webhook ペイロードを含むランナー上のファイルへのパス。 |
github.graphql_url | string | GitHub GraphQL API の URL。 |
github.head_ref | string | ワークフローの実行における head_ref または pull request のソース ブランチ。 このプロパティは、ワークフローの実行をトリガーしたイベントが pull_request または pull_request_target の� �合にのみ使用できます。 |
github.job | string | 現在のジョブの job_id 。 注: このコンテキスト プロパティは Actions ランナーによって設定され、ジョブの実行 steps 内でのみ使用できます。 それ以外の� �合、このプロパティの値は null になります。 |
github.ref | string | ワークフローの実行をトリガーしたブランチまたはタグの完全な形式の参照。 push によってトリガーされるワークフローの� �合、これはプッシュされたブランチまたはタグの参照です。 pull_request によってトリガーされるワークフローの� �合、これは pull request のマージ ブランチです。 release によってトリガーされるワークフローの� �合、これは作成されたリリース タグです。 その他のトリガーの� �合、これはワークフロー実行をトリガーしたブランチまたはタグの参照です。 これは、イベントの種類に対してブランチまたはタグを使用できる� �合にのみ設定されます。 指定する参照は完全な形式です。つまり、ブランチの� �合の形式は refs/heads/<branch_name> 、pull request の� �合は refs/pull/<pr_number>/merge 、タグの� �合は refs/tags/<tag_name> です。 たとえば、「 refs/heads/feature-branch-1 」のように入力します。 |
github
コンテキストの内容の例
次のコンテキスト例は、push
イベントによってトリガーされるワークフロー実行のものです。 この例の event
オブジェクトは、push
Webhook ペイロードの内容と同じであるため、切り捨てられています。
注: このコンテキストは、一例です。 コンテキストの内容は、実行中のワークフローによって異なります。 コンテキスト、オブジェクト、プロパティは、ワークフローの実行条件によって大きく異なります。
{
"token": "***",
"job": "dump_contexts_to_log",
"ref": "refs/heads/my_branch",
"sha": "c27d339ee6075c1f744c5d4b200f7901aad2c369",
"repository": "octocat/hello-world",
"repository_owner": "octocat",
"repositoryUrl": "git://github.com/octocat/hello-world.git",
"run_id": "1536140711",
"run_number": "314",
"retention_days": "90",
"run_attempt": "1",
"actor": "octocat",
"workflow": "Context testing",
"head_ref": "",
"base_ref": "",
"event_name": "push",
"event": {
...
},
"server_url": "https://github.com",
"api_url": "https://api.github.com",
"graphql_url": "https://api.github.com/graphql",
"ref_name": "my_branch",
"ref_protected": false,
"ref_type": "branch",
"secret_source": "Actions",
"workspace": "/home/runner/work/hello-world/hello-world",
"action": "github_step",
"event_path": "/home/runner/work/_temp/_github_workflow/event.json",
"action_repository": "",
"action_ref": "",
"path": "/home/runner/work/_temp/_runner_file_commands/add_path_b037e7b5-1c88-48e2-bf78-eaaab5e02602",
"env": "/home/runner/work/_temp/_runner_file_commands/set_env_b037e7b5-1c88-48e2-bf78-eaaab5e02602"
}
github
コンテキストの使用例
このワークフロー例では、ワークフロー実行が github.event_name
イベントによってトリガーされた� �合にのみ、pull_request
コンテキストを使用してジョブを実行します。
name: Run CI
on: [push, pull_request]
jobs:
normal_ci:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Run normal CI
run: ./run-tests
pull_request_ci:
runs-on: ubuntu-latest
if: ${{ github.event_name == 'pull_request' }}
steps:
- uses: actions/checkout@v2
- name: Run PR CI
run: ./run-additional-pr-ci
env
コンテキスト
env
コンテキストには、ワークフロー、ジョブ、またはステップで設定された環境変数が含まれます。 ワークフローでの環境変数の設定について詳しくは、「GitHub Actions のワークフロー構文」を参照してく� さい。
env
コンテキスト構文では、ワークフロー ファイルで環境変数の値を使用できます。 env
コンテキストは、ステップ内の任意のキーの値で使用できます。た� し、id
と uses
キーは除きます。 ステップ構文について詳しくは、「GitHub Actions のワークフロー構文」を参照してく� さい。
ランナー中で環境変数の値を使いたい� �合は、ランナーのオペレーティングシステ� で環境変数を読み取る通常の方法を使ってく� さい。
プロパティ名 | Type | 説明 |
---|---|---|
env | object | このコンテキストは、ジョブのステップごとに異なります。 このコンテキストには、ジョブのあらゆるステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているプロパティが含まれています。 |
env.<env_name> | string | 特定の環境変数の値。 |
env
コンテキストの内容の例
env
コンテキストの内容は、環境変数の名前とその値へのマッピングです。 コンテキストの内容は、ワークフローの実行で使用される� �所に応じて変わる� �合があります。
{
"first_name": "Mona",
"super_duper_var": "totally_awesome"
}
env
コンテキストの使用例
このワークフロー例では、ワークフロー、ジョブ、ステップ レベルで env
コンテキストを構成する方法と、ステップでそのコンテキストを使用する方法を示します。
同じ名前で複数の環境変数が定義されている� �合、GitHubは最も具体的な環境変数を使用します。 たとえば、ステップ中で定義された環境変数は、ジョブやワークフローの同じ名前の変数をステップの実行の間オーバーライドします。 ジョブで定義された変数は、そのジョブの実行の間はワークフローで定義された同じ名前の変数をオーバーライドします。
name: Hi Mascot
on: push
env:
mascot: Mona
super_duper_var: totally_awesome
jobs:
windows_job:
runs-on: windows-latest
steps:
- run: echo 'Hi ${{ env.mascot }}' # Hi Mona
- run: echo 'Hi ${{ env.mascot }}' # Hi Octocat
env:
mascot: Octocat
linux_job:
runs-on: ubuntu-latest
env:
mascot: Tux
steps:
- run: echo 'Hi ${{ env.mascot }}' # Hi Tux
job
コンテキスト
job
コンテキストには、現在実行中のジョブに関する情� �が含まれます。
プロパティ名 | Type | 説明 |
---|---|---|
job | object | このコンテキストは、実行しているジョブごとに異なります。 このコンテキストには、ジョブのあらゆるステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。 |
job.container | object | ジョブのコンテナに関する情� �。 コンテナーについて詳しくは、「GitHub Actions のワークフロー構文」を参照してく� さい。 |
job.container.id | string | コンテナーの ID。 |
job.container.network | string | コンテナー ネットワークの ID。 ランナーは、コンテナ内のすべてのジョブに使用されるネットワークを作成します。 |
job.services | object | ジョブのために作成されたサービスコンテナ。 サービス コンテナーについて詳しくは、「GitHub Actions のワークフロー構文」を参照してく� さい。 |
job.services.<service_id>.id | string | サービス コンテナーの ID。 |
job.services.<service_id>.network | string | サービス コンテナー ネットワークの ID。 ランナーは、コンテナ内のすべてのジョブに使用されるネットワークを作成します。 |
job.services.<service_id>.ports | object | サービスコンテナの公開ポート。 |
job.status | string | ジョブの現在の状態。 設定可能な値は、success 、failure 、または cancelled です。 |
job
コンテキストの内容の例
この job
コンテキストの例では、マップされたポートを持つ PostgreSQL サービス コンテナーを使用します。 ジョブで使用されるコンテナーまたはサービス コンテナーがない� �合、job
コンテキストには status
プロパティのみが含まれます。
{
"status": "success",
"container": {
"network": "github_network_53269bd575974817b43f4733536b200c"
},
"services": {
"postgres": {
"id": "60972d9aa486605e66b0dad4abb638dc3d9116f566579e418166eedb8abb9105",
"ports": {
"5432": "49153"
},
"network": "github_network_53269bd575974817b43f4733536b200c"
}
}
}
job
コンテキストの使用例
このワークフロー例では、PostgreSQL サービス コンテナーを構成し、サービス コンテナー内のポート 5432 をホスト上でランダ� に選ばれた使用可能なポートに自動的にマップします。 job
コンテキストは、ホストで割り当てられた番号のポートにアクセスするために使用されます。
name: PostgreSQL Service Example
on: push
jobs:
postgres-job:
runs-on: ubuntu-latest
services:
postgres:
image: postgres
env:
POSTGRES_PASSWORD: postgres
options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
ports:
# Maps TCP port 5432 in the service container to a randomly chosen available port on the host.
- 5432
steps:
- uses: actions/checkout@v2
- run: pg_isready -h localhost -p ${{ job.services.postgres.ports[5432] }}
- run: ./run-tests
steps
コンテキスト
steps
コンテキストには、id
が指定されていて、既に実行されている現在のジョブのステップに関する情� �が含まれています。
プロパティ名 | Type | 説明 |
---|---|---|
steps | object | このコンテキストは、ジョブのステップごとに異なります。 このコンテキストには、ジョブのあらゆるステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。 |
steps.<step_id>.outputs | object | ステップに定義された出力のセット。 詳細については、「GitHub Actions のメタデータ構文」を参照してく� さい。 |
steps.<step_id>.conclusion | string | continue-on-error の適用後の完了したステップの結果。 指定できる値は、success 、failure 、cancelled 、および skipped です。 continue-on-error ステップが失敗した� �合、outcome は failure になりますが、最終的な conclusion は success になります。 |
steps.<step_id>.outcome | string | continue-on-error の適用前の完了したステップの結果。 指定できる値は、success 、failure 、cancelled 、および skipped です。 continue-on-error ステップが失敗した� �合、outcome は failure になりますが、最終的な conclusion は success になります。 |
steps.<step_id>.outputs.<output_name> | string | 特定の出力の値。 |
steps
コンテキストの内容の例
この steps
コンテキストの例は、id
が指定された 2 つの前のステップを示しています。 最初のステップの id
は checkout
という名前で、2 番目は generate_number
です。 generate_number
ステップの出力は random_number
という名前です。
{
"checkout": {
"outputs": {},
"outcome": "success",
"conclusion": "success"
},
"generate_number": {
"outputs": {
"random_number": "1"
},
"outcome": "success",
"conclusion": "success"
}
}
steps
コンテキストの使用例
このワークフロー例では、1 つのステップで出力として乱数を生成し、後のステップでは steps
コンテキストを使用してその出力の値を読み取ります。
name: Generate random failure
on: push
jobs:
randomly-failing-job:
runs-on: ubuntu-latest
steps:
- id: checkout
uses: actions/checkout@v2
- name: Generate 0 or 1
id: generate_number
run: echo "::set-output name=random_number::$(($RANDOM % 2))"
- name: Pass or fail
run: |
if [[ ${{ steps.generate_number.outputs.random_number }} == 0 ]]; then exit 0; else exit 1; fi
runner
コンテキスト
runner
コンテキストには、現在のジョブを実行しているランナーに関する情� �が含まれています。
プロパティ名 | Type | 説明 |
---|---|---|
runner | object | このコンテキストは、実行しているジョブごとに異なります。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。 |
runner.name | string | ジョブを実行しているランナーの名前。 |
runner.os | string | ジョブを実行しているランナーのオペレーティングシステ� 。 設定可能な値は、Linux 、Windows 、または macOS です。 |
runner.temp | string | ランナー上の一時ディレクトリへのパス。 このディレクトリは、各ジョブの開始及び終了時点で空になります。 ランナーのユーザアカウントが削除する権限を持っていない� �合、ファイルは削除されないことに注意してく� さい。 |
runner.tool_cache | string | GitHubホストランナーにプレインストールされているツールを含むディレクトリへのパス。 詳細については、「GitHub ホスト ランナーの概要」を参照してく� さい。 |
runner.debug | string | これは、デバッグ ログが有効になっている� �合にのみ設定され、値は常に 1 です。 独自のジョブ手� �で追� のデバッグまたは詳細ログを有効にするためのインジケーターとして役に立ちます。 |
runner
コンテキストの内容の例
次のコンテキスト例は、Linux GitHub ホスト ランナーからのものです。
{
"os": "Linux",
"arch": "X64",
"name": "GitHub Actions 2",
"tool_cache": "/opt/hostedtoolcache",
"temp": "/home/runner/work/_temp"
}
runner
コンテキストの使用例
このワークフロー例では、runner
コンテキストを使用して、ログを書き込む一時ディレクトリへのパスを設定し、ワークフローが失敗した� �合は、それらのログを成果物としてアップロードします。
name: Build
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Build with logs
run: |
mkdir ${{ runner.temp }}/build_logs
./build.sh --log-path ${{ runner.temp }}/build_logs
- name: Upload logs on fail
if: ${{ failure() }}
uses: actions/upload-artifact@v2
with:
name: Build failure logs
path: ${{ runner.temp }}/build_logs
secrets
コンテキスト
secrets
コンテキストには、ワークフロー実行で使用できるシークレットの名前と値が含まれています。 セキュリティ上の理由から、複合アクションに secrets
コンテキストは使用できません。 複合アクションにシークレットを渡すには、入力として明示的に行う必要があります。 シークレットについて詳しくは、「暗号化されたシークレット」を参照してく� さい。
GITHUB_TOKEN
は、すべてのワークフロー実行に対して自動的に作成されるシークレットであり、常に secrets
コンテキストに含まれます。 詳しくは、「自動トークン認証」を参照してく� さい。
警告: GitHub はログに出力されたシークレットを自動的に削除しますが、シークレットをログに出力することは意識的に避けなくてはなりません。
プロパティ名 | Type | 説明 |
---|---|---|
secrets | object | このコンテキストは、ワークフロー実行のジョブごとに同じです。 このコンテキストには、ジョブのあらゆるステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。 |
secrets.GITHUB_TOKEN | string | ワークフロー実行ごとに自動的に作成されたトークン。 詳しくは、「自動トークン認証」を参照してく� さい。 |
secrets.<secret_name> | string | 特定のシークレットの値。 |
secrets
コンテキストの内容の例
次の secrets
コンテキストの内容の例は、自動 GITHUB_TOKEN
と、ワークフロー実行で使用できる他の 2 つのシークレットを示しています。
{
"github_token": "***",
"NPM_TOKEN": "***",
"SUPERSECRET": "***"
}
secrets
コンテキストの使用例
次のワークフローの例では、repo-token
入力パラメーターの値として GITHUB_TOKEN
を必要とするラベラー アクションを使用します。
name: Pull request labeler
on: [ pull_request_target ]
permissions:
contents: read
pull-requests: write
jobs:
triage:
runs-on: ubuntu-latest
steps:
- uses: actions/labeler@v3
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
strategy
コンテキスト
マトリックスを含むワークフローの� �合、strategy
コンテキストには現在のジョブのマトリックス実行戦略に関する情� �が含まれます。
プロパティ名 | Type | 説明 |
---|---|---|
strategy | object | このコンテキストは、実行しているジョブごとに異なります。 このコンテキストには、ワークフロー内の任意のジョブまたはステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。 |
strategy.fail-fast | boolean | true の� �合、マトリックス内のジョブが失敗すると、進行中のすべてのジョブが取り消されます。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。 |
strategy.job-index | number | マトリックス内の現在のジョブのインデックス。 注: この数値は 0 から始まる数値です。 マトリックス内の最初のジョブのインデックスは 0 です。 |
strategy.job-total | number | マトリックス内のジョブの合計数。 注: この数値は 0 から始まる数値では ありません。 たとえば、4 つのジョブを含むマトリックスの� �合、job-total の値は 4 になります。 |
strategy.max-parallel | number | matrix ジョブ戦略を使用するときに、同時に実行できるジョブの最大数。 詳細については、GitHub Actions のワークフロー構文に関するページを参照してく� さい。 |
strategy
コンテキストの内容の例
次の strategy
コンテキストの内容の例は、4 つのジョブを含むマトリックスからのものであり、最終的なジョブから取得されたものです。 0 から始まる job-index
数値と、0 から始まらない job-total
との違いに注意してく� さい。
{
"fail-fast": true,
"job-index": 3,
"job-total": 4,
"max-parallel": 4
}
strategy
コンテキストの使用例
このワークフロー例では strategy.job-index
プロパティを使用して、マトリックス内の各ジョブのログ ファイルの一意の名前を設定します。
name: Test matrix
on: push
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
test-group: [1, 2]
node: [14, 16]
steps:
- uses: actions/checkout@v2
- run: npm test > test-job-${{ strategy.job-index }}.txt
- name: Upload logs
uses: actions/upload-artifact@v2
with:
name: Build log for job ${{ strategy.job-index }}
path: test-job-${{ strategy.job-index }}.txt
matrix
コンテキスト
マトリックスを含むワークフローの� �合、matrix
コンテキストには、現在のジョブに適用されるワークフロー ファイルで定義されているマトリックス プロパティが含まれます。 たとえば、os
と node
キーを使用してマトリックスを構成する� �合、matrix
コンテキスト オブジェクトには、現在のジョブで使用されている値を持つ os
と node
プロパティが含まれます。
matrix
コンテキストには標準プロパティはなく、ワークフロー ファイルで定義されているもののみとなります。
プロパティ名 | Type | 説明 |
---|---|---|
matrix | object | このコンテキストは、マトリックス内のジョブに対してのみ使用でき、ワークフロー実行のジョブごとに変わります。 このコンテキストには、ワークフロー内の任意のジョブまたはステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているプロパティが含まれています。 |
matrix.<property_name> | string | マトリックス プロパティの値。 |
matrix
コンテキストの内容の例
次の matrix
コンテキストの内容の例は、ワークフローで定義された os
と node
マトリックス プロパティを持つマトリックス内のジョブからのものです。 そのジョブでは、ubuntu-latest
OS と Node.js バージョン16
のマトリックスの組み合わせが実行されています。
{
"os": "ubuntu-latest",
"node": 16
}
matrix
コンテキストの使用例
このワークフロー例では、os
と node
キーを使用してマトリックスを作成します。 matrix.os
プロパティを使って各ジョブのランナーの種類が設定され、matrix.node
プロパティを使用して各ジョブの Node.js バージョンが設定されます。
name: Test matrix
on: push
jobs:
build:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node: [14, 16]
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node }}
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
needs
コンテキスト
needs
コンテキストには、現在のジョブの直接依存関係として定義されたすべてのジョブからの出力が含まれます。 これには、暗黙的な依存ジョブ (たとえば、依存ジョブの依存ジョブ) は含まれないことに注意してく� さい。 ジョブの依存関係の定義について詳しくは、「GitHub Actions のワークフロー構文」を参照してく� さい。
プロパティ名 | Type | 説明 |
---|---|---|
needs | object | このコンテキストは、依存ジョブを持つワークフロー実行に対してのみ設定され、ワークフロー実行のジョブごとに変わります。 このコンテキストには、ワークフロー内の任意のジョブまたはステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。 |
needs.<job_id> | object | 現在のジョブが依存している1つのジョブ。 |
needs.<job_id>.outputs | object | 現在のジョブが依存しているジョブの出力の集合。 |
needs.<job_id>.outputs.<output name> | string | 現在のジョブが依存しているジョブの特定の出力の値。 |
needs.<job_id>.result | string | 現在のジョブが依存しているジョブの結果。 指定できる値は、success 、failure 、cancelled 、および skipped です。 |
needs
コンテキストの内容の例
needs
コンテキストの次の内容の例は、現在のジョブが依存している 2 つのジョブの情� �を示しています。
{
"build": {
"result": "success",
"outputs": {
"build_id": "ABC123"
}
},
"deploy": {
"result": "failure",
"outputs": {}
}
}
needs
コンテキストの使用例
このワークフロー例には 3 つのジョブがあります。つまり、ビルドを実行する build
ジョブ、build
ジョブを必要とする deploy
ジョブ、build
と deploy
ジョブの両方を必要とし、ワークフローにエラーがある� �合にのみ実行される debug
ジョブです。 また、deploy
ジョブでは needs
コンテキストを使用して build
ジョブからの出力にアクセスします。
name: Build and deploy
on: push
jobs:
build:
runs-on: ubuntu-latest
outputs:
build_id: ${{ steps.build_step.outputs.build_id }}
steps:
- uses: actions/checkout@v2
- name: Build
id: build_step
run: |
./build
echo "::set-output name=build_id::$BUILD_ID"
deploy:
needs: build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- run: ./deploy --build ${{ needs.build.outputs.build_id }}
debug:
needs: [build, deploy]
runs-on: ubuntu-latest
if: ${{ failure() }}
steps:
- uses: actions/checkout@v2
- run: ./debug