Available contexts

As part of an expression, you can access context information using one of two syntaxes.

• Index syntax:github['sha']
• Property dereference syntax:github.sha

In order to use property dereference syntax, the property name must start with a letter or_ and contain only alphanumeric characters,-, or_.

If you attempt to dereference a nonexistent property, it will evaluate to an empty string.

Determining when to use contexts

GitHub Actions includes a collection of variables calledcontexts and a similar collection of variables calleddefault variables. These variables are intended for use at different points in the workflow:

• Default environment variables: These environment variables exist only on the runner that is executing your job. For more information, seeVariables reference.
• Contexts: You can use most contexts at any point in your workflow, including whendefault 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 conditionalif 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 asrunner.os. For details of where you can use various contexts within a workflow, seeContext availability.

The following example demonstrates how these different types of variables can be used together in a job:

name: CIon: pushjobs:  prod-check:    if: ${{ github.ref == 'refs/heads/main' }}    runs-on: ubuntu-latest    steps:      - run: echo "Deploying to production server on branch $GITHUB_REF"

name:CIon:pushjobs:prod-check:if:${{github.ref=='refs/heads/main'}}runs-on:ubuntu-lateststeps:-run:echo"Deploying to production server on branch $GITHUB_REF"

In this example, theif statement checks thegithub.ref context to determine the current branch name; if the name isrefs/heads/main, then the subsequent steps are executed. Theif check is processed by GitHub Actions, and the job is only sent to the runner if the result istrue. Once the job is sent to the runner, the step is executed and refers to the$GITHUB_REF variable from the runner.

Context availability

Different contexts are available throughout a workflow run. For example, thesecrets context may only be used at certain places within a job.

In addition, some functions may only be used in certain places. For example, thehashFiles function is not available everywhere.

The 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.

Example: printing context information to the log

You can print the contents of contexts to the log for debugging. ThetoJSON function is required to pretty-print JSON objects to the log.

name: Context testingon: pushjobs:  dump_contexts_to_log:    runs-on: ubuntu-latest    steps:      - name: Dump GitHub context        env:          GITHUB_CONTEXT: ${{ toJson(github) }}        run: echo "$GITHUB_CONTEXT"      - name: Dump job context        env:          JOB_CONTEXT: ${{ toJson(job) }}        run: echo "$JOB_CONTEXT"      - name: Dump steps context        env:          STEPS_CONTEXT: ${{ toJson(steps) }}        run: echo "$STEPS_CONTEXT"      - name: Dump runner context        env:          RUNNER_CONTEXT: ${{ toJson(runner) }}        run: echo "$RUNNER_CONTEXT"      - name: Dump strategy context        env:          STRATEGY_CONTEXT: ${{ toJson(strategy) }}        run: echo "$STRATEGY_CONTEXT"      - name: Dump matrix context        env:          MATRIX_CONTEXT: ${{ toJson(matrix) }}        run: echo "$MATRIX_CONTEXT"

name:Contexttestingon:pushjobs:dump_contexts_to_log:runs-on:ubuntu-lateststeps:-name:DumpGitHubcontextenv:GITHUB_CONTEXT:${{toJson(github)}}run:echo"$GITHUB_CONTEXT"-name:Dumpjobcontextenv:JOB_CONTEXT:${{toJson(job)}}run:echo"$JOB_CONTEXT"-name:Dumpstepscontextenv:STEPS_CONTEXT:${{toJson(steps)}}run:echo"$STEPS_CONTEXT"-name:Dumprunnercontextenv:RUNNER_CONTEXT:${{toJson(runner)}}run:echo"$RUNNER_CONTEXT"-name:Dumpstrategycontextenv:STRATEGY_CONTEXT:${{toJson(strategy)}}run:echo"$STRATEGY_CONTEXT"-name:Dumpmatrixcontextenv:MATRIX_CONTEXT:${{toJson(matrix)}}run:echo"$MATRIX_CONTEXT"

github context

Thegithub context contains information about the workflow run and the event that triggered the run. You can read most of thegithub context data in environment variables. For more information about environment variables, seeStore information in variables.

Example contents of thegithub context

The following example context is from a workflow run triggered by thepush event. Theevent object in this example has been truncated because it is identical to the contents of thepush webhook payload.

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

Example usage of thegithub context

This example workflow uses thegithub.event_name context to run a job only if the workflow run was triggered by thepull_request event.

name: Run CIon: [push, pull_request]jobs:  normal_ci:    runs-on: ubuntu-latest    steps:      - name: Run normal CI        run: echo "Running normal CI"  pull_request_ci:    runs-on: ubuntu-latest    if: ${{ github.event_name == 'pull_request' }}    steps:      - name: Run PR CI        run: echo "Running PR only CI"

name:RunCIon: [push,pull_request]jobs:normal_ci:runs-on:ubuntu-lateststeps:-name:RunnormalCIrun:echo"Running normal CI"pull_request_ci:runs-on:ubuntu-latestif:${{github.event_name=='pull_request'}}steps:-name:RunPRCIrun:echo"Running PR only CI"

env context

Theenv 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, seeWorkflow syntax for GitHub Actions.

You can retrieve the values of variables stored inenv context and use these values in your workflow file. You can use theenv context in any key in a workflow step except for theid anduses keys. For more information on the step syntax, seeWorkflow syntax for GitHub Actions.

If you want to use the value of a variable inside a runner, use the runner operating system's normal method for reading environment variables.

Example contents of theenv context

The contents of theenv 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, theenv context contains two variables.

{"first_name":"Mona","super_duper_var":"totally_awesome"}

Example usage of theenv context

This example workflow shows variables being set in theenv 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.

When 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.

name: Hi Mascoton: pushenv:  mascot: Mona  super_duper_var: totally_awesomejobs:  windows_job:    runs-on: windows-latest    steps:      - run: echo 'Hi ${{ env.mascot }}'  # Hi Mona      - run: echo 'Hi ${{ env.mascot }}'  # Hi Octocat        env:          mascot: Octocat  linux_job:    runs-on: ubuntu-latest    env:      mascot: Tux    steps:      - run: echo 'Hi ${{ env.mascot }}'  # Hi Tux

name:HiMascoton:pushenv:mascot:Monasuper_duper_var:totally_awesomejobs:windows_job:runs-on:windows-lateststeps:-run:echo'Hi ${{ env.mascot }}'# Hi Mona-run:echo'Hi ${{ env.mascot }}'# Hi Octocatenv:mascot:Octocatlinux_job:runs-on:ubuntu-latestenv:mascot:Tuxsteps:-run:echo'Hi ${{ env.mascot }}'# Hi Tux

vars context

Thevars 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, seeStore information in variables.

Example contents of thevars context

The contents of thevars context is a mapping of configuration variable names to their values.

{"mascot":"Mona"}

Example usage of thevars context

This example workflow shows how configuration variables set at the repository, environment, or organization levels are automatically available using thevars context.

If a configuration variable has not been set, the return value of a context referencing the variable will be an empty string.

The following example shows using configuration variables with thevars context across a workflow. Each of the following configuration variables have been defined at the repository, organization, or environment levels.

on:  workflow_dispatch:env:  # Setting an environment variable with the value of a configuration variable  env_var: ${{ vars.ENV_CONTEXT_VAR }}jobs:  display-variables:    name: ${{ vars.JOB_NAME }}    # You can use configuration variables with the `vars` context for dynamic jobs    if: ${{ vars.USE_VARIABLES == 'true' }}    runs-on: ${{ vars.RUNNER }}    environment: ${{ vars.ENVIRONMENT_STAGE }}    steps:    - name: Use variables      run: |        echo "repository variable : $REPOSITORY_VAR"        echo "organization variable : $ORGANIZATION_VAR"        echo "overridden variable : $OVERRIDE_VAR"        echo "variable from shell environment : $env_var"      env:        REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }}        ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }}        OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }}            - name: ${{ vars.HELLO_WORLD_STEP }}      if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }}      uses: actions/hello-world-javascript-action@main      with:        who-to-greet: ${{ vars.GREET_NAME }}

on:workflow_dispatch:env:# Setting an environment variable with the value of a configuration variableenv_var:${{vars.ENV_CONTEXT_VAR}}jobs:display-variables:name:${{vars.JOB_NAME}}# You can use configuration variables with the `vars` context for dynamic jobsif:${{vars.USE_VARIABLES=='true'}}runs-on:${{vars.RUNNER}}environment:${{vars.ENVIRONMENT_STAGE}}steps:-name:Usevariablesrun:|        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@mainwith:who-to-greet:${{vars.GREET_NAME}}

job context

Thejob context contains information about the currently running job.

Example contents of thejob context

This examplejob context uses a PostgreSQL service container with mapped ports. If there are no containers or service containers used in a job, thejob context only contains thestatus property.

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

Example usage of thejob context

This 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. Thejob context is used to access the number of the port that was assigned on the host.

name: PostgreSQL Service Exampleon: pushjobs:  postgres-job:    runs-on: ubuntu-latest    services:      postgres:        image: postgres        env:          POSTGRES_PASSWORD: postgres        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5        ports:          # Maps TCP port 5432 in the service container to a randomly chosen available port on the host.          - 5432    steps:      - run: pg_isready -h localhost -p ${{ job.services.postgres.ports[5432] }}      - run: echo "Run tests against Postgres"

name:PostgreSQLServiceExampleon:pushjobs:postgres-job:runs-on:ubuntu-latestservices:postgres:image:postgresenv:POSTGRES_PASSWORD:postgresoptions:--health-cmdpg_isready--health-interval10s--health-timeout5s--health-retries5ports:# Maps TCP port 5432 in the service container to a randomly chosen available port on the host.-5432steps:-run:pg_isready-hlocalhost-p${{job.services.postgres.ports[5432]}}-run:echo"Run tests against Postgres"

jobs context

Thejobs context is only available in reusable workflows, and can only be used to set outputs for a reusable workflow. For more information, seeReuse workflows.

Example contents of thejobs context

This examplejobs context contains the result and outputs of a job from a reusable workflow run.

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

Example usage of thejobs context

This example reusable workflow uses thejobs context to set outputs for the reusable workflow. Note how the outputs flow up from the steps, to the job, then to theworkflow_call trigger. For more information, seeReuse workflows.

name: Reusable workflowon:  workflow_call:    # Map the workflow outputs to job outputs    outputs:      firstword:        description: "The first output string"        value: ${{ jobs.example_job.outputs.output1 }}      secondword:        description: "The second output string"        value: ${{ jobs.example_job.outputs.output2 }}jobs:  example_job:    name: Generate output    runs-on: ubuntu-latest    # Map the job outputs to step outputs    outputs:      output1: ${{ steps.step1.outputs.firstword }}      output2: ${{ steps.step2.outputs.secondword }}    steps:      - id: step1        run: echo "firstword=hello" >> $GITHUB_OUTPUT      - id: step2        run: echo "secondword=world" >> $GITHUB_OUTPUT

name:Reusableworkflowon:workflow_call:# Map the workflow outputs to job outputsoutputs: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:Generateoutputruns-on:ubuntu-latest# Map the job outputs to step outputsoutputs:output1:${{steps.step1.outputs.firstword}}output2:${{steps.step2.outputs.secondword}}steps:-id:step1run:echo"firstword=hello">>$GITHUB_OUTPUT-id:step2run:echo"secondword=world">>$GITHUB_OUTPUT

steps context

Thesteps context contains information about the steps in the current job that have anid specified and have already run.

Example contents of thesteps context

This examplesteps context shows two previous steps that had anid specified. The first step had theid namedcheckout, the secondgenerate_number. Thegenerate_number step had an output namedrandom_number.

{"checkout":{"outputs":{},"outcome":"success","conclusion":"success"},"generate_number":{"outputs":{"random_number":"1"},"outcome":"success","conclusion":"success"}}

Example usage of thesteps context

This example workflow generates a random number as an output in one step, and a later step uses thesteps context to read the value of that output.

name: Generate random failureon: pushjobs:  randomly-failing-job:    runs-on: ubuntu-latest    steps:      - name: Generate 0 or 1        id: generate_number        run: echo "random_number=$(($RANDOM % 2))" >> $GITHUB_OUTPUT      - name: Pass or fail        run: |          if [[ ${{ steps.generate_number.outputs.random_number }} == 0 ]]; then exit 0; else exit 1; fi

name:Generaterandomfailureon:pushjobs:randomly-failing-job:runs-on:ubuntu-lateststeps:-name:Generate0or1id:generate_numberrun:echo"random_number=$(($RANDOM % 2))">>$GITHUB_OUTPUT-name:Passorfailrun:|          if [[ ${{ steps.generate_number.outputs.random_number }} == 0 ]]; then exit 0; else exit 1; fi

runner context

Therunner context contains information about the runner that is executing the current job.

Example contents of therunner context

The following example context is from a Linux GitHub-hosted runner.

{"os":"Linux","arch":"X64","name":"GitHub Actions 2","tool_cache":"/opt/hostedtoolcache","temp":"/home/runner/work/_temp"}

Example usage of therunner context

This example workflow uses therunner context to set the path to the temporary directory to write logs, and if the workflow fails, it uploads those logs as artifact.

name: Buildon: pushjobs:  build:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - name: Build with logs        run: |          mkdir ${{ runner.temp }}/build_logs          echo "Logs from building" > ${{ runner.temp }}/build_logs/build.logs          exit 1      - name: Upload logs on fail        if: ${{ failure() }}        uses: actions/upload-artifact@v4        with:          name: Build failure logs          path: ${{ runner.temp }}/build_logs

name:Buildon:pushjobs:build:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-name:Buildwithlogsrun:|          mkdir ${{ runner.temp }}/build_logs          echo "Logs from building" > ${{ runner.temp }}/build_logs/build.logs          exit 1-name:Uploadlogsonfailif:${{failure()}}uses:actions/upload-artifact@v4with:name:Buildfailurelogspath:${{runner.temp}}/build_logs

secrets context

Thesecrets context contains the names and values of secrets that are available to a workflow run. Thesecrets 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, seeUsing secrets in GitHub Actions.

GITHUB_TOKEN is a secret that is automatically created for every workflow run, and is always included in thesecrets context. For more information, seeUse GITHUB_TOKEN in workflows.

Example contents of thesecrets context

The following example contents of thesecrets context shows the automaticGITHUB_TOKEN, as well as two other secrets available to the workflow run.

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

Example usage of thesecrets context

This example workflow uses theGitHub CLI, which requires theGITHUB_TOKEN as the value for theGH_TOKEN input parameter:

name: Open new issueon: workflow_dispatchjobs:  open-issue:    runs-on: ubuntu-latest    permissions:      contents: read      issues: write    steps:      - run: |          gh issue --repo ${{ github.repository }} \            create --title "Issue title" --body "Issue body"        env:          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

name:Opennewissueon:workflow_dispatchjobs:open-issue:runs-on:ubuntu-latestpermissions:contents:readissues:writesteps:-run:|          gh issue --repo ${{ github.repository }} \            create --title "Issue title" --body "Issue body"env:GH_TOKEN:${{secrets.GITHUB_TOKEN}}

strategy context

For workflows with a matrix, thestrategy context contains information about the matrix execution strategy for the current job.

Example contents of thestrategy context

The following example contents of thestrategy context is from a matrix with four jobs, and is taken from the final job. Note the difference between the zero-basedjob-index number, andjob-total which is not zero-based.

{"fail-fast":true,"job-index":3,"job-total":4,"max-parallel":4}

Example usage of thestrategy context

This example workflow uses thestrategy.job-index property to set a unique name for a log file for each job in a matrix.

name: Test strategyon: pushjobs:  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

name:Teststrategyon:pushjobs:test:runs-on:ubuntu-lateststrategy:matrix:test-group: [1,2]node: [14,16]steps:-run:echo"Mock test logs">test-job-${{strategy.job-index}}.txt-name:Uploadlogsuses:actions/upload-artifact@v4with:name:Buildlogforjob${{strategy.job-index}}path:test-job-${{strategy.job-index}}.txt

matrix context

For workflows with a matrix, thematrix context contains the matrix properties defined in the workflow file that apply to the current job. For example, if you configure a matrix with theos andnode keys, thematrix context object includes theos andnode properties with the values that are being used for the current job.

There are no standard properties in thematrix context, only those which are defined in the workflow file.

Example contents of thematrix context

The following example contents of thematrix context is from a job in a matrix that has theos andnode matrix properties defined in the workflow. The job is executing the matrix combination of anubuntu-latest OS and Node.js version16.

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

Example usage of thematrix context

This example workflow creates a matrix withos andnode keys. It uses thematrix.os property to set the runner type for each job, and uses thematrix.node property to set the Node.js version for each job.

name: Test matrixon: pushjobs:  build:    runs-on: ${{ matrix.os }}    strategy:      matrix:        os: [ubuntu-latest, windows-latest]        node: [14, 16]    steps:      - uses: actions/setup-node@v4        with:          node-version: ${{ matrix.node }}      - name: Output node version        run: node --version

name:Testmatrixon:pushjobs:build:runs-on:${{matrix.os}}strategy:matrix:os: [ubuntu-latest,windows-latest]node: [14,16]steps:-uses:actions/setup-node@v4with:node-version:${{matrix.node}}-name:Outputnodeversionrun:node--version

needs context

Theneeds 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, seeWorkflow syntax for GitHub Actions.

Example contents of theneeds context

The following example contents of theneeds context shows information for two jobs that the current job depends on.

{"build":{"result":"success","outputs":{"build_id":"123456"}},"deploy":{"result":"failure","outputs":{}}}

Example usage of theneeds context

This example workflow has three jobs: abuild job that does a build, adeploy job that requires thebuild job, and adebug job that requires both thebuild anddeploy jobs and runs only if there is a failure in the workflow. Thedeploy job also uses theneeds context to access an output from thebuild job.

name: Build and deployon: pushjobs:  build:    runs-on: ubuntu-latest    outputs:      build_id: ${{ steps.build_step.outputs.build_id }}    steps:      - name: Build        id: build_step        run: echo "build_id=$RANDOM" >> $GITHUB_OUTPUT  deploy:    needs: build    runs-on: ubuntu-latest    steps:      - run: echo "Deploying build ${{ needs.build.outputs.build_id }}"  debug:    needs: [build, deploy]    runs-on: ubuntu-latest    if: ${{ failure() }}    steps:      - run: echo "Failed to build and deploy"

name:Buildanddeployon:pushjobs:build:runs-on:ubuntu-latestoutputs:build_id:${{steps.build_step.outputs.build_id}}steps:-name:Buildid:build_steprun:echo"build_id=$RANDOM">>$GITHUB_OUTPUTdeploy:needs:buildruns-on:ubuntu-lateststeps:-run:echo"Deploying build ${{ needs.build.outputs.build_id }}"debug:needs: [build,deploy]runs-on:ubuntu-latestif:${{failure()}}steps:-run:echo"Failed to build and deploy"

inputs context

Theinputs 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 theworkflow_call event configuration of a reusable workflow, and the input values are passed fromjobs.<job_id>.with in an external workflow that calls the reusable workflow. For manually triggered workflows, the inputs are defined in theworkflow_dispatch event configuration of a workflow.

The properties in theinputs context are defined in the workflow file. They are only available in areusable workflow or in a workflow triggered by theworkflow_dispatch event

Example contents of theinputs context

The following example contents of theinputs context is from a workflow that has defined thebuild_id,deploy_target, andperform_deploy inputs.

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

Example usage of theinputs context in a reusable workflow

This example reusable workflow uses theinputs context to get the values of thebuild_id,deploy_target, andperform_deploy inputs that were passed to the reusable workflow from the caller workflow.

name: Reusable deploy workflowon:  workflow_call:    inputs:      build_id:        required: true        type: number      deploy_target:        required: true        type: string      perform_deploy:        required: true        type: booleanjobs:  deploy:    runs-on: ubuntu-latest    if: ${{ inputs.perform_deploy }}    steps:      - name: Deploy build to target        run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"

name:Reusabledeployworkflowon:workflow_call:inputs:build_id:required:truetype:numberdeploy_target:required:truetype:stringperform_deploy:required:truetype:booleanjobs:deploy:runs-on:ubuntu-latestif:${{inputs.perform_deploy}}steps:-name:Deploybuildtotargetrun:echo"Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"

Example usage of theinputs context in a manually triggered workflow

This example workflow triggered by aworkflow_dispatch event uses theinputs context to get the values of thebuild_id,deploy_target, andperform_deploy inputs that were passed to the workflow.

on:  workflow_dispatch:    inputs:      build_id:        required: true        type: string      deploy_target:        required: true        type: string      perform_deploy:        required: true        type: booleanjobs:  deploy:    runs-on: ubuntu-latest    if: ${{ inputs.perform_deploy }}    steps:      - name: Deploy build to target        run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"

on:workflow_dispatch:inputs:build_id:required:truetype:stringdeploy_target:required:truetype:stringperform_deploy:required:truetype:booleanjobs:deploy:runs-on:ubuntu-latestif:${{inputs.perform_deploy}}steps:-name:Deploybuildtotargetrun:echo"Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"

Further reading

• Contexts