注: GitHub ホステッド ランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。
コンテキストについて
コンテキストは、ワークフローの実行、変数、ランナーの環境、ジョブ、ステップに関する情報にアクセスする方法です。 各コンテキストは、プロパティを含むオブジェクトであり、文字列またはその他のオブジェクトにすることができます。
コンテキスト、オブジェクト、プロパティは、ワークフローの実行条件によって大きく異なります。 たとえば、matrix
コンテキストはマトリックス内のジョブに対してのみ設定されます。
式構文を使用してコンテキストにアクセスできます。 詳しくは、「ワークフローとアクションで式を評価する」を参照してください。
${{ <context> }}
警告: ワークフローとアクションを作成するときは、コードが攻撃者からの信頼されていない入力を実行する可能性があるかどうかを常に考慮する必要があります。 攻撃者が悪意あるコンテンツを挿入してくるかもしれないので、特定のコンテキストは信頼できない入力として扱うべきです。 詳しくは、「GitHub Actions のセキュリティ強化」を参照してください。
コンテキスト名 | 型 | 説明 |
---|---|---|
github | object | ワークフロー実行に関する情報。 詳しくは、「github コンテキスト」を参照してください。 |
env | object | ワークフロー、ジョブ、ステップで設定された変数が含まれます。 詳しくは、「env コンテキスト」を参照してください。 |
vars | object | リポジトリ、組織、または環境レベルで設定された変数が含まれます。 詳しくは、「vars コンテキスト」を参照してください。 |
job | object | 現在実行中のジョブに関する情報。 詳しくは、「job コンテキスト」を参照してください。 |
jobs | object | 再利用可能なワークフローの場合のみ、再利用可能なワークフローからのジョブの出力が含まれます。 詳しくは、「jobs コンテキスト」を参照してください。 |
steps | object | 現在のジョブで実行されているステップに関する情報。 詳しくは、「steps コンテキスト」を参照してください。 |
runner | object | 現在のジョブを実行しているランナーに関する情報。 詳しくは、「runner コンテキスト」を参照してください。 |
secrets | object | ワークフロー実行で使用できるシークレットの名前と値が含まれます。 詳しくは、「secrets コンテキスト」を参照してください。 |
strategy | object | 現在のジョブのマトリックス実行戦略に関する情報。 詳しくは、「strategy コンテキスト」を参照してください。 |
matrix | object | 現在のジョブに適用されるワークフローで定義されているマトリックス プロパティが含まれます。 詳しくは、「matrix コンテキスト」を参照してください。 |
needs | object | 現在のジョブの依存関係として定義されているすべてのジョブの出力が含まれます。 詳しくは、「needs コンテキスト」を参照してください。 |
inputs | object | 再利用可能なワークフローまたは手動で行ったワークフローの入力が含まれます。 詳しくは、「inputs コンテキスト」を参照してください。 |
式の一部として、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"
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 | 特殊な関数 |
---|---|---|
run-name | github, inputs, vars | なし |
concurrency | github, inputs, vars | なし |
env | github, secrets, inputs, vars | なし |
jobs.<job_id>.concurrency | github, needs, strategy, matrix, inputs, vars | なし |
jobs.<job_id>.container | github, needs, strategy, matrix, vars, inputs | なし |
jobs.<job_id>.container.credentials | github, needs, strategy, matrix, env, vars, secrets, inputs | なし |
jobs.<job_id>.container.env.<env_id> | github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs | なし |
jobs.<job_id>.container.image | github, needs, strategy, matrix, vars, inputs | なし |
jobs.<job_id>.continue-on-error | github, needs, strategy, vars, matrix, inputs | なし |
jobs.<job_id>.defaults.run | github, needs, strategy, matrix, env, vars, inputs | なし |
jobs.<job_id>.env | github, needs, strategy, matrix, vars, secrets, inputs | なし |
jobs.<job_id>.environment | github, needs, strategy, matrix, vars, inputs | なし |
jobs.<job_id>.environment.url | github, needs, strategy, matrix, job, runner, env, vars, steps, inputs | なし |
jobs.<job_id>.if | github, needs, vars, inputs | always, cancelled, success, failure |
jobs.<job_id>.name | github, needs, strategy, matrix, vars, inputs | なし |
jobs.<job_id>.outputs.<output_id> | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | なし |
jobs.<job_id>.runs-on | github, needs, strategy, matrix, vars, inputs | なし |
jobs.<job_id>.secrets.<secrets_id> | github, needs, strategy, matrix, secrets, inputs, vars | なし |
jobs.<job_id>.services | github, needs, strategy, matrix, vars, inputs | なし |
jobs.<job_id>.services.<service_id>.credentials | github, needs, strategy, matrix, env, vars, secrets, inputs | なし |
jobs.<job_id>.services.<service_id>.env.<env_id> | github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs | なし |
jobs.<job_id>.steps.continue-on-error | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.env | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.if | github, needs, strategy, matrix, job, runner, env, vars, steps, inputs | always, cancelled, success, failure, hashFiles |
jobs.<job_id>.steps.name | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.run | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.timeout-minutes | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.with | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.working-directory | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.strategy | github, needs, vars, inputs | なし |
jobs.<job_id>.timeout-minutes | github, needs, strategy, matrix, vars, inputs | なし |
jobs.<job_id>.with.<with_id> | github, needs, strategy, matrix, inputs, vars | なし |
on.workflow_call.inputs.<inputs_id>.default | github, inputs, vars | なし |
on.workflow_call.outputs.<output_id>.value | github, jobs, vars, inputs | なし |
例: ログへのコンテキスト情報の出力
デバッグのためにコンテキストの内容をログに出力できます。 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 env: GITHUB_CONTEXT: ${{ toJson(github) }} run: echo "$GITHUB_CONTEXT" - name: Dump job context env: JOB_CONTEXT: ${{ toJson(job) }} run: echo "$JOB_CONTEXT" - name: Dump steps context env: STEPS_CONTEXT: ${{ toJson(steps) }} run: echo "$STEPS_CONTEXT" - name: Dump runner context env: RUNNER_CONTEXT: ${{ toJson(runner) }} run: echo "$RUNNER_CONTEXT" - name: Dump strategy context env: STRATEGY_CONTEXT: ${{ toJson(strategy) }} run: echo "$STRATEGY_CONTEXT" - name: Dump matrix context env: MATRIX_CONTEXT: ${{ toJson(matrix) }} run: echo "$MATRIX_CONTEXT"
name: Context testing
on: push
jobs:
dump_contexts_to_log:
runs-on: ubuntu-latest
steps:
- name: Dump GitHub context
env:
GITHUB_CONTEXT: ${{ toJson(github) }}
run: echo "$GITHUB_CONTEXT"
- name: Dump job context
env:
JOB_CONTEXT: ${{ toJson(job) }}
run: echo "$JOB_CONTEXT"
- name: Dump steps context
env:
STEPS_CONTEXT: ${{ toJson(steps) }}
run: echo "$STEPS_CONTEXT"
- name: Dump runner context
env:
RUNNER_CONTEXT: ${{ toJson(runner) }}
run: echo "$RUNNER_CONTEXT"
- name: Dump strategy context
env:
STRATEGY_CONTEXT: ${{ toJson(strategy) }}
run: echo "$STRATEGY_CONTEXT"
- name: Dump matrix context
env:
MATRIX_CONTEXT: ${{ toJson(matrix) }}
run: echo "$MATRIX_CONTEXT"
github
コンテキスト
github
コンテキストには、ワークフローの実行とその実行をトリガーしたイベントの情報が含まれます。 ほとんどの github
コンテキスト データは環境変数で読み取ることができます。 環境変数について詳しくは、「変数に情報を格納する」をご覧ください。
警告: github
コンテキスト全体を使う場合、github.token
などの機密情報が含まれることに注意してください。 GitHubは、シークレットがコンソールに出力される際にはマスクしますが、コンテキストをエクスポートしたりプリントしたりするときには注意が必要です。
警告: ワークフローとアクションを作成するときは、コードが攻撃者からの信頼されていない入力を実行する可能性があるかどうかを常に考慮する必要があります。 攻撃者が悪意あるコンテンツを挿入してくるかもしれないので、特定のコンテキストは信頼できない入力として扱うべきです。 詳しくは、「GitHub Actions のセキュリティ強化」を参照してください。
プロパティ名 | 種類 | 説明 |
---|---|---|
github | object | ワークフローのあらゆるジョブやステップにおいて使用できる最上位のコンテキスト。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。 |
github.action | string | 現在実行中のアクションの名前、またはステップの id 。 GitHub では特殊文字を削除し、現在のステップで id なしでスクリプトを実行するときに __run という名前を使用します。 同じジョブで同じアクションを複数回使う場合、名前には、前にアンダースコアが付いたシーケンス番号で構成されるサフィックスが含まれます。 たとえば、実行する最初のスクリプトの名前は __run で、2 番目のスクリプトの名前は __run_2 となります。 同様に、actions/checkout の 2 番目の呼び出しは actionscheckout2 になります。 |
github.action_path | string | アクションが置かれているパス。 このプロパティは、複合アクションでのみサポートされます。 このパスを使用して、アクションと同じリポジトリにあるファイルにアクセスできます。たとえば、ディレクトリをパス cd ${{ github.action_path }} に変更します。 |
github.action_ref | string | アクションを実行するステップの場合、これは実行中のアクションの参照です。 たとえば、v2 のようにします。run キーワードで使用しないでください。 このコンテキストを複合アクションで動作させるには、複合アクションの env コンテキスト内で参照します。 |
github.action_repository | string | アクションを実行するステップの場合、これはアクションの所有者とリポジトリの名前です。 たとえば、actions/checkout のようにします。run キーワードで使用しないでください。 このコンテキストを複合アクションで動作させるには、複合アクションの env コンテキスト内で参照します。 |
github.action_status | string | 複合アクションの場合は、複合アクションの現在の結果。 |
github.actor | string | ワークフローの実行を最初にトリガーしたユーザーのユーザー名。 ワークフローの実行が再実行である場合、この値は github.triggering_actor と異なることがあります。 ワークフローのすべての再実行では、再実行を開始したアクター (github.triggering_actor ) が異なる特権を持っている場合であっても、github.actor の特権が使われます。 |
github.actor_id | string | 最初のワークフロー実行をトリガーしたユーザーまたはアプリのアカウント ID。 たとえば、1234567 のようにします。 これはアクターのユーザー名とは異なることに注意してください。 |
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.path | string | ワークフロー コマンドから システム PATH 変数を設定するファイルを見つけるためにランナーで実行するパス。 このファイルは現在のステップに固有であり、ジョブ内のステップごとに異なるファイルです。 詳しくは、「GitHub Actions のワークフロー コマンド」を参照してください。 |
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.ref_name | string | ワークフローの実行をトリガーしたブランチまたはタグの短い参照名。 この値は、GitHub に表示されるブランチまたはタグ名と一致します。 たとえば、feature-branch-1 のようにします。pull request の場合、形式は <pr_number>/merge 。 |
github.ref_protected | boolean | true 分岐保護が、ワークフロー実行をトリガーした ref に対して構成されている場合。 |
github.ref_type | string | ワークフローの実行をトリガーした ref の種類。 有効な値は branch または tag です。 |
github.repository | string | 所有者およびリポジトリの名前。 たとえば、octocat/Hello-World のようにします。 |
github.repository_id | string | リポジトリの ID。 たとえば、「 123456789 」のように入力します。 これはリポジトリ名とは異なることに注意してください。 |
github.repository_owner | string | リポジトリ所有者のユーザー名。 たとえば、octocat のようにします。 |
github.repository_owner_id | string | リポジトリ所有者のアカウント ID。 たとえば、「 1234567 」のように入力します。 これは所有者名とは異なることに注意してください。 |
github.repositoryUrl | string | リポジトリへの Git URL。 たとえば、git://github.com/octocat/hello-world.git のようにします。 |
github.retention_days | string | ワークフロー実行ログと成果物が保持される日数 |
github.run_id | string | 各ワークフローの一意の番号は、リポジトリ内で実行されます。 この番号は、ワークフローの実行をやり直しても変化しません、 |
github.run_number | string | リポジトリ内の特定のワークフローの各実行に対するユニークな番号。 この番号は、ワークフローの最初の実行時に 1 から始まり、新しい実行ごとに増加します。 この番号は、ワークフローの実行をやり直しても変化しません、 |
github.run_attempt | string | リポジトリ内で実行される特定のワークフローの各試行に割り振られる一意の番号。 この番号は、ワークフロー実行の最初の試行時に 1 で始まり、再実行ごとに増加します。 |
github.secret_source | string | ワークフローで使われるシークレットのソース。 指定できる値は None 、Actions 、Dependabot です。 |
github.server_url | string | GitHub サーバーの URL。 (例: https://github.com )。 |
github.sha | string | ワークフローをトリガーしたコミット SHA。 このコミット SHA の値は、ワークフローをトリガーしたイベントによって異なります。 詳しくは、「ワークフローをトリガーするイベント」を参照してください。 たとえば、「 ffac537e6cbbf934b08745a378932722df287a53 」のように入力します。 |
github.token | string | リポジトリにインストールされた GitHub App の代わりに認証を受けるためのトークン。 これは、機能的には GITHUB_TOKEN シークレットと同等です。 詳しくは、「自動トークン認証」を参照してください。 注: このコンテキスト プロパティは Actions ランナーによって設定され、ジョブの実行 steps 内でのみ使用できます。 それ以外の場合、このプロパティの値は null になります。 |
github.triggering_actor | string | ワークフローの実行を開始したユーザーのユーザー名。 ワークフローの実行が再実行である場合、この値は github.actor と異なることがあります。 ワークフローのすべての再実行では、再実行を開始したアクター (github.triggering_actor ) が異なる特権を持っている場合であっても、github.actor の特権が使われます。 |
github.workflow | string | ワークフローの名前です。 ワークフロー ファイルで name を指定していない場合、このプロパティの値は、リポジトリ内にあるワークフロー ファイルの完全なパスになります。 |
github.workflow_ref | string | ワークフローへの参照パス。 たとえば、「 octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch 」のように入力します。 |
github.workflow_sha | string | ワークフロー ファイルのコミット SHA。 |
github.workspace | string | ステップのランナー上の既定の作業ディレクトリと、checkout アクションを使用するときのリポジトリの既定の場所。 |
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: - name: Run normal CI run: echo "Running normal CI" pull_request_ci: runs-on: ubuntu-latest if: ${{ github.event_name == 'pull_request' }} steps: - name: Run PR CI run: echo "Running PR only CI"
name: Run CI
on: [push, pull_request]
jobs:
normal_ci:
runs-on: ubuntu-latest
steps:
- name: Run normal CI
run: echo "Running normal CI"
pull_request_ci:
runs-on: ubuntu-latest
if: ${{ github.event_name == 'pull_request' }}
steps:
- name: Run PR CI
run: echo "Running PR only CI"
env
コンテキスト
env
コンテキストには、ワークフロー、ジョブ、またはステップで設定された変数が含まれます。 ランナー プロセスによって継承された変数は含まれません。 ワークフローでの変数の設定について詳しくは、「GitHub Actions のワークフロー構文」をご覧ください。
env
コンテキストに格納された変数の値を取得し、ワークフローファイルで使用することができます。 ワークフローステップのどのキーでも、id
と uses
鍵以外の env
コンテキストを使うことができます。 ステップの構文について詳しくは、「GitHub Actions のワークフロー構文」をご覧ください。
ランナー内で変数の値を使いたい場合は、そのランナーのオペレーティング システムでの通常の変数読み取り方法を使ってください。
プロパティ名 | 種類 | 説明 |
---|---|---|
env | object | このコンテキストは、ジョブのステップごとに異なります。 このコンテキストには、ジョブのあらゆるステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているプロパティが含まれています。 |
env.<env_name> | string | 特定の環境変数の値。 |
env
コンテキストの内容の例
env
コンテキストの内容は、変数名とその値へのマッピングです。 コンテキストの内容は、ワークフローの実行で使用される場所に応じて変わる場合があります。 この例では、env
コンテキストに2 つの変数が含まれています。
{
"first_name": "Mona",
"super_duper_var": "totally_awesome"
}
env
コンテキストの使用例
このワークフロー例では、ワークフロー、ジョブ、およびステップ レベルで env
コンテキストで 設定されている変数を示します。 その後、${{ env.VARIABLE-NAME }}
構文を使用して、ワークフロー内の個々のステップ内の変数値を取得します。
同じ名前で複数の環境変数が定義されている場合、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
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
vars
コンテキスト
注: GitHub Actions の構成変数は ベータ 段階であり、変更される可能性があります。
vars
コンテキストには、Organization レベル、リポジトリ レベル、環境レベルで設定されたカスタムの構成変数が含まれます。 複数のワークフローで使う構成変数の定義について詳しくは、「変数に情報を格納する」をご覧ください。
vars
コンテキストの内容の例
vars
コンテキストの内容は、構成変数名とその値へのマッピングです。
{
"mascot": "Mona"
}
vars
コンテキストの使用例
このワークフロー例では、vars
コンテキストを使って、リポジトリ レベル、環境レベル、または Organization レベルで設定された構成変数を自動的に使えるようにする方法を示しています。
注: 環境レベルの構成変数は、ランナーによって環境が宣言された後に自動的に使用できます。
構成変数が設定されていない場合、変数を参照するコンテキストの戻り値は空の文字列になります。
次の例は、ワークフロー全体で vars
コンテキストと共に構成変数を使用する方法を示しています。 次の各構成変数は、リポジトリ、Organization、または環境レベルで定義されています。
on: workflow_dispatch: env: # Setting an environment variable with the value of a configuration variable env_var: ${{ vars.ENV_CONTEXT_VAR }} jobs: display-variables: name: ${{ vars.JOB_NAME }} # You can use configuration variables with the `vars` context for dynamic jobs if: ${{ vars.USE_VARIABLES == 'true' }} runs-on: ${{ vars.RUNNER }} environment: ${{ vars.ENVIRONMENT_STAGE }} steps: - name: Use variables run: | echo "repository variable : $REPOSITORY_VAR" echo "organization variable : $ORGANIZATION_VAR" echo "overridden variable : $OVERRIDE_VAR" echo "variable from shell environment : $env_var" env: REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }} ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }} OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }} - name: ${{ vars.HELLO_WORLD_STEP }} if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }} uses: actions/hello-world-javascript-action@main with: who-to-greet: ${{ vars.GREET_NAME }}
on:
workflow_dispatch:
env:
# Setting an environment variable with the value of a configuration variable
env_var: ${{ vars.ENV_CONTEXT_VAR }}
jobs:
display-variables:
name: ${{ vars.JOB_NAME }}
# You can use configuration variables with the `vars` context for dynamic jobs
if: ${{ vars.USE_VARIABLES == 'true' }}
runs-on: ${{ vars.RUNNER }}
environment: ${{ vars.ENVIRONMENT_STAGE }}
steps:
- name: Use variables
run: |
echo "repository variable : $REPOSITORY_VAR"
echo "organization variable : $ORGANIZATION_VAR"
echo "overridden variable : $OVERRIDE_VAR"
echo "variable from shell environment : $env_var"
env:
REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }}
ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }}
OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }}
- name: ${{ vars.HELLO_WORLD_STEP }}
if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }}
uses: actions/hello-world-javascript-action@main
with:
who-to-greet: ${{ vars.GREET_NAME }}
job
コンテキスト
job
コンテキストには、現在実行中のジョブに関する情報が含まれます。
プロパティ名 | 種類 | 説明 |
---|---|---|
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: - run: pg_isready -h localhost -p ${{ job.services.postgres.ports[5432] }} - run: echo "Run tests against Postgres"
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:
- run: pg_isready -h localhost -p ${{ job.services.postgres.ports[5432] }}
- run: echo "Run tests against Postgres"
jobs
コンテキスト
jobs
コンテキストは、再利用可能なワークフローでのみ使うことができ、再利用可能なワークフローに出力を設定するためにのみ使うことができます。 詳しくは、「ワークフローの再利用」を参照してください。
プロパティ名 | 種類 | 説明 |
---|---|---|
jobs | object | これは、再利用可能なワークフローでのみ使うことができ、再利用可能なワークフローに出力を設定するためにのみ使うことができます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。 |
jobs.<job_id>.result | string | 再利用可能なワークフロー内のジョブの結果。 指定できる値は、success 、failure 、cancelled 、および skipped です。 |
jobs.<job_id>.outputs | object | 再利用可能なワークフロー内のジョブの出力セット。 |
jobs.<job_id>.outputs.<output_name> | string | 再利用可能なワークフロー内のジョブの特定の出力値。 |
jobs
コンテキストの内容の例
この jobs
コンテキストの例には、再利用可能なワークフローの実行からのジョブの結果と出力が含まれています。
{
"example_job": {
"result": "success",
"outputs": {
"output1": "hello",
"output2": "world"
}
}
}
jobs
コンテキストの使用例
この再利用可能なワークフローの例では、jobs
コンテキストを使って、再利用可能なワークフローの出力を設定します。 出力のフローが、ステップからジョブへ、その後 workflow_call
トリガーへ向かっていることに注意してください。 詳しくは、「ワークフローの再利用」を参照してください。
name: Reusable workflow on: workflow_call: # Map the workflow outputs to job outputs outputs: firstword: description: "The first output string" value: ${{ jobs.example_job.outputs.output1 }} secondword: description: "The second output string" value: ${{ jobs.example_job.outputs.output2 }} jobs: example_job: name: Generate output runs-on: ubuntu-latest # Map the job outputs to step outputs outputs: output1: ${{ steps.step1.outputs.firstword }} output2: ${{ steps.step2.outputs.secondword }} steps: - id: step1 run: echo "firstword=hello" >> $GITHUB_OUTPUT - id: step2 run: echo "secondword=world" >> $GITHUB_OUTPUT
name: Reusable workflow
on:
workflow_call:
# Map the workflow outputs to job outputs
outputs:
firstword:
description: "The first output string"
value: ${{ jobs.example_job.outputs.output1 }}
secondword:
description: "The second output string"
value: ${{ jobs.example_job.outputs.output2 }}
jobs:
example_job:
name: Generate output
runs-on: ubuntu-latest
# Map the job outputs to step outputs
outputs:
output1: ${{ steps.step1.outputs.firstword }}
output2: ${{ steps.step2.outputs.secondword }}
steps:
- id: step1
run: echo "firstword=hello" >> $GITHUB_OUTPUT
- id: step2
run: echo "secondword=world" >> $GITHUB_OUTPUT
steps
コンテキスト
steps
コンテキストには、id
が指定されていて、既に実行されている現在のジョブのステップに関する情報が含まれています。
プロパティ名 | 種類 | 説明 |
---|---|---|
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: - name: Generate 0 or 1 id: generate_number run: echo "random_number=$(($RANDOM % 2))" >> $GITHUB_OUTPUT - name: Pass or fail run: | if [[ ${{ steps.generate_number.outputs.random_number }} == 0 ]]; then exit 0; else exit 1; fi
name: Generate random failure
on: push
jobs:
randomly-failing-job:
runs-on: ubuntu-latest
steps:
- name: Generate 0 or 1
id: generate_number
run: echo "random_number=$(($RANDOM % 2))" >> $GITHUB_OUTPUT
- name: Pass or fail
run: |
if [[ ${{ steps.generate_number.outputs.random_number }} == 0 ]]; then exit 0; else exit 1; fi
runner
コンテキスト
runner
コンテキストには、現在のジョブを実行しているランナーに関する情報が含まれています。
プロパティ名 | 種類 | 説明 |
---|---|---|
runner | object | このコンテキストは、実行しているジョブごとに異なります。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。 |
runner.name | string | ジョブを実行しているランナーの名前。 この名前は、リポジトリのランナーと組織レベルで同じ名前を使用できるため、ワークフロー実行で一意でない場合があります。 |
runner.os | string | ジョブを実行しているランナーのオペレーティングシステム。 設定可能な値は、Linux 、Windows 、または macOS です。 |
runner.arch | string | ジョブを実行しているランナーのアーキテクチャ。 指定できる値は、X86 、X64 、ARM 、および ARM64 です。 |
runner.temp | string | ランナー上の一時ディレクトリへのパス。 このディレクトリは、各ジョブの開始及び終了時点で空になります。 ランナーのユーザアカウントが削除する権限を持っていない場合、ファイルは削除されないことに注意してください。 |
runner.tool_cache | string | GitHubホストランナーにプレインストールされているツールを含むディレクトリへのパス。 詳しくは、「GitHub ホステッド ランナーの使用」をご覧ください。 |
runner.debug | string | これは、デバッグ ログが有効になっている場合にのみ設定され、値は常に 1 です。 独自のジョブ手順で追加のデバッグまたは詳細ログを有効にするためのインジケーターとして役に立ちます。 |
runner.environment | string | ジョブを実行しているランナーの環境。 使用可能な値は、GitHub によって提供される GitHub でホストされたランナーの場合は github-hosted 、リポジトリのオーナーによって構成されたセルフホステッド ランナーの場合は self-hosted です。 |
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@v4 - name: Build with logs run: | mkdir ${{ runner.temp }}/build_logs echo "Logs from building" > ${{ runner.temp }}/build_logs/build.logs exit 1 - name: Upload logs on fail if: ${{ failure() }} uses: actions/upload-artifact@v3 with: name: Build failure logs path: ${{ runner.temp }}/build_logs
name: Build
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build with logs
run: |
mkdir ${{ runner.temp }}/build_logs
echo "Logs from building" > ${{ runner.temp }}/build_logs/build.logs
exit 1
- name: Upload logs on fail
if: ${{ failure() }}
uses: actions/upload-artifact@v3
with:
name: Build failure logs
path: ${{ runner.temp }}/build_logs
secrets
コンテキスト
secrets
コンテキストには、ワークフロー実行で使用できるシークレットの名前と値が含まれています。 セキュリティ上の理由から、複合アクションに secrets
コンテキストは使用できません。 複合アクションにシークレットを渡すには、入力として明示的に行う必要があります。 シークレットについて詳しくは、「GitHub Actions でのシークレットの使用」をご覧ください。
GITHUB_TOKEN
は、すべてのワークフロー実行に対して自動的に作成されるシークレットであり、常に secrets
コンテキストに含まれます。 詳しくは、「自動トークン認証」を参照してください。
警告: ジョブでシークレットが使用された場合、GitHub はログに出力されたシークレットを自動的に編集します。 シークレットを意図的にログに出力しないようにする必要があります。
プロパティ名 | 種類 | 説明 |
---|---|---|
secrets | object | このコンテキストは、ワークフロー実行のジョブごとに同じです。 このコンテキストには、ジョブのあらゆるステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。 |
secrets.GITHUB_TOKEN | string | ワークフロー実行ごとに自動的に作成されたトークン。 詳しくは、「自動トークン認証」を参照してください。 |
secrets.<secret_name> | string | 特定のシークレットの値。 |
secrets
コンテキストの内容の例
次の secrets
コンテキストの内容の例は、自動 GITHUB_TOKEN
と、ワークフロー実行で使用できる他の 2 つのシークレットを示しています。
{
"github_token": "***",
"NPM_TOKEN": "***",
"SUPERSECRET": "***"
}
secrets
コンテキストの使用例
このワークフローの例では、GH_TOKEN
入力パラメーターの値として GITHUB_TOKEN
を必要とする GitHub CLI が使用されます。
name: Open new issue on: workflow_dispatch jobs: open-issue: runs-on: ubuntu-latest permissions: contents: read issues: write steps: - run: | gh issue --repo ${{ github.repository }} \ create --title "Issue title" --body "Issue body" env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
name: Open new issue
on: workflow_dispatch
jobs:
open-issue:
runs-on: ubuntu-latest
permissions:
contents: read
issues: write
steps:
- run: |
gh issue --repo ${{ github.repository }} \
create --title "Issue title" --body "Issue body"
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
strategy
コンテキスト
マトリックスを含むワークフローの場合、strategy
コンテキストには現在のジョブのマトリックス実行戦略に関する情報が含まれます。
プロパティ名 | 種類 | 説明 |
---|---|---|
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 strategy on: push jobs: test: runs-on: ubuntu-latest strategy: matrix: test-group: [1, 2] node: [14, 16] steps: - run: echo "Mock test logs" > test-job-${{ strategy.job-index }}.txt - name: Upload logs uses: actions/upload-artifact@v3 with: name: Build log for job ${{ strategy.job-index }} path: test-job-${{ strategy.job-index }}.txt
name: Test strategy
on: push
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
test-group: [1, 2]
node: [14, 16]
steps:
- run: echo "Mock test logs" > test-job-${{ strategy.job-index }}.txt
- name: Upload logs
uses: actions/upload-artifact@v3
with:
name: Build log for job ${{ strategy.job-index }}
path: test-job-${{ strategy.job-index }}.txt
matrix
コンテキスト
マトリックスを含むワークフローの場合、matrix
コンテキストには、現在のジョブに適用されるワークフロー ファイルで定義されているマトリックス プロパティが含まれます。 たとえば、os
と node
キーを使用してマトリックスを構成する場合、matrix
コンテキスト オブジェクトには、現在のジョブで使用されている値を持つ os
と node
プロパティが含まれます。
matrix
コンテキストには標準プロパティはなく、ワークフロー ファイルで定義されているもののみとなります。
プロパティ名 | 種類 | 説明 |
---|---|---|
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/setup-node@v4 with: node-version: ${{ matrix.node }} - name: Output node version run: node --version
name: Test matrix
on: push
jobs:
build:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node: [14, 16]
steps:
- uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node }}
- name: Output node version
run: node --version
needs
コンテキスト
needs
コンテキストには、現在のジョブの直接依存関係として定義されたすべてのジョブからの出力が含まれます。 これには、暗黙的な依存ジョブ (たとえば、依存ジョブの依存ジョブ) は含まれないことに注意してください。 ジョブの依存関係の定義については詳しくは、「GitHub Actions のワークフロー構文」を参照してください。
プロパティ名 | 種類 | 説明 |
---|---|---|
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": "123456"
}
},
"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: - name: Build id: build_step run: echo "build_id=$RANDOM" >> $GITHUB_OUTPUT deploy: needs: build runs-on: ubuntu-latest steps: - run: echo "Deploying build ${{ needs.build.outputs.build_id }}" debug: needs: [build, deploy] runs-on: ubuntu-latest if: ${{ failure() }} steps: - run: echo "Failed to build and deploy"
name: Build and deploy
on: push
jobs:
build:
runs-on: ubuntu-latest
outputs:
build_id: ${{ steps.build_step.outputs.build_id }}
steps:
- name: Build
id: build_step
run: echo "build_id=$RANDOM" >> $GITHUB_OUTPUT
deploy:
needs: build
runs-on: ubuntu-latest
steps:
- run: echo "Deploying build ${{ needs.build.outputs.build_id }}"
debug:
needs: [build, deploy]
runs-on: ubuntu-latest
if: ${{ failure() }}
steps:
- run: echo "Failed to build and deploy"
inputs
コンテキスト
inputs
コンテキストには、アクション、再利用可能なワークフロー、または手動で行ったワークフローまでの入力プロパティが含まれます。 再利用可能なワークフローの場合、入力の名前と種類が再利用可能なワークフローの workflow_call
イベント構成で定義され、再利用可能なワークフローを呼び出す外部ワークフローの jobs.<job_id>.with
から入力値が渡されます。 手動で実行したワークフローの場合、入力はワークフローの workflow_dispatch
イベント構成で定義されています。
inputs
コンテキストのプロパティは、ワークフロー ファイルで定義されています。 これらは、再利用可能なワークフローまたは workflow_dispatch
イベントでトリガーしたワークフローでのみ使用できます
プロパティ名 | 種類 | 説明 |
---|---|---|
inputs | object | このコンテキストは、再利用可能なワークフロー{または workflow_dispatch イベントでトリガーしたワークフローでのみ使用できます。 このコンテキストには、ワークフロー内の任意のジョブまたはステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているプロパティが含まれています。 |
inputs.<name> | string または number 、あるいは boolean または choice | 外部ワークフローから渡される各入力値。 |
inputs
コンテキストの内容の例
次の inputs
コンテキストの内容の例は、build_id
、deploy_target
、perform_deploy
の各入力が定義されているワークフローのものです。
{
"build_id": 123456768,
"deploy_target": "deployment_sys_1a",
"perform_deploy": true
}
再利用可能なワークフローでの inputs
コンテキストの使用例
この再利用可能なワークフローの例では、inputs
コンテキストを使って、呼び出し元ワークフローから再利用可能なワークフローに渡された build_id
、deploy_target
、perform_deploy
入力の値を取得しています。
name: Reusable deploy workflow on: workflow_call: inputs: build_id: required: true type: number deploy_target: required: true type: string perform_deploy: required: true type: boolean jobs: deploy: runs-on: ubuntu-latest if: ${{ inputs.perform_deploy }} steps: - name: Deploy build to target run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"
name: Reusable deploy workflow
on:
workflow_call:
inputs:
build_id:
required: true
type: number
deploy_target:
required: true
type: string
perform_deploy:
required: true
type: boolean
jobs:
deploy:
runs-on: ubuntu-latest
if: ${{ inputs.perform_deploy }}
steps:
- name: Deploy build to target
run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"
手動でトリガーされたワークフローでの inputs
コンテキストの使用例
workflow_dispatch
イベントによってトリガーされたこのワークフローの例では、inputs
コンテキストを使って、ワークフローに渡された build_id
、deploy_target
、perform_deploy
入力の値を取得しています。
on: workflow_dispatch: inputs: build_id: required: true type: string deploy_target: required: true type: string perform_deploy: required: true type: boolean jobs: deploy: runs-on: ubuntu-latest if: ${{ inputs.perform_deploy }} steps: - name: Deploy build to target run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"
on:
workflow_dispatch:
inputs:
build_id:
required: true
type: string
deploy_target:
required: true
type: string
perform_deploy:
required: true
type: boolean
jobs:
deploy:
runs-on: ubuntu-latest
if: ${{ inputs.perform_deploy }}
steps:
- name: Deploy build to target
run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"