Skip to main content

コンテキスト リファレンス

使用できるプロパティ、アクセス方法、使用例など、GitHub Actions ワークフローで使用できるコンテキストについて説明します。

この記事で

利用可能なコンテキスト

コンテキスト名タイプ説明
githubobjectワークフロー実行に関する情報。 詳しくは、「github コンテキスト」を参照してください。
envobjectワークフロー、ジョブ、ステップで設定された変数が含まれます。 詳しくは、「env コンテキスト」を参照してください。
varsobjectリポジトリ、組織、または環境レベルで設定された変数が含まれます。 詳しくは、「vars コンテキスト」を参照してください。
jobobject現在実行中のジョブに関する情報。 詳しくは、「job コンテキスト」を参照してください。
jobsobject再利用可能なワークフローの場合のみ、再利用可能なワークフローからのジョブの出力が含まれます。 詳しくは、「jobs コンテキスト」を参照してください。
stepsobject現在のジョブで実行されているステップに関する情報。 詳しくは、「steps コンテキスト」を参照してください。
runnerobject現在のジョブを実行しているランナーに関する情報。 詳しくは、「runner コンテキスト」を参照してください。
secretsobjectワークフロー実行で使用できるシークレットの名前と値が含まれます。 詳しくは、「secrets コンテキスト」を参照してください。
strategyobject現在のジョブのマトリックス実行戦略に関する情報。 詳しくは、「strategy コンテキスト」を参照してください。
matrixobject現在のジョブに適用されるワークフローで定義されているマトリックス プロパティが含まれます。 詳しくは、「matrix コンテキスト」を参照してください。
needsobject現在のジョブの依存関係として定義されているすべてのジョブの出力が含まれます。 詳しくは、「needs コンテキスト」を参照してください。
inputsobject再利用可能な、または手動で行ったワークフローの入力が含まれます。 詳しくは、「inputs コンテキスト」を参照してください。

式の一部として、2 つの構文のいずれかを使用してコンテキスト情報にアクセスできます。

  • インデックス構文: github['sha']
  • プロパティ逆参照構文: github.sha

プロパティ逆参照構文を使うには、プロパティ名が文字または _ で始まっていて、英数字、-、または _ のみを含んでいる必要があります。

存在しないプロパティを逆参照しようとすると、空の文字列として評価されます。

コンテキストを使用する場合の判断

GitHub Actions には、"コンテキスト" と呼ばれる変数のコレクションと、"既定の変数" と呼ばれる同様の変数のコレクションが含まれます。____ これらの変数は、ワークフロー中の様々な場所で利用されることを意図したものです。

  •         **既定の環境変数:** これらの環境変数は、ジョブを実行しているランナーにのみ存在します。 詳しくは、「[AUTOTITLE](/actions/reference/variables-reference#default-environment-variables)」をご覧ください。
    
  •         **コンテキスト:** "既定の変数" を使用できない場合など、ワークフロー内の任意の時点でほとんどのコンテキストを使用できます。__ たとえば、式を含むコンテキストを使って、ジョブが実行のためにランナーにルーティングされる前に初期処理を実行できます。これにより、条件付き `if` キーワードを含むコンテキストを使用して、ステップを実行するかどうかを決定できます。 ジョブが実行されると、`runner.os` など、ジョブを実行しているランナーからコンテキスト変数を取得することもできます。 ワークフロー内でさまざまなコンテキストを使用できる場所について詳しくは、「[コンテキストの可用性](#context-availability)」をご覧ください。
    

以下の例は、さまざまな種類の変数をジョブの中で合わせてどのように使用できるかを示しています。

YAML
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-namegithub, inputs, varsなし
concurrencygithub, inputs, varsなし
envgithub, secrets, inputs, varsなし
jobs.<job_id>.concurrencygithub, needs, strategy, matrix, inputs, varsなし
jobs.<job_id>.containergithub, needs, strategy, matrix, vars, inputsなし
jobs.<job_id>.container.credentialsgithub, 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.imagegithub, needs, strategy, matrix, vars, inputsなし
jobs.<job_id>.continue-on-errorgithub, needs, strategy, vars, matrix, inputsなし
jobs.<job_id>.defaults.rungithub, needs, strategy, matrix, env, vars, inputsなし
jobs.<job_id>.envgithub, needs, strategy, matrix, vars, secrets, inputsなし
jobs.<job_id>.environmentgithub, needs, strategy, matrix, vars, inputsなし
jobs.<job_id>.environment.urlgithub, needs, strategy, matrix, job, runner, env, vars, steps, inputsなし
jobs.<job_id>.ifgithub, needs, vars, inputsalways, cancelled, success, failure
jobs.<job_id>.namegithub, 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-ongithub, needs, strategy, matrix, vars, inputsなし
jobs.<job_id>.secrets.<secrets_id>github, needs, strategy, matrix, secrets, inputs, varsなし
jobs.<job_id>.servicesgithub, needs, strategy, matrix, vars, inputsなし
jobs.<job_id>.services.<service_id>.credentialsgithub, 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-errorgithub, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputshashFiles
jobs.<job_id>.steps.envgithub, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputshashFiles
jobs.<job_id>.steps.ifgithub, needs, strategy, matrix, job, runner, env, vars, steps, inputsalways, cancelled, success, failure, hashFiles
jobs.<job_id>.steps.namegithub, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputshashFiles
jobs.<job_id>.steps.rungithub, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputshashFiles
jobs.<job_id>.steps.timeout-minutesgithub, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputshashFiles
jobs.<job_id>.steps.withgithub, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputshashFiles
jobs.<job_id>.steps.working-directorygithub, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputshashFiles
jobs.<job_id>.strategygithub, needs, vars, inputsなし
jobs.<job_id>.timeout-minutesgithub, needs, strategy, matrix, vars, inputsなし
jobs.<job_id>.with.<with_id>github, needs, strategy, matrix, inputs, varsなし
on.workflow_call.inputs.<inputs_id>.defaultgithub, inputs, varsなし
on.workflow_call.outputs.<output_id>.valuegithub, jobs, vars, inputsなし

例: ログへのコンテキスト情報の出力

デバッグのためにコンテキストの内容をログに出力できます。 JSON オブジェクトをログに整形出力するには、toJSON 関数が必要です。

警告

github コンテキスト全体を使うときは、github.token などの機密情報が含まれることに注意してください。 GitHubは、シークレットがコンソールに出力される際にはマスクしますが、コンテキストをエクスポートしたりプリントしたりするときには注意が必要です。

YAML
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` コンテキスト データのほとんどは環境変数で読み取ることができます。 環境変数について詳しくは、「[AUTOTITLE](/actions/learn-github-actions/variables)」をご覧ください。

警告

github コンテキスト全体を使うときは、github.token などの機密情報が含まれることに注意してください。 GitHubは、シークレットがコンソールに出力される際にはマスクしますが、コンテキストをエクスポートしたりプリントしたりするときには注意が必要です。 ワークフローとアクションを作成するときは、攻撃者によってコードが信頼されていない入力を実行する可能性があるかどうかを常に考慮する必要があります。 攻撃者が悪意あるコンテンツを挿入してくるかもしれないので、特定のコンテキストは信頼できない入力として扱うべきです。 詳しくは、「セキュリティで保護された使用に関するリファレンス」をご覧ください。

プロパティ名タイプ説明
githubobjectワークフローのあらゆるジョブやステップにおいて使用できる最上位のコンテキスト。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。
github.actionstring現在実行中のアクションの名前、またはステップの id。 GitHub では特殊文字を削除し、現在のステップで __run なしでスクリプトを実行するときに id という名前を使用します。 同じジョブで同じアクションを複数回使う場合、名前には、前にアンダースコアが付いたシーケンス番号で構成されるサフィックスが含まれます。 たとえば、実行する最初のスクリプトの名前は __run で、2 番目のスクリプトの名前は __run_2 となります。 同様に、actions/checkout の 2 番目の呼び出しは actionscheckout2 になります。
github.action_pathstringアクションが置かれているパス。 このプロパティは、複合アクションでのみサポートされます。 このパスを使用して、アクションと同じリポジトリにあるファイルにアクセスできます。たとえば、ディレクトリをパス cd ${{ github.action_path }} に変更します。
github.action_refstringアクションを実行するステップの場合、これは実行中のアクションの参照です。 たとえば、v2 のようにします。

データ再利用可能なアクション。コンポジットアクションはサポートされていません。%}
github.action_repositorystringアクションを実行するステップの場合、これはアクションの所有者とリポジトリの名前です。 たとえば、actions/checkout のようにします。

データ再利用可能なアクション。コンポジットアクションはサポートされていません。%}
github.action_statusstring複合アクションの場合は、複合アクションの現在の結果。
github.actorstringワークフローの実行を最初にトリガーしたユーザーのユーザー名。 ワークフローの実行が再実行である場合、この値は github.triggering_actor と異なることがあります。 ワークフローのすべての再実行では、再実行を開始したアクター (github.actor) が異なる特権を持っている場合であっても、github.triggering_actor の特権が使われます。
github.actor_idstring最初のワークフロー実行をトリガーしたユーザーまたはアプリのアカウント ID。 たとえば、1234567 のようにします。 これはアクターのユーザー名とは異なることに注意してください。
github.api_urlstringGitHub REST API の URL。
github.base_refstringワークフローの実行における base_ref または pull request のターゲット ブランチ。 このプロパティは、ワークフローの実行をトリガーしたイベントが pull_request または pull_request_targetにのみ使用できます。
github.envstringワークフロー コマンドから環境変数を設定するファイルへのランナーのパス。 このファイルは現在のステップに固有であり、ジョブ内のステップごとに異なるファイルです。 詳しくは、「GitHub Actions のワークフロー コマンド」をご覧ください。
github.eventobjectwebhook ペイロードの完全なイベント。 このコンテキストを使用して、イベントの個々のプロパティにアクセスできます。 このオブジェクトは、ワークフロー実行をトリガーしたイベントの Webhook ペイロードと同じであり、イベントごとに異なります。 各 GitHub Actions イベントの Webhook は、「ワークフローをトリガーするイベント」でリンクされています。 たとえば、push イベントによってトリガーされるワークフロー実行の場合、このオブジェクトにはプッシュ Webhook ペイロードの内容が含まれます。
github.event_namestringワークフローの実行をトリガーしたイベントの名前。
github.event_pathstring完全なイベント Webhook ペイロードを含むランナー上のファイルへのパス。
github.graphql_urlstringGitHub GraphQL API の URL。
github.head_refstringワークフロー実行における head_ref もしくはプルリクエストのソースブランチ。 このプロパティは、ワークフローの実行をトリガーしたイベントが pull_request または pull_request_targetにのみ使用できます。
github.jobstring現在のジョブの job_id
注: このコンテキスト プロパティは Actions ランナーによって設定され、ジョブの実行 steps 内でのみ使用できます。 それ以外の場合、このプロパティの値は null になります。
github.pathstringシステム PATH 変数をワークフロー コマンドから設定するためのファイルへのランナーのパス。 このファイルは現在のステップに固有であり、ジョブ内のステップごとに異なるファイルです。 詳しくは、「GitHub Actions のワークフロー コマンド」をご覧ください。
github.refstringワークフローの実行をトリガーしたブランチまたはタグの完全な形式の参照。
          `push` によってトリガーされるワークフローの場合、これはプッシュされたブランチまたはタグの参照です。 マージされなかった `pull_request` によってトリガーされるワークフローの場合、これは pull request マージ ブランチです。 pull request がマージされた場合、これはヘッド ブランチです。 
          `release` によってトリガーされるワークフローの場合、これは作成されたリリース タグです。 その他のトリガーの場合、これはワークフロー実行をトリガーしたブランチまたはタグの参照です。 これは、イベントの種類に対してブランチまたはタグを使用できる場合にのみ設定されます。 この参照は完全な形式です。つまり、ブランチの場合の形式は `refs/heads/<branch_name>` です。 マージされなかった `pull_request_target` を除くプル要求イベントの場合は、 `refs/pull/<pr_number>/merge`。 
          `pull_request_target` イベントにはベース ブランチの `ref` があります。 タグの場合は `refs/tags/<tag_name>` です。 たとえば、 `refs/heads/feature-branch-1` です。 |

| github.ref_name | string | ワークフローの実行をトリガーしたブランチまたはタグの短い参照名。 この値は、GitHub に表示されるブランチまたはタグ名と一致します。 たとえば、feature-branch-1 のようにします。

マージされなかったプル要求の場合、形式は <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 | | | 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 | ワークフローで使われるシークレットのソース。 指定できる値は NoneActionsCodespacesDependabot です。 | | github.server_url | string | GitHub サーバーの URL。 (例: https://github.com)。 | | github.sha | string | ワークフローをトリガーしたコミット SHA。 このコミット SHA の値は、ワークフローをトリガーしたイベントによって異なります。 詳しくは、「ワークフローをトリガーするイベント」をご覧ください。 たとえば、 ffac537e6cbbf934b08745a378932722df287a53 です。 | | github.token | string | リポジトリにインストールされた GitHub App の代わりに認証を受けるためのトークン。 これは、機能的には GITHUB_TOKEN シークレットと同等です。 詳しくは、「ワークフローでの認証に 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 コンテキストを使用してジョブを実行します。

YAML
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` コンテキストには、ワークフロー、ジョブ、またはステップで設定された変数が含まれます。 ランナー プロセスによって継承された変数は含まれません。 ワークフローでの変数の設定について詳しくは、「[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#env)」をご覧ください。

          `env` コンテキストに格納された変数の値を取得し、ワークフローファイルで使用することができます。 ワークフローステップのどのキーでも、`env` と `id` 鍵以外の `uses` コンテキストを使うことができます。 ステップの構文について詳しくは、「[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsteps)」をご覧ください。

ランナー内で変数の値を使いたい場合は、そのランナーのオペレーティング システムでの通常の変数読み取り方法を使ってください。

プロパティ名タイプ説明
envobjectこのコンテキストは、ジョブのステップごとに異なります。 このコンテキストには、ジョブのあらゆるステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているプロパティが含まれています。
env.<env_name>string特定の環境変数の値。

          `env` コンテキストの内容の例

          `env` コンテキストの内容は、変数名とその値へのマッピングです。 コンテキストの内容は、ワークフローの実行で使用される場所に応じて変わる場合があります。 この例では、`env` コンテキストに2 つの変数が含まれています。
{
  "first_name": "Mona",
  "super_duper_var": "totally_awesome"
}

          `env` コンテキストの使用例

このワークフロー例では、ワークフロー、ジョブ、およびステップ レベルで env コンテキストで 設定されている変数を示します。 その後、${{ env.VARIABLE-NAME }} 構文を使用して、ワークフロー内の個々のステップ内の変数値を取得します。

同じ名前で複数の環境変数が定義されている場合、GitHub では最も具体的な変数を使用します。 たとえば、ステップ中で定義された環境変数は、ジョブやワークフローの同じ名前の環境変数をステップの実行の間オーバーライドします。 ジョブで定義された環境変数は、そのジョブの実行の間はワークフローの同じ名前の変数をオーバーライドします。

YAML
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 レベル、リポジトリ レベル、環境レベルで設定されたカスタムの構成変数が含まれます。 複数のワークフローで使う構成変数の定義について詳しくは、「[AUTOTITLE](/actions/learn-github-actions/variables#defining-variables-for-multiple-workflows)」をご覧ください。

          `vars` コンテキストの内容の例

          `vars` コンテキストの内容は、構成変数名とその値へのマッピングです。
{
  "mascot": "Mona"
}

          `vars` コンテキストの使用例

このワークフロー例では、vars コンテキストを使って、リポジトリ レベル、環境レベル、または Organization レベルで設定された構成変数を自動的に使えるようにする方法を示しています。

メモ

環境レベルの構成変数は、ランナーによって環境が宣言された後に自動的に使用可能になります。

構成変数が設定されていない場合、変数を参照するコンテキストの戻り値は空の文字列になります。

次の例は、ワークフロー全体で vars コンテキストと共に構成変数を使用する方法を示しています。 次の各構成変数は、リポジトリ、Organization、または環境レベルで定義されています。

YAML
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` コンテキストには、現在実行中のジョブに関する情報が含まれます。
プロパティ名タイプ説明
jobobjectワークフローの実行において、このコンテキストは各ジョブごとに変化します。 このコンテキストには、ジョブのあらゆるステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。
job.check_run_idnumber現在のジョブに関連するチェック実行ID。
job.containerobjectジョブのコンテナに関する情報。 コンテナーについて詳しくは、「GitHub Actions のワークフロー構文」をご覧ください。
job.container.idstringコンテナーの ID。
job.container.networkstringコンテナー ネットワークの ID。 ランナーは、ジョブ内のすべてのコンテナで使用されるネットワークを作成します。
job.servicesobjectジョブのために作成されたサービスコンテナ。 サービス コンテナーについて詳しくは、「GitHub Actions のワークフロー構文」をご覧ください。
job.services.<service_id>.idstringサービス コンテナーの ID。
job.services.<service_id>.networkstringサービス コンテナー ネットワークの ID。 ランナーは、ジョブ内のすべてのコンテナで使用されるネットワークを作成します。
job.services.<service_id>.portsobjectサービスコンテナの公開ポート。
job.statusstringジョブの現在の状態。 設定可能な値は、successfailure、または cancelled です。

          `job` コンテキストの内容の例

この job コンテキストの例では、マップされたポートを持つ PostgreSQL サービス コンテナーを使用します。 ジョブで使用されるコンテナーまたはサービス コンテナーがない場合、 job コンテキストには statuscheck_run_id のプロパティのみが含まれます。

{
  "status": "success",
  "check_run_id": 51725241954,
  "container": {
    "network": "github_network_53269bd575974817b43f4733536b200c"
  },
  "services": {
    "postgres": {
      "id": "60972d9aa486605e66b0dad4abb638dc3d9116f566579e418166eedb8abb9105",
      "ports": {
        "5432": "49153"
      },
      "network": "github_network_53269bd575974817b43f4733536b200c"
    }
  }
}

          `job` コンテキストの使用例

このワークフロー例では、PostgreSQL サービス コンテナーを構成し、サービス コンテナー内のポート 5432 をホスト上でランダムに選ばれた使用可能なポートに自動的にマップします。 job コンテキストは、ホストで割り当てられた番号のポートにアクセスするために使用されます。

YAML
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` コンテキストは、再利用可能なワークフローでのみ使うことができ、再利用可能なワークフローに出力を設定するためにのみ使うことができます。 詳しくは、「[AUTOTITLE](/actions/using-workflows/reusing-workflows#using-outputs-from-a-reusable-workflow)」をご覧ください。
プロパティ名タイプ説明
jobsobjectこれは、再利用可能なワークフローでのみ使うことができ、再利用可能なワークフローに出力を設定するためにのみ使うことができます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。
jobs.<job_id>.resultstring再利用可能なワークフロー内のジョブの結果。 指定できる値は、successfailurecancelled、および skipped です。
jobs.<job_id>.outputsobject再利用可能なワークフロー内のジョブの出力セット。
jobs.<job_id>.outputs.<output_name>string再利用可能なワークフロー内のジョブの特定の出力値。

          `jobs` コンテキストの内容の例

この jobs コンテキストの例には、再利用可能なワークフローの実行からのジョブの結果と出力が含まれています。

{
  "example_job": {
    "result": "success",
    "outputs": {
      "output1": "hello",
      "output2": "world"
    }
  }
}

          `jobs` コンテキストの使用例

この再利用可能なワークフローの例では、jobs コンテキストを使って、再利用可能なワークフローの出力を設定します。 出力のフローが、ステップからジョブへ、その後 workflow_call トリガーへ向かっていることに注意してください。 詳しくは、「ワークフローを再利用する」をご覧ください。

YAML
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`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsid) が指定されていて、既に実行されている現在のジョブのステップに関する情報が含まれています。
プロパティ名タイプ説明
stepsobjectこのコンテキストは、ジョブのステップごとに異なります。 このコンテキストには、ジョブのあらゆるステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。
steps.<step_id>.outputsobjectステップに定義された出力のセット。 詳しくは、「メタデータ構文リファレンス」をご覧ください。
steps.<step_id>.conclusionstring
          [
          `continue-on-error`
          ](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error) の適用後の完了したステップの結果。 指定できる値は、`success`、`failure`、`cancelled`、および `skipped` です。 
          `continue-on-error` ステップが失敗した場合、`outcome` は `failure` になりますが、最終的な `conclusion` は `success` になります。 |

| steps.<step_id>.outcome | string | continue-on-error の適用前の完了したステップの結果。 指定できる値は、successfailurecancelled、および skipped です。 continue-on-error ステップが失敗した場合、outcomefailure になりますが、最終的な conclusionsuccess になります。 | | steps.<step_id>.outputs.<output_name> | string | 特定の出力の値。 |

          `steps` コンテキストの内容の例

この steps コンテキストの例は、id が指定された 2 つの前のステップを示しています。 最初のステップの idcheckout という名前で、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 コンテキストを使用してその出力の値を読み取ります。

YAML
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` コンテキストには、現在のジョブを実行しているランナーに関する情報が含まれています。
プロパティ名タイプ説明
runnerobjectこのコンテキストは、ワークフロー内のジョブごとに変わります。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。
runner.namestringジョブを実行しているランナーの名前。 この名前は、リポジトリのランナーと組織レベルで同じ名前を使用できるため、ワークフロー実行で一意でない場合があります。
runner.osstringデータ 再利用可能な項目.actions.runner-os-description %}
runner.archstringジョブを実行しているランナーのアーキテクチャ。 指定できる値は、X86X64ARM、および ARM64 です。
runner.tempstringランナー上の一時ディレクトリへのパス。 このディレクトリは、各ジョブの開始及び終了時点で空になります。 ランナーのユーザアカウントが削除する権限を持っていない場合、ファイルは削除されないことに注意してください。
runner.tool_cachestringGitHubホストランナーにプレインストールされているツールを含むディレクトリへのパス。 詳しくは、「GitHub ホステッド ランナー」をご覧ください。
runner.debugstringデータ 再利用可能.アクション.ランナー・デバッグ・ディスクリプション %}
runner.environmentstringジョブを実行しているランナーの環境。 使用可能な値は、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 コンテキストを使用して、ログを書き込む一時ディレクトリへのパスを設定し、ワークフローが失敗した場合は、それらのログを成果物としてアップロードします。

YAML
name: Build
on: push

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - 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@v4
        with:
          name: Build failure logs
          path: ${{ runner.temp }}/build_logs

          `secrets` コンテキスト

          `secrets` コンテキストには、ワークフロー実行で使用できるシークレットの名前と値が含まれています。 セキュリティ上の理由から、複合アクションに `secrets` コンテキストは使用できません。 複合アクションにシークレットを渡すには、入力として明示的に行う必要があります。 シークレットについて詳しくは、「[AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions)」をご覧ください。

          `GITHUB_TOKEN` は、すべてのワークフロー実行に対して自動的に作成されるシークレットであり、常に `secrets` コンテキストに含まれます。 詳しくは、「[AUTOTITLE](/actions/security-guides/automatic-token-authentication)」をご覧ください。

データ 使用可能なアクション.秘密の編集警告 %}

プロパティ名タイプ説明
secretsobjectこのコンテキストは、ワークフロー実行のジョブごとに同じです。 このコンテキストには、ジョブのあらゆるステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。
secrets.GITHUB_TOKENstringワークフロー実行ごとに自動的に作成されたトークン。 詳しくは、「ワークフローでの認証に GITHUB_TOKEN を使用する」をご覧ください。
secrets.<secret_name>string特定のシークレットの値。

          `secrets` コンテキストの内容の例

次の secrets コンテキストの内容の例は、自動 GITHUB_TOKEN と、ワークフロー実行で使用できる他の 2 つのシークレットを示しています。

{
  "github_token": "***",
  "NPM_TOKEN": "***",
  "SUPERSECRET": "***"
}

          `secrets` コンテキストの使用例

このワークフローの例では、GH_TOKEN 入力パラメーターの値として GITHUB_TOKEN を必要とする GitHub CLI が使用されます。

YAML
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 コンテキストには現在のジョブのマトリックス実行戦略に関する情報が含まれます。

プロパティ名タイプ説明
strategyobjectこのコンテキストは、ワークフローの実行中のジョブごとに異なります。 このコンテキストには、ワークフロー内の任意のジョブまたはステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。
strategy.fail-fastboolean評価値が true、マトリックス内のジョブが失敗すると、進行中のすべてのジョブがキャンセルされます。 詳しくは、「GitHub Actions のワークフロー構文」をご覧ください。
strategy.job-indexnumberマトリックス内の現在のジョブのインデックス。
          **注:** この数値は 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 プロパティを使用して、マトリックス内の各ジョブのログ ファイルの一意の名前を設定します。

YAML
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@v4
        with:
          name: Build log for job ${{ strategy.job-index }}
          path: test-job-${{ strategy.job-index }}.txt

          `matrix` コンテキスト

マトリックスを含むワークフローの場合、matrix コンテキストには、現在のジョブに適用されるワークフロー ファイルで定義されているマトリックス プロパティが含まれます。 たとえば、osnode キーを使用してマトリックスを構成する場合、matrix コンテキスト オブジェクトには、現在のジョブで使用されている値を持つ osnode プロパティが含まれます。

          `matrix` コンテキストには標準プロパティはなく、ワークフロー ファイルで定義されているもののみとなります。
プロパティ名タイプ説明
matrixobjectこのコンテキストは、マトリックス内のジョブに対してのみ使用でき、ワークフロー実行のジョブごとに変わります。 このコンテキストには、ワークフロー内の任意のジョブまたはステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているプロパティが含まれています。
matrix.<property_name>stringマトリックス プロパティの値。

          `matrix` コンテキストの内容の例

次の matrix コンテキストの内容の例は、ワークフローで定義された osnode マトリックス プロパティを持つマトリックス内のジョブからのものです。 そのジョブでは、ubuntu-latestOS と Node.js バージョン16のマトリックスの組み合わせが実行されています。

{
  "os": "ubuntu-latest",
  "node": 16
}

          `matrix` コンテキストの使用例

このワークフロー例では、osnode キーを使用してマトリックスを作成します。 matrix.os プロパティを使って各ジョブのランナーの種類が設定され、matrix.node プロパティを使用して各ジョブの Node.js バージョンが設定されます。

YAML
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` コンテキストには、現在のジョブの直接依存関係として定義されたすべてのジョブからの出力が含まれます。 これには、暗黙的な依存ジョブ (たとえば、依存ジョブの依存ジョブ) は含まれないことに注意してください。 ジョブの依存関係の定義については詳しくは、「[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds)」をご覧ください。
プロパティ名タイプ説明
needsobjectこのコンテキストは、依存ジョブを持つワークフロー実行に対してのみ設定され、ワークフロー実行のジョブごとに変わります。 このコンテキストには、ワークフロー内の任意のジョブまたはステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているすべてのプロパティが含まれています。
needs.<job_id>object現在のジョブが依存している1つのジョブ。
needs.<job_id>.outputsobject現在のジョブが依存しているジョブの出力の集合。
needs.<job_id>.outputs.<output name>string現在のジョブが依存しているジョブの特定の出力の値。
needs.<job_id>.resultstring現在のジョブが依存しているジョブの結果。 指定できる値は、successfailurecancelled、および skipped です。

          `needs` コンテキストの内容の例

          `needs` コンテキストの次の内容の例は、現在のジョブが依存している 2 つのジョブの情報を示しています。
{
  "build": {
    "result": "success",
    "outputs": {
      "build_id": "123456"
    }
  },
  "deploy": {
    "result": "failure",
    "outputs": {}
  }
}

          `needs` コンテキストの使用例

このワークフロー例には 3 つのジョブがあります。つまり、ビルドを実行する build ジョブ、deploy ジョブを必要とする build ジョブ、debugbuild ジョブの両方を必要とし、ワークフローにエラーがある場合にのみ実行される deploy ジョブです。 また、deploy ジョブでは needs コンテキストを使用して build ジョブからの出力にアクセスします。

YAML
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` イベント構成](/actions/using-workflows/events-that-trigger-workflows#workflow-reuse-events)で定義され、再利用可能なワークフローを呼び出す外部ワークフローの [`jobs.<job_id>.with`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idwith) から入力値が渡されます。 手動で実行したワークフローの場合、入力はワークフローの [`workflow_dispatch` イベント構成](/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch)で定義されています。

          `inputs` コンテキストのプロパティは、ワークフロー ファイルで定義されています。 これらは、[再利用可能なワークフロー](/actions/using-workflows/reusing-workflows)または [`workflow_dispatch` イベント](/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch)でトリガーしたワークフローでのみ使用できます
プロパティ名タイプ説明
inputsobjectこのコンテキストは、再利用可能なワークフロー{または workflow_dispatch イベントでトリガーしたワークフローでのみ使用できます。 このコンテキストには、ワークフロー内の任意のジョブまたはステップからアクセスできます。 このオブジェクトには、以下に一覧表示されているプロパティが含まれています。
inputs.<name>
          `string` または `number`、あるいは `boolean` または `choice` | 外部ワークフローから渡される各入力値。 |

          `inputs` コンテキストの内容の例

次の inputs コンテキストの内容の例は、build_iddeploy_targetperform_deploy の各入力が定義されているワークフローのものです。

{
  "build_id": 123456768,
  "deploy_target": "deployment_sys_1a",
  "perform_deploy": true
}

再利用可能なワークフローでの inputs コンテキストの使用例

この再利用可能なワークフローの例では、inputs コンテキストを使って、呼び出し元ワークフローから再利用可能なワークフローに渡された build_iddeploy_targetperform_deploy 入力の値を取得しています。

YAML
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
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 }}"

参考資料

  •         [AUTOTITLE](/actions/concepts/workflows-and-actions/contexts)