# コンテキスト リファレンス 使用可能なプロパティ、アクセス方法、使用例など、 GitHub Actions ワークフローで使用できるコンテキストに関する情報を確認します。 ## 利用可能なコンテキスト | コンテキスト名 | タイプ | 説明 | | ---------- | -------- | ------------------------------------------------------------------------------------------------- | | `github` | `object` | ワークフロー実行に関する情報。 詳しくは、「[`github` コンテキスト](#github-context)」を参照してください。 | | `env` | `object` | ワークフロー、ジョブ、ステップで設定された変数が含まれます。 詳しくは、「[`env` コンテキスト](#env-context)」を参照してください。 | | `vars` | `object` | リポジトリ、組織、または環境レベルで設定された変数が含まれます。 詳しくは、「[`vars` コンテキスト](#vars-context)」を参照してください。 | | `job` | `object` | 現在実行中のジョブに関する情報。 詳しくは、「[`job` コンテキスト](#job-context)」を参照してください。 | | `jobs` | `object` | 再利用可能なワークフローの場合のみ、再利用可能なワークフローからのジョブの出力が含まれます。 詳しくは、「[`jobs` コンテキスト](#jobs-context)」を参照してください。 | | `steps` | `object` | 現在のジョブで実行されているステップに関する情報。 詳しくは、「[`steps` コンテキスト](#steps-context)」を参照してください。 | | `runner` | `object` | 現在のジョブを実行しているランナーに関する情報。 詳しくは、「[`runner` コンテキスト](#runner-context)」を参照してください。 | | `secrets` | `object` | ワークフロー実行で使用できるシークレットの名前と値が含まれます。 詳しくは、「[`secrets` コンテキスト](#secrets-context)」を参照してください。 | | `strategy` | `object` | 現在のジョブのマトリックス実行戦略に関する情報。 詳しくは、「[`strategy` コンテキスト](#strategy-context)」を参照してください。 | | `matrix` | `object` | 現在のジョブに適用されるワークフローで定義されているマトリックス プロパティが含まれます。 詳しくは、「[`matrix` コンテキスト](#matrix-context)」を参照してください。 | | `needs` | `object` | 現在のジョブの依存関係として定義されているすべてのジョブの出力が含まれます。 詳しくは、「[`needs` コンテキスト](#needs-context)」を参照してください。 | | `inputs` | `object` | 再利用可能な、または手動で行ったワークフローの入力が含まれます。 詳しくは、「[`inputs` コンテキスト](#inputs-context)」を参照してください。 | 式の一部として、2 つの構文のいずれかを使用してコンテキスト情報にアクセスできます。 * インデックス構文: `github['sha']` * プロパティ逆参照構文: `github.sha` プロパティ逆参照構文を使うには、プロパティ名が文字または `_` で始まっていて、英数字、`-`、または `_` のみを含んでいる必要があります。 存在しないプロパティを逆参照しようとすると、空の文字列として評価されます。 ### コンテキストを使用する場合の判断 GitHub Actions には、 *コンテキスト* と呼ばれる変数のコレクションと、 \_既定の変数\_と呼ばれる同様の変数のコレクションが含まれています。 これらの変数は、ワークフロー中の様々な場所で利用されることを意図したものです。 * **既定の環境変数:** これらの環境変数は、ジョブを実行しているランナーにのみ存在します。 詳しくは、「[変数リファレンス](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/variables)」をご覧ください。 * **コンテキスト:** "既定の変数" を使用できない場合など、ワークフロー内の任意の時点でほとんどのコンテキストを使用できます。\_\_ たとえば、式を含むコンテキストを使って、ジョブが実行のためにランナーにルーティングされる前に初期処理を実行できます。これにより、条件付き `if` キーワードを含むコンテキストを使用して、ステップを実行するかどうかを決定できます。 ジョブが実行されると、`runner.os` など、ジョブを実行しているランナーからコンテキスト変数を取得することもできます。 ワークフロー内でさまざまなコンテキストを使用できる場所について詳しくは、「[コンテキストの可用性](#context-availability)」をご覧ください。 以下の例は、さまざまな種類の変数をジョブの中で合わせてどのように使用できるかを示しています。 ```yaml copy 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`](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#github-context) コンテキストをチェックして、現在のブランチ名を判別します。名前が `refs/heads/main`、後続のステップが実行されます。 `if`チェックはGitHub Actionsによって処理され、結果が`true`された場合にのみ、ジョブがランナーに送信されます。 ジョブがランナーに送信されると、ステップが実行され、ランナーから [`$GITHUB_REF`](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/variables) 変数が参照されます。 ### コンテキストの可用性 ワークフローの実行を通して、さまざまなコンテキストを使用できます。 たとえば、`secrets` コンテキストはジョブ内の特定の場所でのみ使用できます。 また、一部の関数は特定の場所でのみ使用できます。 たとえば、`hashFiles` 関数はどこにも使用できません。 次の表は、ワークフロー内で、各コンテキストと特殊関数を使用できる場所に課した制限を一覧表示しています。 一覧表示されているコンテキストは、特定のワークフロー キーでのみ使用でき、他の場所では使用できません。 以下に一覧表示されている場合を除き、任意の場所で関数を使用できます。 | ワークフロー キー | Context | 特殊な関数 | | -------------------------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------ | | `run-name` | `github, inputs, vars` | なし | | `concurrency` | `github, inputs, vars` | なし | | `env` | `github, secrets, inputs, vars` | なし | | `jobs..concurrency` | `github, needs, strategy, matrix, inputs, vars` | なし | | `jobs..container` | `github, needs, strategy, matrix, vars, inputs` | なし | | `jobs..container.credentials` | `github, needs, strategy, matrix, env, vars, secrets, inputs` | なし | | `jobs..container.env.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs` | なし | | `jobs..container.image` | `github, needs, strategy, matrix, vars, inputs` | なし | | `jobs..continue-on-error` | `github, needs, strategy, vars, matrix, inputs` | なし | | `jobs..defaults.run` | `github, needs, strategy, matrix, env, vars, inputs` | なし | | `jobs..env` | `github, needs, strategy, matrix, vars, secrets, inputs` | なし | | `jobs..environment` | `github, needs, strategy, matrix, vars, inputs` | なし | | `jobs..environment.url` | `github, needs, strategy, matrix, job, runner, env, vars, steps, inputs` | なし | | `jobs..if` | `github, needs, vars, inputs` | `always, cancelled, success, failure` | | `jobs..name` | `github, needs, strategy, matrix, vars, inputs` | なし | | `jobs..outputs.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | なし | | `jobs..runs-on` | `github, needs, strategy, matrix, vars, inputs` | なし | | `jobs..secrets.` | `github, needs, strategy, matrix, secrets, inputs, vars` | なし | | `jobs..services` | `github, needs, strategy, matrix, vars, inputs` | なし | | `jobs..services..credentials` | `github, needs, strategy, matrix, env, vars, secrets, inputs` | なし | | `jobs..services..env.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs` | なし | | `jobs..steps.continue-on-error` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.env` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.if` | `github, needs, strategy, matrix, job, runner, env, vars, steps, inputs` | `always, cancelled, success, failure, hashFiles` | | `jobs..steps.name` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.run` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.timeout-minutes` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.with` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.working-directory` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..strategy` | `github, needs, vars, inputs` | なし | | `jobs..timeout-minutes` | `github, needs, strategy, matrix, vars, inputs` | なし | | `jobs..with.` | `github, needs, strategy, matrix, inputs, vars` | なし | | `on.workflow_call.inputs..default` | `github, inputs, vars` | なし | | `on.workflow_call.outputs..value` | `github, jobs, vars, inputs` | なし | ### 例: ログへのコンテキスト情報の出力 デバッグのためにコンテキストの内容をログに出力できます。 JSON オブジェクトをログに整形出力するには、[`toJSON` 関数](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions#tojson)が必要です。 > \[!WARNING] > `github` コンテキスト全体を使うときは、`github.token` などの機密情報が含まれることに注意してください。 GitHubは、シークレットがコンソールに出力される際にはマスクしますが、コンテキストをエクスポートしたりプリントしたりするときには注意が必要です。 ```yaml copy 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` コンテキスト データのほとんどは環境変数で読み取ることができます。 環境変数について詳しくは、「[変数に情報を格納する](/ja/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables)」をご覧ください。 > \[!WARNING] > `github` コンテキスト全体を使うときは、`github.token` などの機密情報が含まれることに注意してください。 GitHubは、シークレットがコンソールに出力される際にはマスクしますが、コンテキストをエクスポートしたりプリントしたりするときには注意が必要です。 > \[!WARNING] > ワークフローとアクションを作成するときは、攻撃者によってコードが信頼されていない入力を実行する可能性があるかどうかを常に考慮する必要があります。 攻撃者が悪意あるコンテンツを挿入してくるかもしれないので、特定のコンテキストは信頼できない入力として扱うべきです。 詳しくは、「[セキュリティで保護された使用に関するリファレンス](/ja/enterprise-server@3.22/actions/reference/security/secure-use#good-practices-for-mitigating-script-injection-attacks)」をご覧ください。 | プロパティ名 | タイプ | 説明 | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `github` | `object` | ワークフローのあらゆるジョブやステップにおいて使用できる最上位のコンテキスト。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。 | | `github.action` | `string` | 現在実行中のアクションの名前、またはステップの [`id`](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsid)。 | | GitHubは特殊文字を削除し、現在のステップが`__run`なしでスクリプトを実行するときに`id`名前を使用します。 同じジョブで同じアクションを複数回使う場合、名前には、前にアンダースコアが付いたシーケンス番号で構成されるサフィックスが含まれます。 たとえば、実行する最初のスクリプトの名前は `__run` で、2 番目のスクリプトの名前は `__run_2` となります。 同様に、`actions/checkout` の 2 番目の呼び出しは `actionscheckout2` になります。 | | | | `github.action_path` | `string` | アクションが置かれているパス。 このプロパティは、複合アクションでのみサポートされます。 このパスを使用して、アクションと同じリポジトリにあるファイルにアクセスできます(たとえば、ディレクトリをパスに変更する (対応する環境変数を使用する): `cd "$GITHUB_ACTION_PATH"`。 環境変数の詳細については、 [セキュリティで保護された使用に関するリファレンス](/ja/enterprise-server@3.22/actions/reference/security/secure-use#use-an-intermediate-environment-variable) を参照してください。 | | `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.actor`) が異なる特権を持っている場合であっても、`github.triggering_actor` の特権が使われます。 | | `github.actor_id` | `string` | 最初のワークフロー実行をトリガーしたユーザーまたはアプリのアカウント ID。 たとえば、`1234567` のようにします。 これはアクターのユーザー名とは異なることに注意してください。 | | `github.api_url` | `string` | | | GitHub REST API の URL。 | | | | | | | | `github.artifacts` | `string` | 現在のステップのワークフロー成果物を識別するファイルへのランナーのパス。 ファイルまたは OCI ダイジェスト参照をワークフロー成果物として識別するために、1 行に 1 つの宣言を記述します。 詳しくは、「[GitHub Actions のワークフロー コマンド](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#declaring-workflow-artifacts)」をご覧ください。 | | `github.artifacts_list` | `string` | 現在のジョブの集計ワークフロー成果物メタデータを JSON として含む読み取り専用ファイルへのランナーのパス。 詳しくは、「[GitHub Actions のワークフロー コマンド](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#reading-workflow-artifacts)」をご覧ください。 | | | | | | `github.base_ref` | `string` | ワークフローの実行における `base_ref` または pull request のターゲット ブランチ。 このプロパティは、ワークフローの実行をトリガーしたイベントが `pull_request` または `pull_request_target`にのみ使用できます。 | | `github.env` | `string` | ワークフロー コマンドから環境変数を設定するファイルへのランナーのパス。 このファイルは現在のステップに固有であり、ジョブ内のステップごとに異なるファイルです。 詳しくは、「[GitHub Actions のワークフロー コマンド](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#setting-an-environment-variable)」をご覧ください。 | | `github.event` | `object` | webhook ペイロードの完全なイベント。 このコンテキストを使用して、イベントの個々のプロパティにアクセスできます。 このオブジェクトは、ワークフロー実行をトリガーしたイベントの Webhook ペイロードと同じであり、イベントごとに異なります。 各 GitHub Actions イベントの Webhook は [ワークフローをトリガーするイベント](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_call) でリンクされています。 たとえば、[`push` イベント](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#push)によってトリガーされるワークフロー実行の場合、このオブジェクトには[プッシュ Webhook ペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#push)の内容が含まれます。 | | `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_target`にのみ使用できます。 | | `github.job` | `string` | 現在のジョブの [`job_id`](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_id)。
注: このコンテキスト プロパティは Actions ランナーによって設定され、ジョブの実行 `steps` 内でのみ使用できます。 それ以外の場合、このプロパティの値は `null` になります。 | | `github.path` | `string` | システム `PATH` 変数をワークフロー コマンドから設定するためのファイルへのランナーのパス。 このファイルは現在のステップに固有であり、ジョブ内のステップごとに異なるファイルです。 詳しくは、「[GitHub Actions のワークフロー コマンド](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#adding-a-system-path)」をご覧ください。 | | `github.ref` | `string` | ワークフローの実行をトリガーしたブランチまたはタグの完全な形式のリファレンス。 | | `push` によってトリガーされるワークフローの場合、これはプッシュされたブランチまたはタグの参照です。 マージされなかった `pull_request` によってトリガーされるワークフローの場合、これは pull request マージ ブランチです。 もしpull requestがマージされた場合、その統合先のブランチはこれです。 | | | | `release` によってトリガーされるワークフローの場合、これは作成されたリリース タグです。 その他のトリガーの場合、これはワークフロー実行をトリガーしたブランチまたはタグの参照です。 これは、イベントの種類に対してブランチまたはタグを使用できる場合にのみ設定されます。 このリファレンスは完全な形に整えられています。つまり、ブランチの場合の形式は`refs/heads/`となります。 マージされなかった `pull_request_target` を除く pull request イベントの場合は、 `refs/pull//merge`。 | | | | `pull_request_target` イベントにはベース ブランチの `ref` があります。 タグの場合は `refs/tags/` です。 たとえば、 `refs/heads/feature-branch-1` です。 プルリクエストのマージブランチの詳細については、[Pull Request](/ja/enterprise-server@3.22/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#pull-request-refs-and-merge-branches) を参照してください。 | | | | `github.ref_name` | `string` | ワークフローの実行をトリガーしたブランチまたはタグの短い参照名。 この値は、GitHub に表示されるブランチまたはタグ名と一致します。 たとえば、`feature-branch-1` のようにします。

マージされなかったプル要求の場合、形式は `/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 の値は、ワークフローをトリガーしたイベントによって異なります。 詳しくは、「[ワークフローをトリガーするイベント](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows)」をご覧ください。 たとえば、 `ffac537e6cbbf934b08745a378932722df287a53` です。 | | `github.token` | `string` | リポジトリにインストールされた GitHub App の代わりに認証を受けるためのトークン。 これは、機能的には `GITHUB_TOKEN` シークレットと同等です。 詳しくは、「[ワークフローでの認証に GITHUB\_TOKEN を使用する](/ja/enterprise-server@3.22/actions/tutorials/authenticate-with-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`](https://github.com/actions/checkout) アクションを使用するときのリポジトリの既定の場所。 | ### `github` コンテキストの内容の例 次のコンテキスト例は、`push` イベントによってトリガーされるワークフロー実行のものです。 この例の `event` オブジェクトは、[`push` Webhook ペイロード](/ja/enterprise-server@3.22/webhooks/webhook-events-and-payloads#push)の内容と同じであるため、切り捨てられています。 > \[!NOTE] > このコンテキストは一例にすぎません。 コンテキストの内容は、実行中のワークフローによって異なります。 コンテキスト、オブジェクト、プロパティは、ワークフローの実行条件によって大きく異なります。 ```json { "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` コンテキストを使用してジョブを実行します。 ```yaml copy 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　のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#env)」をご覧ください。 `env` コンテキストに格納された変数の値を取得し、ワークフローファイルで使用することができます。 ワークフローステップのどのキーでも、`env` と `id` 鍵以外の `uses` コンテキストを使うことができます。 ステップの構文について詳しくは、「[GitHub Actions　のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idsteps)」をご覧ください。 ランナー内で変数の値を使いたい場合は、そのランナーのオペレーティング システムでの通常の変数読み取り方法を使ってください。 | プロパティ名 | タイプ | 説明 | | ---------------- | -------- | ---------------------------------------------------------------------------------------------------- | | `env` | `object` | このコンテキストは、ジョブのステップごとに異なります。 このコンテキストには、ジョブのあらゆるステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているプロパティが含まれています。 | | `env.` | `string` | 特定の環境変数の値。 | ### `env` コンテキストの内容の例 `env` コンテキストの内容は、変数名とその値へのマッピングです。 コンテキストの内容は、ワークフローの実行で使用される場所に応じて変わる場合があります。 この例では、`env` コンテキストに2 つの変数が含まれています。 ```json { "first_name": "Mona", "super_duper_var": "totally_awesome" } ``` ### `env` コンテキストの使用例 このワークフロー例では、ワークフロー、ジョブ、およびステップ レベルで `env` コンテキストで 設定されている変数を示します。 その後、`${{ env.VARIABLE-NAME }}` 構文を使用して、ワークフロー内の個々のステップ内の変数値を取得します。 同じ名前で複数の環境変数が定義されている場合、GitHub では最も具体的な変数を使用します。 たとえば、ステップ中で定義された環境変数は、ジョブやワークフローの同じ名前の環境変数をステップの実行の間オーバーライドします。 ジョブで定義された環境変数は、そのジョブの実行の間はワークフローの同じ名前の変数をオーバーライドします。 ```yaml copy 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` コンテキスト `vars` コンテキストには、Organization レベル、リポジトリ レベル、環境レベルで設定されたカスタムの構成変数が含まれます。 複数のワークフローで使う構成変数の定義について詳しくは、「[変数に情報を格納する](/ja/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables#defining-configuration-variables-for-multiple-workflows)」をご覧ください。 ### `vars` コンテキストの内容の例 `vars` コンテキストの内容は、構成変数名とその値へのマッピングです。 ```json { "mascot": "Mona" } ``` ### `vars` コンテキストの使用例 このワークフロー例では、`vars` コンテキストを使って、リポジトリ レベル、環境レベル、または Organization レベルで設定された構成変数を自動的に使えるようにする方法を示しています。 > \[!NOTE] > 環境レベルの構成変数は、ランナーによって環境が宣言された後に自動的に使用可能になります。 構成変数が設定されていない場合、変数を参照するコンテキストの戻り値は空の文字列になります。 次の例は、ワークフロー全体で `vars` コンテキストと共に構成変数を使用する方法を示しています。 次の各構成変数は、リポジトリ、Organization、または環境レベルで定義されています。 ```yaml copy 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　のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idcontainer)」をご覧ください。 | | `job.container.id` | `string` | コンテナーの ID。 | | `job.container.network` | `string` | コンテナー ネットワークの ID。 ランナーは、ジョブ内のすべてのコンテナで使用されるネットワークを作成します。 | | `job.services` | `object` | ジョブのために作成されたサービスコンテナ。 サービス コンテナーについて詳しくは、「[GitHub Actions　のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idservices)」をご覧ください。 | | `job.services..id` | `string` | サービス コンテナーの ID。 | | `job.services..network` | `string` | サービス コンテナー ネットワークの ID。 ランナーは、ジョブ内のすべてのコンテナで使用されるネットワークを作成します。 | | `job.services..ports` | `object` | サービスコンテナの公開ポート。 | | `job.status` | `string` | ジョブの現在の状態。 設定可能な値は、`success`、`failure`、または `cancelled` です。 | | `job.workflow_ref` | `string` | 現在のジョブを定義するワークフロー ファイルの完全な参照。 たとえば、`octo-org/octo-repo/.github/workflows/deploy.yml@refs/heads/main` のようにします。 ワークフロー ファイルで直接定義されたジョブの場合、これは `github.workflow_ref`と同じです。 | | [ワークフローを再利用する](/ja/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows) で定義されたジョブの場合、これは再利用可能なワークフロー ファイルを参照します。 ( GitHub Enterprise Serverでは使用できません) | | | | `job.workflow_sha` | `string` | 現在のジョブを定義するワークフロー ファイルのコミット SHA。 ( GitHub Enterprise Serverでは使用できません) | | `job.workflow_repository` | `string` | 現在のジョブを定義するワークフロー ファイルを含むリポジトリの `owner/repo` 。 たとえば、`octo-org/octo-repo` のようにします。 ( GitHub Enterprise Serverでは使用できません) | | `job.workflow_file_path` | `string` | 現在のジョブを定義するワークフロー ファイルのファイル パス(リポジトリ ルートを基準とする相対パス)。 たとえば、`.github/workflows/deploy.yml` のようにします。 ( GitHub Enterprise Serverでは使用できません) | ### `job` コンテキストの内容の例 この `job` コンテキストの例では、マップされたポートを持つ PostgreSQL サービス コンテナーを使用します。 ジョブで使用されるコンテナーまたはサービス コンテナーがない場合、 `job` コンテキストには `status`のみが含まれます。 `check_run_id`では、`workflow_ref`とワークフロー ID のプロパティ (`workflow_sha`、`workflow_repository`、`workflow_file_path`、GitHub Enterprise Server) は使用できません。 ```json { "status": "success", "check_run_id": 51725241954, "workflow_ref": "octo-org/octo-repo/.github/workflows/deploy.yml@refs/heads/main", "workflow_sha": "abc123def456789abc123def456789abc123def4", "workflow_repository": "octo-org/octo-repo", "workflow_file_path": ".github/workflows/deploy.yml", "container": { "network": "github_network_53269bd575974817b43f4733536b200c" }, "services": { "postgres": { "id": "60972d9aa486605e66b0dad4abb638dc3d9116f566579e418166eedb8abb9105", "ports": { "5432": "49153" }, "network": "github_network_53269bd575974817b43f4733536b200c" } } } ``` ### `job` コンテキストの使用例 このワークフロー例では、PostgreSQL サービス コンテナーを構成し、サービス コンテナー内のポート 5432 をホスト上でランダムに選ばれた使用可能なポートに自動的にマップします。 `job` コンテキストは、ホストで割り当てられた番号のポートにアクセスするために使用されます。 ```yaml copy 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" ``` ### `job` コンテキスト ワークフロー ID の使用例 > \[!NOTE] > `job.workflow_*` コンテキスト プロパティは、GitHub Enterprise Serverでは使用できません。 この再利用可能なワークフローの例では、呼び出し元のリポジトリではなく、 `job.workflow_repository` と `job.workflow_sha` を使用して独自のソース コードをチェックアウトします。 これは、再利用可能なワークフローがワークフロー定義と併配置されたファイルにアクセスする必要がある場合に便利です。 ```yaml copy # In a reusable workflow (e.g., octo-org/shared-workflows/.github/workflows/deploy.yml) name: Reusable deploy workflow on: workflow_call: jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 with: repository: ${{ job.workflow_repository }} ref: ${{ job.workflow_sha }} - run: echo "Deploying from ${{ job.workflow_ref }}" - run: echo "Workflow file path is ${{ job.workflow_file_path }}" ``` ## `jobs` コンテキスト `jobs` コンテキストは、再利用可能なワークフローでのみ使うことができ、再利用可能なワークフローに出力を設定するためにのみ使うことができます。 詳しくは、「[ワークフローを再利用する](/ja/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows#using-outputs-from-a-reusable-workflow)」をご覧ください。 | プロパティ名 | タイプ | 説明 | | ------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------- | | `jobs` | `object` | これは、再利用可能なワークフローでのみ使うことができ、再利用可能なワークフローに出力を設定するためにのみ使うことができます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。 | | `jobs..result` | `string` | 再利用可能なワークフロー内のジョブの結果。 指定できる値は、`success`、`failure`、`cancelled`、および `skipped` です。 | | `jobs..outputs` | `object` | 再利用可能なワークフロー内のジョブの出力セット。 | | `jobs..outputs.` | `string` | 再利用可能なワークフロー内のジョブの特定の出力値。 | ### `jobs` コンテキストの内容の例 この `jobs` コンテキストの例には、再利用可能なワークフローの実行からのジョブの結果と出力が含まれています。 ```json { "example_job": { "result": "success", "outputs": { "output1": "hello", "output2": "world" } } } ``` ### `jobs` コンテキストの使用例 この再利用可能なワークフローの例では、`jobs` コンテキストを使って、再利用可能なワークフローの出力を設定します。 出力のフローが、ステップからジョブへ、その後 `workflow_call` トリガーへ向かっていることに注意してください。 詳しくは、「[ワークフローを再利用する](/ja/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows#using-outputs-from-a-reusable-workflow)」をご覧ください。 ```yaml copy 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`](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsid) が指定されていて、既に実行されている現在のジョブのステップに関する情報が含まれています。 | プロパティ名 | タイプ | 説明 | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `steps` | `object` | このコンテキストは、ジョブのステップごとに異なります。 このコンテキストには、ジョブのあらゆるステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。 | | `steps..outputs` | `object` | ステップに定義された出力のセット。 詳しくは、「[メタデータ構文リファレンス](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/metadata-syntax#outputs-for-docker-container-and-javascript-actions)」をご覧ください。 | | `steps..conclusion` | `string` | | | \[ | | | | `continue-on-error` | | | | ]\(/actions/reference/workflows-and-actions/workflow-syntax#jobsjob\_idstepscontinue-on-error) の適用後の完了したステップの結果。 指定できる値は、`success`、`failure`、`cancelled`、および `skipped` です。 | | | | `continue-on-error` ステップが失敗した場合、`outcome` は `failure` になりますが、最終的な `conclusion` は `success` になります。 | | | | `steps..outcome` | `string` | | | \[ | | | | `continue-on-error` | | | | ]\(/actions/reference/workflows-and-actions/workflow-syntax#jobsjob\_idstepscontinue-on-error) の適用前の完了したステップの結果。 指定できる値は、`success`、`failure`、`cancelled`、および `skipped` です。 | | | | `continue-on-error` ステップが失敗した場合、`outcome` は `failure` になりますが、最終的な `conclusion` は `success` になります。 | | | | `steps..outputs.` | `string` | 特定の出力の値。 | ### `steps` コンテキストの内容の例 この `steps` コンテキストの例は、[`id`](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsid) が指定された 2 つの前のステップを示しています。 最初のステップの `id`は `checkout` という名前で、2 番目は `generate_number` です。 `generate_number` ステップの出力は `random_number` という名前です。 ```json { "checkout": { "outputs": {}, "outcome": "success", "conclusion": "success" }, "generate_number": { "outputs": { "random_number": "1" }, "outcome": "success", "conclusion": "success" } } ``` ### `steps` コンテキストの使用例 このワークフロー例では、1 つのステップで出力として乱数を生成し、後のステップでは `steps` コンテキストを使用してその出力の値を読み取ります。 ```yaml copy 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 ホステッド ランナー](/ja/enterprise-server@3.22/actions/concepts/runners/github-hosted-runners#preinstalled-software-for-github-owned-images)」をご覧ください。 | | `runner.debug` | `string` | これは、[デバッグ ログ](/ja/enterprise-server@3.22/actions/how-tos/monitor-workflows/enable-debug-logging)が有効になっている場合にのみ設定され、値は常に `1` です。 独自のジョブ手順で追加のデバッグまたは詳細ログを有効にするためのインジケーターとして役に立ちます。 | | `runner.environment` | `string` | ジョブを実行しているランナーの環境。 使用可能な値は、GitHub によって提供される GitHub でホストされたランナーの場合は `github-hosted`、リポジトリのオーナーによって構成されたセルフホステッド ランナーの場合は `self-hosted` です。 | ### `runner` コンテキストの内容の例 次のコンテキスト例は、Linux GitHubホストランナーからのコンテキストです。 ```json { "os": "Linux", "arch": "X64", "name": "GitHub Actions 2", "tool_cache": "/opt/hostedtoolcache", "temp": "/home/runner/work/_temp" } ``` ### `runner` コンテキストの使用例 このワークフロー例では、`runner` コンテキストを使用して、ログを書き込む一時ディレクトリへのパスを設定し、ワークフローが失敗した場合は、それらのログを成果物としてアップロードします。 ```yaml copy name: Build on: push jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - 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 でのシークレットの使用](/ja/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets)」をご覧ください。 `GITHUB_TOKEN` は、すべてのワークフロー実行に対して自動的に作成されるシークレットであり、常に `secrets` コンテキストに含まれます。 詳しくは、「[ワークフローでの認証に GITHUB\_TOKEN を使用する](/ja/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token)」をご覧ください。 > \[!WARNING] > シークレットがワークフロー ジョブで使われている場合、ログに出力されるシークレットは GitHub によって自動的にリダクトされます。 シークレットを意図的にログに出力しないようにする必要があります。 | プロパティ名 | タイプ | 説明 | | ----------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | `secrets` | `object` | このコンテキストは、ワークフロー実行のジョブごとに同じです。 このコンテキストには、ジョブのあらゆるステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。 | | `secrets.GITHUB_TOKEN` | `string` | ワークフロー実行ごとに自動的に作成されたトークン。 詳しくは、「[ワークフローでの認証に GITHUB\_TOKEN を使用する](/ja/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token)」をご覧ください。 | | `secrets.` | `string` | 特定のシークレットの値。 | ### `secrets` コンテキストの内容の例 次の `secrets` コンテキストの内容の例は、自動 `GITHUB_TOKEN` と、ワークフロー実行で使用できる他の 2 つのシークレットを示しています。 ```json { "github_token": "***", "NPM_TOKEN": "***", "SUPERSECRET": "***" } ``` ### `secrets` コンテキストの使用例 このワークフロー例では、[GitHub CLI](/ja/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-github-cli) を使用しており、`GITHUB_TOKEN` 入力パラメーターの値として `GH_TOKEN` が必要です。 ```yaml copy 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　のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategyfail-fast)」をご覧ください。 | | `strategy.job-index` | `number` | マトリックス内の現在のジョブのインデックス。 | | **注:** この数値は 0 から始まる数値です。 マトリックス内の最初のジョブのインデックスは `0` です。 | | | | `strategy.job-total` | `number` | マトリックス内のジョブの合計数。 | | **注:** この数値は 0 から始まる数値では**ありません**。 たとえば、4 つのジョブを含むマトリックスの場合、`job-total` の値は `4` になります。 | | | | `strategy.max-parallel` | `number` | | | `matrix` ジョブ戦略を使用するときに、同時に実行できるジョブの最大数。 詳しくは、「[GitHub Actions　のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategymax-parallel)」をご覧ください。 | | | ### `strategy` コンテキストの内容の例 次の `strategy` コンテキストの内容の例は、4 つのジョブを含むマトリックスからのものであり、最終的なジョブから取得されたものです。 0 から始まる `job-index` 数値と、0 から始まらない `job-total` との違いに注意してください。 ```json { "fail-fast": true, "job-index": 3, "job-total": 4, "max-parallel": 4 } ``` ### `strategy` コンテキストの使用例 このワークフロー例では `strategy.job-index` プロパティを使用して、マトリックス内の各ジョブのログ ファイルの一意の名前を設定します。 ```yaml copy 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.` | `string` | マトリックス プロパティの値。 | ### `matrix` コンテキストの内容の例 次の `matrix` コンテキストの内容の例は、ワークフローで定義された `os` と `node` マトリックス プロパティを持つマトリックス内のジョブからのものです。 そのジョブでは、`ubuntu-latest`OS と Node.js バージョン`16`のマトリックスの組み合わせが実行されています。 ```json { "os": "ubuntu-latest", "node": 16 } ``` ### `matrix` コンテキストの使用例 このワークフロー例では、`os` と `node` キーを使用してマトリックスを作成します。 `matrix.os` プロパティを使って各ジョブのランナーの種類が設定され、`matrix.node` プロパティを使用して各ジョブの Node.js バージョンが設定されます。 ```yaml copy 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@v7 with: node-version: ${{ matrix.node }} - name: Output node version run: node --version ``` ## `needs` コンテキスト `needs` コンテキストには、現在のジョブの直接依存関係として定義されたすべてのジョブからの出力が含まれます。 これには、暗黙的な依存ジョブ (たとえば、依存ジョブの依存ジョブ) は含まれないことに注意してください。 ジョブの依存関係の定義については詳しくは、「[GitHub Actions　のワークフロー構文](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds)」をご覧ください。 | プロパティ名 | タイプ | 説明 | | -------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | `needs` | `object` | このコンテキストは、依存ジョブを持つワークフロー実行に対してのみ設定され、ワークフロー実行のジョブごとに変わります。 このコンテキストには、ワークフロー内の任意のジョブまたはステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。 | | `needs.` | `object` | 現在のジョブが依存している1つのジョブ。 | | `needs..outputs` | `object` | 現在のジョブが依存しているジョブの出力の集合。 | | `needs..outputs.` | `string` | 現在のジョブが依存しているジョブの特定の出力の値。 | | `needs..result` | `string` | 現在のジョブが依存しているジョブの結果。 指定できる値は、`success`、`failure`、`cancelled`、および `skipped` です。 | ### `needs` コンテキストの内容の例 `needs` コンテキストの次の内容の例は、現在のジョブが依存している 2 つのジョブの情報を示しています。 ```json { "build": { "result": "success", "outputs": { "build_id": "123456" } }, "deploy": { "result": "failure", "outputs": {} } } ``` ### `needs` コンテキストの使用例 このワークフロー例には 3 つのジョブがあります。つまり、ビルドを実行する `build` ジョブ、`deploy` ジョブを必要とする `build` ジョブ、`debug` と `build` ジョブの両方を必要とし、ワークフローにエラーがある場合にのみ実行される `deploy` ジョブです。 また、`deploy` ジョブでは `needs` コンテキストを使用して `build` ジョブからの出力にアクセスします。 ```yaml copy 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` イベント構成](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows)で定義され、再利用可能なワークフローを呼び出す外部ワークフローの [`jobs..with`](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idwith) から入力値が渡されます。 手動で実行したワークフローの場合、入力はワークフローの [`workflow_dispatch` イベント構成](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch)で定義されています。 `inputs` コンテキストのプロパティは、ワークフロー ファイルで定義されています。 これらは、[再利用可能なワークフロー](/ja/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows)または [`workflow_dispatch` イベント](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch)でトリガーしたワークフローでのみ使用できます | プロパティ名 | タイプ | 説明 | | ------------------------------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `inputs` | `object` | このコンテキストは、[再利用可能なワークフロー](/ja/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows){または [`workflow_dispatch` イベント](/ja/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch)でトリガーしたワークフローでのみ使用できます。 このコンテキストには、ワークフロー内の任意のジョブまたはステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているプロパティが含まれています。 | | `inputs.` | | | | `string` または `number`、あるいは `boolean` または `choice` | 外部ワークフローから渡される各入力値。 | | ### `inputs` コンテキストの内容の例 次の `inputs` コンテキストの内容の例は、`build_id`、`deploy_target`、`perform_deploy` の各入力が定義されているワークフローのものです。 ```json { "build_id": 123456768, "deploy_target": "deployment_sys_1a", "perform_deploy": true } ``` ### 再利用可能なワークフローでの `inputs` コンテキストの使用例 この再利用可能なワークフローの例では、`inputs` コンテキストを使って、呼び出し元ワークフローから再利用可能なワークフローに渡された `build_id`、`deploy_target`、`perform_deploy` 入力の値を取得しています。 ```yaml copy 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` 入力の値を取得しています。 ```yaml copy 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 }}" ``` ## 参考資料 * [コンテキスト](/ja/enterprise-server@3.22/actions/concepts/workflows-and-actions/contexts)