{"meta":{"title":"Contexts reference","intro":"Find information about contexts available in GitHub Actions workflows, including available properties, access methods, and usage examples.","product":"GitHub Actions","breadcrumbs":[{"href":"/en/actions","title":"GitHub Actions"},{"href":"/en/actions/reference","title":"Reference"},{"href":"/en/actions/reference/workflows-and-actions","title":"Workflows and actions"},{"href":"/en/actions/reference/workflows-and-actions/contexts","title":"Contexts"}],"documentType":"article"},"body":"# Contexts reference\n\nFind information about contexts available in GitHub Actions workflows, including available properties, access methods, and usage examples.\n\n## Available contexts\n\n| Context name | Type | Description |\n| ------------ | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `github` | `object` | Information about the workflow run. For more information, see [`github` context](#github-context). |\n| `env` | `object` | Contains variables set in a workflow, job, or step. For more information, see [`env` context](#env-context). |\n| `vars` | `object` | Contains variables set at the repository, organization, or environment levels. For more information, see [`vars` context](#vars-context). |\n| `job` | `object` | Information about the currently running job. For more information, see [`job` context](#job-context). |\n| `jobs` | `object` | For reusable workflows only, contains outputs of jobs from the reusable workflow. For more information, see [`jobs` context](#jobs-context). |\n| `steps` | `object` | Information about the steps that have been run in the current job. For more information, see [`steps` context](#steps-context). |\n| `runner` | `object` | Information about the runner that is running the current job. For more information, see [`runner` context](#runner-context). |\n| `secrets` | `object` | Contains the names and values of secrets that are available to a workflow run. For more information, see [`secrets` context](#secrets-context). |\n| `strategy` | `object` | Information about the matrix execution strategy for the current job. For more information, see [`strategy` context](#strategy-context). |\n| `matrix` | `object` | Contains the matrix properties defined in the workflow that apply to the current job. For more information, see [`matrix` context](#matrix-context). |\n| `needs` | `object` | Contains the outputs of all jobs that are defined as a dependency of the current job. For more information, see [`needs` context](#needs-context). |\n| `inputs` | `object` | Contains the inputs of a reusable or manually triggered workflow. For more information, see [`inputs` context](#inputs-context). |\n\nAs part of an expression, you can access context information using one of two syntaxes.\n\n* Index syntax: `github['sha']`\n* Property dereference syntax: `github.sha`\n\nIn order to use property dereference syntax, the property name must start with a letter or `_` and contain only alphanumeric characters, `-`, or `_`.\n\nIf you attempt to dereference a nonexistent property, it will evaluate to an empty string.\n\n### Determining when to use contexts\n\nGitHub Actions includes a collection of variables called *contexts* and a similar collection of variables called *default variables*. These variables are intended for use at different points in the workflow:\n\n* **Default environment variables:** These environment variables exist only on the runner that is executing your job. For more information, see [Variables reference](/en/actions/reference/variables-reference#default-environment-variables).\n* **Contexts:** You can use most contexts at any point in your workflow, including when *default variables* would be unavailable. For example, you can use contexts with expressions to perform initial processing before the job is routed to a runner for execution; this allows you to use a context with the conditional `if` keyword to determine whether a step should run. Once the job is running, you can also retrieve context variables from the runner that is executing the job, such as `runner.os`. For details of where you can use various contexts within a workflow, see [Context availability](#context-availability).\n\nThe following example demonstrates how these different types of variables can be used together in a job:\n\n```yaml copy\nname: CI\non: push\njobs:\n prod-check:\n if: ${{ github.ref == 'refs/heads/main' }}\n runs-on: ubuntu-latest\n steps:\n - run: echo \"Deploying to production server on branch $GITHUB_REF\"\n```\n\nIn this example, the `if` statement checks the [`github.ref`](/en/actions/learn-github-actions/contexts#github-context) context to determine the current branch name; if the name is `refs/heads/main`, then the subsequent steps are executed. The `if` check is processed by GitHub Actions, and the job is only sent to the runner if the result is `true`. Once the job is sent to the runner, the step is executed and refers to the [`$GITHUB_REF`](/en/actions/reference/variables-reference#default-environment-variables) variable from the runner.\n\n### Context availability\n\nDifferent contexts are available throughout a workflow run. For example, the `secrets` context may only be used at certain places within a job.\n\nIn addition, some functions may only be used in certain places. For example, the `hashFiles` function is not available everywhere.\n\nThe following table lists the restrictions on where each context and special function can be used within a workflow. The listed contexts are only available for the given workflow key, and may not be used anywhere else. Unless listed below, a function can be used anywhere.\n\n| Workflow key | Context | Special functions |\n| -------------------------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------ |\n| `run-name` | `github, inputs, vars` | None |\n| `concurrency` | `github, inputs, vars` | None |\n| `env` | `github, secrets, inputs, vars` | None |\n| `jobs..concurrency` | `github, needs, strategy, matrix, inputs, vars` | None |\n| `jobs..container` | `github, needs, strategy, matrix, vars, inputs` | None |\n| `jobs..container.credentials` | `github, needs, strategy, matrix, env, vars, secrets, inputs` | None |\n| `jobs..container.env.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs` | None |\n| `jobs..container.image` | `github, needs, strategy, matrix, vars, inputs` | None |\n| `jobs..continue-on-error` | `github, needs, strategy, vars, matrix, inputs` | None |\n| `jobs..defaults.run` | `github, needs, strategy, matrix, env, vars, inputs` | None |\n| `jobs..env` | `github, needs, strategy, matrix, vars, secrets, inputs` | None |\n| `jobs..environment` | `github, needs, strategy, matrix, vars, inputs` | None |\n| `jobs..environment.url` | `github, needs, strategy, matrix, job, runner, env, vars, steps, inputs` | None |\n| `jobs..if` | `github, needs, vars, inputs` | `always, cancelled, success, failure` |\n| `jobs..name` | `github, needs, strategy, matrix, vars, inputs` | None |\n| `jobs..outputs.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | None |\n| `jobs..runs-on` | `github, needs, strategy, matrix, vars, inputs` | None |\n| `jobs..secrets.` | `github, needs, strategy, matrix, secrets, inputs, vars` | None |\n| `jobs..services` | `github, needs, strategy, matrix, vars, inputs` | None |\n| `jobs..services..credentials` | `github, needs, strategy, matrix, env, vars, secrets, inputs` | None |\n| `jobs..services..env.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs` | None |\n| `jobs..steps.continue-on-error` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` |\n| `jobs..steps.env` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` |\n| `jobs..steps.if` | `github, needs, strategy, matrix, job, runner, env, vars, steps, inputs` | `always, cancelled, success, failure, hashFiles` |\n| `jobs..steps.name` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` |\n| `jobs..steps.run` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` |\n| `jobs..steps.timeout-minutes` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` |\n| `jobs..steps.with` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` |\n| `jobs..steps.working-directory` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` |\n| `jobs..strategy` | `github, needs, vars, inputs` | None |\n| `jobs..timeout-minutes` | `github, needs, strategy, matrix, vars, inputs` | None |\n| `jobs..with.` | `github, needs, strategy, matrix, inputs, vars` | None |\n| `on.workflow_call.inputs..default` | `github, inputs, vars` | None |\n| `on.workflow_call.outputs..value` | `github, jobs, vars, inputs` | None |\n\n### Example: printing context information to the log\n\nYou can print the contents of contexts to the log for debugging. The [`toJSON` function](/en/actions/learn-github-actions/expressions#tojson) is required to pretty-print JSON objects to the log.\n\n> \\[!WARNING]\n> When using the whole `github` context, be mindful that it includes sensitive information such as `github.token`. GitHub masks secrets when they are printed to the console, but you should be cautious when exporting or printing the context.\n\n```yaml copy\nname: Context testing\non: push\n\njobs:\n dump_contexts_to_log:\n runs-on: ubuntu-latest\n steps:\n - name: Dump GitHub context\n env:\n GITHUB_CONTEXT: ${{ toJson(github) }}\n run: echo \"$GITHUB_CONTEXT\"\n - name: Dump job context\n env:\n JOB_CONTEXT: ${{ toJson(job) }}\n run: echo \"$JOB_CONTEXT\"\n - name: Dump steps context\n env:\n STEPS_CONTEXT: ${{ toJson(steps) }}\n run: echo \"$STEPS_CONTEXT\"\n - name: Dump runner context\n env:\n RUNNER_CONTEXT: ${{ toJson(runner) }}\n run: echo \"$RUNNER_CONTEXT\"\n - name: Dump strategy context\n env:\n STRATEGY_CONTEXT: ${{ toJson(strategy) }}\n run: echo \"$STRATEGY_CONTEXT\"\n - name: Dump matrix context\n env:\n MATRIX_CONTEXT: ${{ toJson(matrix) }}\n run: echo \"$MATRIX_CONTEXT\"\n```\n\n## `github` context\n\nThe `github` context contains information about the workflow run and the event that triggered the run. You can read most of the `github` context data in environment variables. For more information about environment variables, see [Store information in variables](/en/actions/learn-github-actions/variables).\n\n> \\[!WARNING]\n> When using the whole `github` context, be mindful that it includes sensitive information such as `github.token`. GitHub masks secrets when they are printed to the console, but you should be cautious when exporting or printing the context.\n> \\[!WARNING]\n> When creating workflows and actions, you should always consider whether your code might execute untrusted input from possible attackers. Certain contexts should be treated as untrusted input, as an attacker could insert their own malicious content. For more information, see [Secure use reference](/en/actions/security-guides/security-hardening-for-github-actions#understanding-the-risk-of-script-injections).\n\n| Property name | Type | Description |\n| ---------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `github` | `object` | The top-level context available during any job or step in a workflow. This object contains all the properties listed below. |\n| `github.action` | `string` | The name of the action currently running, or the [`id`](/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsid) of a step. GitHub removes special characters, and uses the name `__run` when the current step runs a script without an `id`. If you use the same action more than once in the same job, the name will include a suffix with the sequence number with underscore before it. For example, the first script you run will have the name `__run`, and the second script will be named `__run_2`. Similarly, the second invocation of `actions/checkout` will be `actionscheckout2`. |\n| `github.action_path` | `string` | The path where an action is located. This property is only supported in composite actions. You can use this path to access files located in the same repository as the action, for example by changing directories to the path (using the corresponding environment variable): `cd \"$GITHUB_ACTION_PATH\"` . For more information on environment variables, see [Secure use reference](/en/actions/reference/security/secure-use#use-an-intermediate-environment-variable). |\n| `github.action_ref` | `string` | For a step executing an action, this is the ref of the action being executed. For example, `v2`.

Do not use in the `run` keyword. To make this context work with composite actions, reference it within the `env` context of the composite action. |\n| `github.action_repository` | `string` | For a step executing an action, this is the owner and repository name of the action. For example, `actions/checkout`.

Do not use in the `run` keyword. To make this context work with composite actions, reference it within the `env` context of the composite action. |\n| `github.action_status` | `string` | For a composite action, the current result of the composite action. |\n| `github.actor` | `string` | The username of the user that triggered the initial workflow run. If the workflow run is a re-run, this value may differ from `github.triggering_actor`. Any workflow re-runs will use the privileges of `github.actor`, even if the actor initiating the re-run (`github.triggering_actor`) has different privileges. |\n| `github.actor_id` | `string` | The account ID of the person or app that triggered the initial workflow run. For example, `1234567`. Note that this is different from the actor username. |\n| `github.api_url` | `string` | The URL of the GitHub REST API. |\n| `github.base_ref` | `string` | The `base_ref` or target branch of the pull request in a workflow run. This property is only available when the event that triggers a workflow run is either `pull_request` or `pull_request_target`. |\n| `github.env` | `string` | Path on the runner to the file that sets environment variables from workflow commands. This file is unique to the current step and is a different file for each step in a job. For more information, see [Workflow commands for GitHub Actions](/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-environment-variable). |\n| `github.event` | `object` | The full event webhook payload. You can access individual properties of the event using this context. This object is identical to the webhook payload of the event that triggered the workflow run, and is different for each event. The webhooks for each GitHub Actions event is linked in [Events that trigger workflows](/en/actions/using-workflows/events-that-trigger-workflows). For example, for a workflow run triggered by the [`push` event](/en/actions/using-workflows/events-that-trigger-workflows#push), this object contains the contents of the [push webhook payload](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#push). |\n| `github.event_name` | `string` | The name of the event that triggered the workflow run. |\n| `github.event_path` | `string` | The path to the file on the runner that contains the full event webhook payload. |\n| `github.graphql_url` | `string` | The URL of the GitHub GraphQL API. |\n| `github.head_ref` | `string` | The `head_ref` or source branch of the pull request in a workflow run. This property is only available when the event that triggers a workflow run is either `pull_request` or `pull_request_target`. |\n| `github.job` | `string` | The [`job_id`](/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_id) of the current job.
Note: This context property is set by the Actions runner, and is only available within the execution `steps` of a job. Otherwise, the value of this property will be `null`. |\n| `github.path` | `string` | Path on the runner to the file that sets system `PATH` variables from workflow commands. This file is unique to the current step and is a different file for each step in a job. For more information, see [Workflow commands for GitHub Actions](/en/actions/using-workflows/workflow-commands-for-github-actions#adding-a-system-path). |\n| `github.ref` | `string` | The fully-formed ref of the branch or tag that triggered the workflow run. For workflows triggered by `push`, this is the branch or tag ref that was pushed. For workflows triggered by `pull_request` that were not merged, this is the pull request merge branch. If the pull request was merged, this is the branch it was merged into. For workflows triggered by `release`, this is the release tag created. For other triggers, this is the branch or tag ref that triggered the workflow run. This is only set if a branch or tag is available for the event type. The ref given is fully-formed, meaning that for branches the format is `refs/heads/`. For pull request events except `pull_request_target` that were not merged, it is `refs/pull//merge`. `pull_request_target` events have the `ref` from the base branch. For tags it is `refs/tags/`. For example, `refs/heads/feature-branch-1`. For more information about pull request merge branches, see [About pull requests](/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#pull-request-refs-and-merge-branches). |\n| `github.ref_name` | `string` | The short ref name of the branch or tag that triggered the workflow run. This value matches the branch or tag name shown on GitHub. For example, `feature-branch-1`.

For pull requests that were not merged, the format is `/merge`. |\n| `github.ref_protected` | `boolean` | `true` if branch protections or [rulesets](/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository) are configured for the ref that triggered the workflow run. |\n| `github.ref_type` | `string` | The type of ref that triggered the workflow run. Valid values are `branch` or `tag`. |\n| `github.repository` | `string` | The owner and repository name. For example, `octocat/Hello-World`. |\n| `github.repository_id` | `string` | The ID of the repository. For example, `123456789`. Note that this is different from the repository name. |\n| `github.repository_owner` | `string` | The repository owner's username. For example, `octocat`. |\n| `github.repository_owner_id` | `string` | The repository owner's account ID. For example, `1234567`. Note that this is different from the owner's name. |\n| `github.repositoryUrl` | `string` | The Git URL to the repository. For example, `git://github.com/octocat/hello-world.git`. |\n| `github.retention_days` | `string` | The number of days that workflow run logs and artifacts are kept. |\n| `github.run_id` | `string` | A unique number for each workflow run within a repository. This number does not change if you re-run the workflow run. |\n| `github.run_number` | `string` | A unique number for each run of a particular workflow in a repository. This number begins at 1 for the workflow's first run, and increments with each new run. This number does not change if you re-run the workflow run. |\n| `github.run_attempt` | `string` | A unique number for each attempt of a particular workflow run in a repository. This number begins at 1 for the workflow run's first attempt, and increments with each re-run. |\n| `github.secret_source` | `string` | The source of a secret used in a workflow. Possible values are `None`, `Actions`, `Codespaces`, or `Dependabot`. |\n| `github.server_url` | `string` | The URL of the GitHub server. For example: `https://github.com`. |\n| `github.sha` | `string` | The commit SHA that triggered the workflow. The value of this commit SHA depends on the event that triggered the workflow. For more information, see [Events that trigger workflows](/en/actions/using-workflows/events-that-trigger-workflows). For example, `ffac537e6cbbf934b08745a378932722df287a53`. |\n| `github.token` | `string` | A token to authenticate on behalf of the GitHub App installed on your repository. This is functionally equivalent to the `GITHUB_TOKEN` secret. For more information, see [Use GITHUB\\_TOKEN for authentication in workflows](/en/actions/security-guides/automatic-token-authentication).
Note: This context property is set by the Actions runner, and is only available within the execution `steps` of a job. Otherwise, the value of this property will be `null`. |\n| `github.triggering_actor` | `string` | The username of the user that initiated the workflow run. If the workflow run is a re-run, this value may differ from `github.actor`. Any workflow re-runs will use the privileges of `github.actor`, even if the actor initiating the re-run (`github.triggering_actor`) has different privileges. |\n| `github.workflow` | `string` | The name of the workflow. If the workflow file doesn't specify a `name`, the value of this property is the full path of the workflow file in the repository. |\n| `github.workflow_ref` | `string` | The ref path to the workflow. For example, `octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch`. |\n| `github.workflow_sha` | `string` | The commit SHA for the workflow file. |\n| `github.workspace` | `string` | The default working directory on the runner for steps, and the default location of your repository when using the [`checkout`](https://github.com/actions/checkout) action. |\n\n### Example contents of the `github` context\n\nThe following example context is from a workflow run triggered by the `push` event. The `event` object in this example has been truncated because it is identical to the contents of the [`push` webhook payload](/en/webhooks-and-events/webhooks/webhook-events-and-payloads#push).\n\n> \\[!NOTE]\n> This context is an example only. The contents of a context depends on the workflow that you are running. Contexts, objects, and properties will vary significantly under different workflow run conditions.\n\n```json\n{\n \"token\": \"***\",\n \"job\": \"dump_contexts_to_log\",\n \"ref\": \"refs/heads/my_branch\",\n \"sha\": \"c27d339ee6075c1f744c5d4b200f7901aad2c369\",\n \"repository\": \"octocat/hello-world\",\n \"repository_owner\": \"octocat\",\n \"repositoryUrl\": \"git://github.com/octocat/hello-world.git\",\n \"run_id\": \"1536140711\",\n \"run_number\": \"314\",\n \"retention_days\": \"90\",\n \"run_attempt\": \"1\",\n \"actor\": \"octocat\",\n \"workflow\": \"Context testing\",\n \"head_ref\": \"\",\n \"base_ref\": \"\",\n \"event_name\": \"push\",\n \"event\": {\n ...\n },\n \"server_url\": \"https://github.com\",\n \"api_url\": \"https://api.github.com\",\n \"graphql_url\": \"https://api.github.com/graphql\",\n \"ref_name\": \"my_branch\",\n \"ref_protected\": false,\n \"ref_type\": \"branch\",\n \"secret_source\": \"Actions\",\n \"workspace\": \"/home/runner/work/hello-world/hello-world\",\n \"action\": \"github_step\",\n \"event_path\": \"/home/runner/work/_temp/_github_workflow/event.json\",\n \"action_repository\": \"\",\n \"action_ref\": \"\",\n \"path\": \"/home/runner/work/_temp/_runner_file_commands/add_path_b037e7b5-1c88-48e2-bf78-eaaab5e02602\",\n \"env\": \"/home/runner/work/_temp/_runner_file_commands/set_env_b037e7b5-1c88-48e2-bf78-eaaab5e02602\"\n}\n```\n\n### Example usage of the `github` context\n\nThis example workflow uses the `github.event_name` context to run a job only if the workflow run was triggered by the `pull_request` event.\n\n```yaml copy\nname: Run CI\non: [push, pull_request]\n\njobs:\n normal_ci:\n runs-on: ubuntu-latest\n steps:\n - name: Run normal CI\n run: echo \"Running normal CI\"\n\n pull_request_ci:\n runs-on: ubuntu-latest\n if: ${{ github.event_name == 'pull_request' }}\n steps:\n - name: Run PR CI\n run: echo \"Running PR only CI\"\n```\n\n## `env` context\n\nThe `env` context contains variables that have been set in a workflow, job, or step. It does not contain variables inherited by the runner process. For more information about setting variables in your workflow, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#env).\n\nYou can retrieve the values of variables stored in `env` context and use these values in your workflow file. You can use the `env` context in any key in a workflow step except for the `id` and `uses` keys. For more information on the step syntax, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsteps).\n\nIf you want to use the value of a variable inside a runner, use the runner operating system's normal method for reading environment variables.\n\n| Property name | Type | Description |\n| ---------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `env` | `object` | This context changes for each step in a job. You can access this context from any step in a job. This object contains the properties listed below. |\n| `env.` | `string` | The value of a specific environment variable. |\n\n### Example contents of the `env` context\n\nThe contents of the `env` context is a mapping of variable names to their values. The context's contents can change depending on where it is used in the workflow run. In this example, the `env` context contains two variables.\n\n```json\n{\n \"first_name\": \"Mona\",\n \"super_duper_var\": \"totally_awesome\"\n}\n```\n\n### Example usage of the `env` context\n\nThis example workflow shows variables being set in the `env` context at the workflow, job, and step levels. The `${{ env.VARIABLE-NAME }}` syntax is then used to retrieve variable values within individual steps in the workflow.\n\nWhen more than one environment variable is defined with the same name, GitHub uses the most specific variable. For example, an environment variable defined in a step will override job and workflow environment variables with the same name, while the step executes. An environment variable defined for a job will override a workflow variable with the same name, while the job executes.\n\n```yaml copy\nname: Hi Mascot\non: push\nenv:\n mascot: Mona\n super_duper_var: totally_awesome\n\njobs:\n windows_job:\n runs-on: windows-latest\n steps:\n - run: echo 'Hi ${{ env.mascot }}' # Hi Mona\n - run: echo 'Hi ${{ env.mascot }}' # Hi Octocat\n env:\n mascot: Octocat\n linux_job:\n runs-on: ubuntu-latest\n env:\n mascot: Tux\n steps:\n - run: echo 'Hi ${{ env.mascot }}' # Hi Tux\n```\n\n## `vars` context\n\nThe `vars` context contains custom configuration variables set at the organization, repository, and environment levels. For more information about defining configuration variables for use in multiple workflows, see [Store information in variables](/en/actions/learn-github-actions/variables#defining-variables-for-multiple-workflows).\n\n### Example contents of the `vars` context\n\nThe contents of the `vars` context is a mapping of configuration variable names to their values.\n\n```json\n{\n \"mascot\": \"Mona\"\n}\n```\n\n### Example usage of the `vars` context\n\nThis example workflow shows how configuration variables set at the repository, environment, or organization levels are automatically available using the `vars` context.\n\n> \\[!NOTE]\n> Configuration variables at the environment level are automatically available after their environment is declared by the runner.\n\nIf a configuration variable has not been set, the return value of a context referencing the variable will be an empty string.\n\nThe following example shows using configuration variables with the `vars` context across a workflow. Each of the following configuration variables have been defined at the repository, organization, or environment levels.\n\n```yaml copy\non:\n workflow_dispatch:\nenv:\n # Setting an environment variable with the value of a configuration variable\n env_var: ${{ vars.ENV_CONTEXT_VAR }}\n\njobs:\n display-variables:\n name: ${{ vars.JOB_NAME }}\n # You can use configuration variables with the `vars` context for dynamic jobs\n if: ${{ vars.USE_VARIABLES == 'true' }}\n runs-on: ${{ vars.RUNNER }}\n environment: ${{ vars.ENVIRONMENT_STAGE }}\n steps:\n - name: Use variables\n run: |\n echo \"repository variable : $REPOSITORY_VAR\"\n echo \"organization variable : $ORGANIZATION_VAR\"\n echo \"overridden variable : $OVERRIDE_VAR\"\n echo \"variable from shell environment : $env_var\"\n env:\n REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }}\n ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }}\n OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }}\n \n - name: ${{ vars.HELLO_WORLD_STEP }}\n if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }}\n uses: actions/hello-world-javascript-action@main\n with:\n who-to-greet: ${{ vars.GREET_NAME }}\n```\n\n## `job` context\n\nThe `job` context contains information about the currently running job.\n\n| Property name | Type | Description |\n| ----------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `job` | `object` | This context changes for each job in a workflow run. You can access this context from any step in a job. This object contains all the properties listed below. |\n| | | |\n| `job.check_run_id` | `number` | The check run ID of the current job. |\n| | | |\n| `job.container` | `object` | Information about the job's container. For more information about containers, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontainer). |\n| `job.container.id` | `string` | The ID of the container. |\n| `job.container.network` | `string` | The ID of the container network. The runner creates the network used by all containers in a job. |\n| `job.services` | `object` | The service containers created for a job. For more information about service containers, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idservices). |\n| `job.services..id` | `string` | The ID of the service container. |\n| `job.services..network` | `string` | The ID of the service container network. The runner creates the network used by all containers in a job. |\n| `job.services..ports` | `object` | The exposed ports of the service container. |\n| `job.status` | `string` | The current status of the job. Possible values are `success`, `failure`, or `cancelled`. |\n| `job.workflow_ref` | `string` | The full ref of the workflow file that defines the current job. For example, `octo-org/octo-repo/.github/workflows/deploy.yml@refs/heads/main`. For jobs defined directly in a workflow file, this is the same as `github.workflow_ref`. For jobs defined in a [Reuse workflows](/en/actions/using-workflows/reusing-workflows), this refers to the reusable workflow file. (not available on GitHub Enterprise Server) |\n| `job.workflow_sha` | `string` | The commit SHA of the workflow file that defines the current job. (not available on GitHub Enterprise Server) |\n| `job.workflow_repository` | `string` | The `owner/repo` of the repository containing the workflow file that defines the current job. For example, `octo-org/octo-repo`. (not available on GitHub Enterprise Server) |\n| `job.workflow_file_path` | `string` | The file path of the workflow file that defines the current job, relative to the repository root. For example, `.github/workflows/deploy.yml`. (not available on GitHub Enterprise Server) |\n\n### Example contents of the `job` context\n\nThis example `job` context uses a PostgreSQL service container with mapped ports. If there are no containers or service containers used in a job, the `job` context only contains `status`. The `check_run_id` and workflow identity properties (`workflow_ref`, `workflow_sha`, `workflow_repository`, `workflow_file_path`) are not available on GitHub Enterprise Server.\n\n```json\n{\n \"status\": \"success\",\n \"check_run_id\": 51725241954,\n \"workflow_ref\": \"octo-org/octo-repo/.github/workflows/deploy.yml@refs/heads/main\",\n \"workflow_sha\": \"abc123def456789abc123def456789abc123def4\",\n \"workflow_repository\": \"octo-org/octo-repo\",\n \"workflow_file_path\": \".github/workflows/deploy.yml\",\n \"container\": {\n \"network\": \"github_network_53269bd575974817b43f4733536b200c\"\n },\n \"services\": {\n \"postgres\": {\n \"id\": \"60972d9aa486605e66b0dad4abb638dc3d9116f566579e418166eedb8abb9105\",\n \"ports\": {\n \"5432\": \"49153\"\n },\n \"network\": \"github_network_53269bd575974817b43f4733536b200c\"\n }\n }\n}\n```\n\n### Example usage of the `job` context\n\nThis example workflow configures a PostgreSQL service container, and automatically maps port 5432 in the service container to a randomly chosen available port on the host. The `job` context is used to access the number of the port that was assigned on the host.\n\n```yaml copy\nname: PostgreSQL Service Example\non: push\njobs:\n postgres-job:\n runs-on: ubuntu-latest\n services:\n postgres:\n image: postgres\n env:\n POSTGRES_PASSWORD: postgres\n options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5\n ports:\n # Maps TCP port 5432 in the service container to a randomly chosen available port on the host.\n - 5432\n\n steps:\n - run: pg_isready -h localhost -p ${{ job.services.postgres.ports[5432] }}\n - run: echo \"Run tests against Postgres\"\n```\n\n### Example usage of `job` context workflow identity\n\n> \\[!NOTE]\n> The `job.workflow_*` context properties are not available on GitHub Enterprise Server.\n\nThis example reusable workflow uses `job.workflow_repository` and `job.workflow_sha` to check out its own source code, rather than the caller's repository. This is useful when a reusable workflow needs to access files co-located with the workflow definition.\n\n```yaml copy\n# In a reusable workflow (e.g., octo-org/shared-workflows/.github/workflows/deploy.yml)\nname: Reusable deploy workflow\non:\n workflow_call:\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v6\n with:\n repository: ${{ job.workflow_repository }}\n ref: ${{ job.workflow_sha }}\n\n - run: echo \"Deploying from ${{ job.workflow_ref }}\"\n - run: echo \"Workflow file path is ${{ job.workflow_file_path }}\"\n```\n\n## `jobs` context\n\nThe `jobs` context is only available in reusable workflows, and can only be used to set outputs for a reusable workflow. For more information, see [Reuse workflows](/en/actions/using-workflows/reusing-workflows#using-outputs-from-a-reusable-workflow).\n\n| Property name | Type | Description |\n| ------------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `jobs` | `object` | This is only available in reusable workflows, and can only be used to set outputs for a reusable workflow. This object contains all the properties listed below. |\n| `jobs..result` | `string` | The result of a job in the reusable workflow. Possible values are `success`, `failure`, `cancelled`, or `skipped`. |\n| `jobs..outputs` | `object` | The set of outputs of a job in a reusable workflow. |\n| `jobs..outputs.` | `string` | The value of a specific output for a job in a reusable workflow. |\n\n### Example contents of the `jobs` context\n\nThis example `jobs` context contains the result and outputs of a job from a reusable workflow run.\n\n```json\n{\n \"example_job\": {\n \"result\": \"success\",\n \"outputs\": {\n \"output1\": \"hello\",\n \"output2\": \"world\"\n }\n }\n}\n```\n\n### Example usage of the `jobs` context\n\nThis example reusable workflow uses the `jobs` context to set outputs for the reusable workflow. Note how the outputs flow up from the steps, to the job, then to the `workflow_call` trigger. For more information, see [Reuse workflows](/en/actions/using-workflows/reusing-workflows#using-outputs-from-a-reusable-workflow).\n\n```yaml copy\nname: Reusable workflow\n\non:\n workflow_call:\n # Map the workflow outputs to job outputs\n outputs:\n firstword:\n description: \"The first output string\"\n value: ${{ jobs.example_job.outputs.output1 }}\n secondword:\n description: \"The second output string\"\n value: ${{ jobs.example_job.outputs.output2 }}\n\njobs:\n example_job:\n name: Generate output\n runs-on: ubuntu-latest\n # Map the job outputs to step outputs\n outputs:\n output1: ${{ steps.step1.outputs.firstword }}\n output2: ${{ steps.step2.outputs.secondword }}\n steps:\n - id: step1\n run: echo \"firstword=hello\" >> $GITHUB_OUTPUT\n - id: step2\n run: echo \"secondword=world\" >> $GITHUB_OUTPUT\n```\n\n## `steps` context\n\nThe `steps` context contains information about the steps in the current job that have an [`id`](/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsid) specified and have already run.\n\n| Property name | Type | Description |\n| --------------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `steps` | `object` | This context changes for each step in a job. You can access this context from any step in a job. This object contains all the properties listed below. |\n| `steps..outputs` | `object` | The set of outputs defined for the step. For more information, see [Metadata syntax reference](/en/actions/creating-actions/metadata-syntax-for-github-actions#outputs-for-docker-container-and-javascript-actions). |\n| `steps..conclusion` | `string` | The result of a completed step after [`continue-on-error`](/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error) is applied. Possible values are `success`, `failure`, `cancelled`, or `skipped`. When a `continue-on-error` step fails, the `outcome` is `failure`, but the final `conclusion` is `success`. |\n| `steps..outcome` | `string` | The result of a completed step before [`continue-on-error`](/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error) is applied. Possible values are `success`, `failure`, `cancelled`, or `skipped`. When a `continue-on-error` step fails, the `outcome` is `failure`, but the final `conclusion` is `success`. |\n| `steps..outputs.` | `string` | The value of a specific output. |\n\n### Example contents of the `steps` context\n\nThis example `steps` context shows two previous steps that had an [`id`](/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsid) specified. The first step had the `id` named `checkout`, the second `generate_number`. The `generate_number` step had an output named `random_number`.\n\n```json\n{\n \"checkout\": {\n \"outputs\": {},\n \"outcome\": \"success\",\n \"conclusion\": \"success\"\n },\n \"generate_number\": {\n \"outputs\": {\n \"random_number\": \"1\"\n },\n \"outcome\": \"success\",\n \"conclusion\": \"success\"\n }\n}\n```\n\n### Example usage of the `steps` context\n\nThis example workflow generates a random number as an output in one step, and a later step uses the `steps` context to read the value of that output.\n\n```yaml copy\nname: Generate random failure\non: push\njobs:\n randomly-failing-job:\n runs-on: ubuntu-latest\n steps:\n - name: Generate 0 or 1\n id: generate_number\n run: echo \"random_number=$(($RANDOM % 2))\" >> $GITHUB_OUTPUT\n - name: Pass or fail\n run: |\n if [[ ${{ steps.generate_number.outputs.random_number }} == 0 ]]; then exit 0; else exit 1; fi\n```\n\n## `runner` context\n\nThe `runner` context contains information about the runner that is executing the current job.\n\n| Property name | Type | Description |\n| -------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `runner` | `object` | This context changes for each job in a workflow run. This object contains all the properties listed below. |\n| `runner.name` | `string` | The name of the runner executing the job. This name may not be unique in a workflow run as runners at the repository and organization levels could use the same name. |\n| `runner.os` | `string` | The operating system of the runner executing the job. Possible values are `Linux`, `Windows`, or `macOS`. |\n| `runner.arch` | `string` | The architecture of the runner executing the job. Possible values are `X86`, `X64`, `ARM`, or `ARM64`. |\n| `runner.temp` | `string` | The path to a temporary directory on the runner. This directory is emptied at the beginning and end of each job. Note that files will not be removed if the runner's user account does not have permission to delete them. |\n| `runner.tool_cache` | `string` | The path to the directory containing preinstalled tools for GitHub-hosted runners. For more information, see [GitHub-hosted runners](/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software). |\n| `runner.debug` | `string` | This is set only if [debug logging](/en/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging) is enabled, and always has the value of `1`. It can be useful as an indicator to enable additional debugging or verbose logging in your own job steps. |\n| `runner.environment` | `string` | The environment of the runner executing the job. Possible values are: `github-hosted` for GitHub-hosted runners provided by GitHub, and `self-hosted` for self-hosted runners configured by the repository owner. |\n\n### Example contents of the `runner` context\n\nThe following example context is from a Linux GitHub-hosted runner.\n\n```json\n{\n \"os\": \"Linux\",\n \"arch\": \"X64\",\n \"name\": \"GitHub Actions 2\",\n \"tool_cache\": \"/opt/hostedtoolcache\",\n \"temp\": \"/home/runner/work/_temp\"\n}\n```\n\n### Example usage of the `runner` context\n\nThis example workflow uses the `runner` context to set the path to the temporary directory to write logs, and if the workflow fails, it uploads those logs as artifact.\n\n```yaml copy\nname: Build\non: push\n\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v6\n - name: Build with logs\n run: |\n mkdir ${{ runner.temp }}/build_logs\n echo \"Logs from building\" > ${{ runner.temp }}/build_logs/build.logs\n exit 1\n - name: Upload logs on fail\n if: ${{ failure() }}\n uses: actions/upload-artifact@v4\n with:\n name: Build failure logs\n path: ${{ runner.temp }}/build_logs\n```\n\n## `secrets` context\n\nThe `secrets` context contains the names and values of secrets that are available to a workflow run. The `secrets` context is not available for composite actions due to security reasons. If you want to pass a secret to a composite action, you need to do it explicitly as an input. For more information about secrets, see [Using secrets in GitHub Actions](/en/actions/security-guides/using-secrets-in-github-actions).\n\n`GITHUB_TOKEN` is a secret that is automatically created for every workflow run, and is always included in the `secrets` context. For more information, see [Use GITHUB\\_TOKEN for authentication in workflows](/en/actions/security-guides/automatic-token-authentication).\n\n> \\[!WARNING]\n> If a secret is used in a workflow job, GitHub automatically redacts secrets printed to the log. You should avoid printing secrets to the log intentionally.\n\n| Property name | Type | Description |\n| ----------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `secrets` | `object` | This context is the same for each job in a workflow run. You can access this context from any step in a job. This object contains all the properties listed below. |\n| `secrets.GITHUB_TOKEN` | `string` | Automatically created token for each workflow run. For more information, see [Use GITHUB\\_TOKEN for authentication in workflows](/en/actions/security-guides/automatic-token-authentication). |\n| `secrets.` | `string` | The value of a specific secret. |\n\n### Example contents of the `secrets` context\n\nThe following example contents of the `secrets` context shows the automatic `GITHUB_TOKEN`, as well as two other secrets available to the workflow run.\n\n```json\n{\n \"github_token\": \"***\",\n \"NPM_TOKEN\": \"***\",\n \"SUPERSECRET\": \"***\"\n}\n```\n\n### Example usage of the `secrets` context\n\nThis example workflow uses the [GitHub CLI](/en/actions/using-workflows/using-github-cli-in-workflows), which requires the `GITHUB_TOKEN` as the value for the `GH_TOKEN` input parameter:\n\n```yaml copy\nname: Open new issue\non: workflow_dispatch\n\njobs:\n open-issue:\n runs-on: ubuntu-latest\n permissions:\n contents: read\n issues: write\n steps:\n - run: |\n gh issue --repo ${{ github.repository }} \\\n create --title \"Issue title\" --body \"Issue body\"\n env:\n GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n```\n\n## `strategy` context\n\nFor workflows with a matrix, the `strategy` context contains information about the matrix execution strategy for the current job.\n\n| Property name | Type | Description |\n| ----------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `strategy` | `object` | This context changes for each job in a workflow run. You can access this context from any job or step in a workflow. This object contains all the properties listed below. |\n| `strategy.fail-fast` | `boolean` | When this evaluates to `true`, all in-progress jobs are canceled if any job in a matrix fails. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast). |\n| `strategy.job-index` | `number` | The index of the current job in the matrix. **Note:** This number is a zero-based number. The first job's index in the matrix is `0`. |\n| `strategy.job-total` | `number` | The total number of jobs in the matrix. **Note:** This number **is not** a zero-based number. For example, for a matrix with four jobs, the value of `job-total` is `4`. |\n| `strategy.max-parallel` | `number` | The maximum number of jobs that can run simultaneously when using a `matrix` job strategy. For more information, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategymax-parallel). |\n\n### Example contents of the `strategy` context\n\nThe following example contents of the `strategy` context is from a matrix with four jobs, and is taken from the final job. Note the difference between the zero-based `job-index` number, and `job-total` which is not zero-based.\n\n```json\n{\n \"fail-fast\": true,\n \"job-index\": 3,\n \"job-total\": 4,\n \"max-parallel\": 4\n}\n```\n\n### Example usage of the `strategy` context\n\nThis example workflow uses the `strategy.job-index` property to set a unique name for a log file for each job in a matrix.\n\n```yaml copy\nname: Test strategy\non: push\n\njobs:\n test:\n runs-on: ubuntu-latest\n strategy:\n matrix:\n test-group: [1, 2]\n node: [14, 16]\n steps:\n - run: echo \"Mock test logs\" > test-job-${{ strategy.job-index }}.txt\n - name: Upload logs\n uses: actions/upload-artifact@v4\n with:\n name: Build log for job ${{ strategy.job-index }}\n path: test-job-${{ strategy.job-index }}.txt\n```\n\n## `matrix` context\n\nFor workflows with a matrix, the `matrix` context contains the matrix properties defined in the workflow file that apply to the current job. For example, if you configure a matrix with the `os` and `node` keys, the `matrix` context object includes the `os` and `node` properties with the values that are being used for the current job.\n\nThere are no standard properties in the `matrix` context, only those which are defined in the workflow file.\n\n| Property name | Type | Description |\n| ------------------------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `matrix` | `object` | This context is only available for jobs in a matrix, and changes for each job in a workflow run. You can access this context from any job or step in a workflow. This object contains the properties listed below. |\n| `matrix.` | `string` | The value of a matrix property. |\n\n### Example contents of the `matrix` context\n\nThe following example contents of the `matrix` context is from a job in a matrix that has the `os` and `node` matrix properties defined in the workflow. The job is executing the matrix combination of an `ubuntu-latest` OS and Node.js version `16`.\n\n```json\n{\n \"os\": \"ubuntu-latest\",\n \"node\": 16\n}\n```\n\n### Example usage of the `matrix` context\n\nThis example workflow creates a matrix with `os` and `node` keys. It uses the `matrix.os` property to set the runner type for each job, and uses the `matrix.node` property to set the Node.js version for each job.\n\n```yaml copy\nname: Test matrix\non: push\n\njobs:\n build:\n runs-on: ${{ matrix.os }}\n strategy:\n matrix:\n os: [ubuntu-latest, windows-latest]\n node: [14, 16]\n steps:\n - uses: actions/setup-node@v4\n with:\n node-version: ${{ matrix.node }}\n - name: Output node version\n run: node --version\n```\n\n## `needs` context\n\nThe `needs` context contains outputs from all jobs that are defined as a direct dependency of the current job. Note that this doesn't include implicitly dependent jobs (for example, dependent jobs of a dependent job). For more information on defining job dependencies, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds).\n\n| Property name | Type | Description |\n| -------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `needs` | `object` | This context is only populated for workflow runs that have dependent jobs, and changes for each job in a workflow run. You can access this context from any job or step in a workflow. This object contains all the properties listed below. |\n| `needs.` | `object` | A single job that the current job depends on. |\n| `needs..outputs` | `object` | The set of outputs of a job that the current job depends on. |\n| `needs..outputs.` | `string` | The value of a specific output for a job that the current job depends on. |\n| `needs..result` | `string` | The result of a job that the current job depends on. Possible values are `success`, `failure`, `cancelled`, or `skipped`. |\n\n### Example contents of the `needs` context\n\nThe following example contents of the `needs` context shows information for two jobs that the current job depends on.\n\n```json\n{\n \"build\": {\n \"result\": \"success\",\n \"outputs\": {\n \"build_id\": \"123456\"\n }\n },\n \"deploy\": {\n \"result\": \"failure\",\n \"outputs\": {}\n }\n}\n```\n\n### Example usage of the `needs` context\n\nThis example workflow has three jobs: a `build` job that does a build, a `deploy` job that requires the `build` job, and a `debug` job that requires both the `build` and `deploy` jobs and runs only if there is a failure in the workflow. The `deploy` job also uses the `needs` context to access an output from the `build` job.\n\n```yaml copy\nname: Build and deploy\non: push\n\njobs:\n build:\n runs-on: ubuntu-latest\n outputs:\n build_id: ${{ steps.build_step.outputs.build_id }}\n steps:\n - name: Build\n id: build_step\n run: echo \"build_id=$RANDOM\" >> $GITHUB_OUTPUT\n deploy:\n needs: build\n runs-on: ubuntu-latest\n steps:\n - run: echo \"Deploying build ${{ needs.build.outputs.build_id }}\"\n debug:\n needs: [build, deploy]\n runs-on: ubuntu-latest\n if: ${{ failure() }}\n steps:\n - run: echo \"Failed to build and deploy\"\n```\n\n## `inputs` context\n\nThe `inputs` context contains input properties passed to an action, to a reusable workflow, or to a manually triggered workflow. For reusable workflows, the input names and types are defined in the [`workflow_call` event configuration](/en/actions/using-workflows/events-that-trigger-workflows#workflow-reuse-events) of a reusable workflow, and the input values are passed from [`jobs..with`](/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idwith) in an external workflow that calls the reusable workflow. For manually triggered workflows, the inputs are defined in the [`workflow_dispatch` event configuration](/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch) of a workflow.\n\nThe properties in the `inputs` context are defined in the workflow file. They are only available in a [reusable workflow](/en/actions/using-workflows/reusing-workflows) or in a workflow triggered by the [`workflow_dispatch` event](/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch)\n\n| Property name | Type | Description |\n| --------------- | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `inputs` | `object` | This context is only available in a [reusable workflow](/en/actions/using-workflows/reusing-workflows) or in a workflow triggered by the [`workflow_dispatch` event](/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch). You can access this context from any job or step in a workflow. This object contains the properties listed below. |\n| `inputs.` | `string` or `number` or `boolean` or `choice` | Each input value passed from an external workflow. |\n\n### Example contents of the `inputs` context\n\nThe following example contents of the `inputs` context is from a workflow that has defined the `build_id`, `deploy_target`, and `perform_deploy` inputs.\n\n```json\n{\n \"build_id\": 123456768,\n \"deploy_target\": \"deployment_sys_1a\",\n \"perform_deploy\": true\n}\n```\n\n### Example usage of the `inputs` context in a reusable workflow\n\nThis example reusable workflow uses the `inputs` context to get the values of the `build_id`, `deploy_target`, and `perform_deploy` inputs that were passed to the reusable workflow from the caller workflow.\n\n```yaml copy\nname: Reusable deploy workflow\non:\n workflow_call:\n inputs:\n build_id:\n required: true\n type: number\n deploy_target:\n required: true\n type: string\n perform_deploy:\n required: true\n type: boolean\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n if: ${{ inputs.perform_deploy }}\n steps:\n - name: Deploy build to target\n run: echo \"Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}\"\n```\n\n### Example usage of the `inputs` context in a manually triggered workflow\n\nThis example workflow triggered by a `workflow_dispatch` event uses the `inputs` context to get the values of the `build_id`, `deploy_target`, and `perform_deploy` inputs that were passed to the workflow.\n\n```yaml copy\non:\n workflow_dispatch:\n inputs:\n build_id:\n required: true\n type: string\n deploy_target:\n required: true\n type: string\n perform_deploy:\n required: true\n type: boolean\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n if: ${{ inputs.perform_deploy }}\n steps:\n - name: Deploy build to target\n run: echo \"Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}\"\n```\n\n## Further reading\n\n* [Contexts](/en/actions/concepts/workflows-and-actions/contexts)"}