Skip to main content

Accessing contextual information about workflow runs

You can access context information in workflows and actions.

About contexts

컨텍스트는 워크플로 실행, 변수, 실행기 환경, 작업 및 단계에 대한 정보에 액세스하는 방법입니다. Each context is an object that contains properties, which can be strings or other objects.

컨텍스트, 개체 및 속성은 워크플로 실행 조건마다 크게 달라집니다. For example, the matrix context is only populated for jobs in a matrix.

You can access contexts using the expression syntax. For more information, see "Evaluate expressions in workflows and actions."

${{ <context> }}

경고: 워크플로 및 작업을 만들 때 코드가 가능한 공격자의 신뢰할 수 없는 입력을 실행할 수 있는지 항상 고려해야 합니다. 공격자가 자신의 악성 콘텐츠를 삽입할 수 있으므로 특정 컨텍스트는 신뢰할 수 없는 입력으로 처리되어야 합니다. 자세한 내용은 "GitHub Actions에 대한 보안 강화"을(를) 참조하세요.

Context nameTypeDescription
githubobjectInformation about the workflow run. For more information, see github context.
envobjectContains variables set in a workflow, job, or step. For more information, see env context.
varsobjectContains variables set at the repository, organization, or environment levels. For more information, see vars context.
jobobjectInformation about the currently running job. For more information, see job context.
jobsobjectFor reusable workflows only, contains outputs of jobs from the reusable workflow. For more information, see jobs context.
stepsobjectInformation about the steps that have been run in the current job. For more information, see steps context.
runnerobjectInformation about the runner that is running the current job. For more information, see runner context.
secretsobjectContains the names and values of secrets that are available to a workflow run. For more information, see secrets context.
strategyobjectInformation about the matrix execution strategy for the current job. For more information, see strategy context.
matrixobjectContains the matrix properties defined in the workflow that apply to the current job. For more information, see matrix context.
needsobjectContains the outputs of all jobs that are defined as a dependency of the current job. For more information, see needs context.
inputsobjectContains the inputs of a reusable or manually triggered workflow. For more information, see inputs context.

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 called contexts and a similar collection of variables called default 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, see "Store information in variables."
  • 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."

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

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"

In this example, the if statement checks the github.ref 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 variable from the runner.

Context availability

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

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

The following table indicates where each context and special function can be used within a workflow. Unless listed below, a function can be used anywhere.

Workflow keyContextSpecial functions
run-namegithub, inputs, varsNone
concurrencygithub, inputs, varsNone
envgithub, secrets, inputs, varsNone
jobs.<job_id>.concurrencygithub, needs, strategy, matrix, inputs, varsNone
jobs.<job_id>.containergithub, needs, strategy, matrix, vars, inputsNone
jobs.<job_id>.container.credentialsgithub, needs, strategy, matrix, env, vars, secrets, inputsNone
jobs.<job_id>.container.env.<env_id>github, needs, strategy, matrix, job, runner, env, vars, secrets, inputsNone
jobs.<job_id>.container.imagegithub, needs, strategy, matrix, vars, inputsNone
jobs.<job_id>.continue-on-errorgithub, needs, strategy, vars, matrix, inputsNone
jobs.<job_id>.defaults.rungithub, needs, strategy, matrix, env, vars, inputsNone
jobs.<job_id>.envgithub, needs, strategy, matrix, vars, secrets, inputsNone
jobs.<job_id>.environmentgithub, needs, strategy, matrix, vars, inputsNone
jobs.<job_id>.environment.urlgithub, needs, strategy, matrix, job, runner, env, vars, steps, inputsNone
jobs.<job_id>.ifgithub, needs, vars, inputsalways, cancelled, success, failure
jobs.<job_id>.namegithub, needs, strategy, matrix, vars, inputsNone
jobs.<job_id>.outputs.<output_id>github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputsNone
jobs.<job_id>.runs-ongithub, needs, strategy, matrix, vars, inputsNone
jobs.<job_id>.secrets.<secrets_id>github, needs, strategy, matrix, secrets, inputs, varsNone
jobs.<job_id>.servicesgithub, needs, strategy, matrix, vars, inputsNone
jobs.<job_id>.services.<service_id>.credentialsgithub, needs, strategy, matrix, env, vars, secrets, inputsNone
jobs.<job_id>.services.<service_id>.env.<env_id>github, needs, strategy, matrix, job, runner, env, vars, secrets, inputsNone
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, inputsNone
jobs.<job_id>.timeout-minutesgithub, needs, strategy, matrix, vars, inputsNone
jobs.<job_id>.with.<with_id>github, needs, strategy, matrix, inputs, varsNone
on.workflow_call.inputs.<inputs_id>.defaultgithub, inputs, varsNone
on.workflow_call.outputs.<output_id>.valuegithub, jobs, vars, inputsNone

Example: printing context information to the log

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

경고: 전체 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 context

The github context contains information about the workflow run and the event that triggered the run. You can also read most of the github context data in environment variables. For more information about environment variables, see "Store information in variables."

경고: 전체 github 컨텍스트를 사용할 때는 중요한 정보(예: github.token)가 포함된다는 점을 염두에 두어야 합니다. GitHub은(는) 비밀을 콘솔에 인쇄할 때 마스킹하지만 컨텍스트를 내보내거나 인쇄할 때는 주의해야 합니다.

경고: 워크플로 및 작업을 만들 때 코드가 가능한 공격자의 신뢰할 수 없는 입력을 실행할 수 있는지 항상 고려해야 합니다. 공격자가 자신의 악성 콘텐츠를 삽입할 수 있으므로 특정 컨텍스트는 신뢰할 수 없는 입력으로 처리되어야 합니다. 자세한 내용은 "GitHub Actions에 대한 보안 강화"을(를) 참조하세요.

Property nameTypeDescription
githubobjectThe top-level context available during any job or step in a workflow. This object contains all the properties listed below.
github.actionstringThe name of the action currently running, or the id 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.
github.action_pathstringThe 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: cd ${{ github.action_path }} .
github.action_refstringFor a step executing an action, this is the ref of the action being executed. For example, v2.

run 키워드를 사용하지 마세요. 이 컨텍스트를 복합 작업에서 작동하도록 하려면 복합 작업의 env 컨텍스트 내에서 참조합니다.
github.action_repositorystringFor a step executing an action, this is the owner and repository name of the action. For example, actions/checkout.

run 키워드를 사용하지 마세요. 이 컨텍스트를 복합 작업에서 작동하도록 하려면 복합 작업의 env 컨텍스트 내에서 참조합니다.
github.action_statusstringFor a composite action, the current result of the composite action.
github.actorstringThe 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.
github.actor_idstring최초로 워크플로 실행을 트리거한 사용자 또는 앱의 계정 ID입니다. 예들 들어 1234567입니다. 행위자 사용자 이름과는 다릅니다.
github.api_urlstringThe URL of the GitHub REST API.
github.base_refstringThe 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.
github.envstringPath 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 "GitHub Actions에 대한 워크플로 명령."
github.eventobjectThe 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 "워크플로를 트리거하는 이벤트." For example, for a workflow run triggered by the push event, this object contains the contents of the push webhook payload.
github.event_namestringThe name of the event that triggered the workflow run.
github.event_pathstringThe path to the file on the runner that contains the full event webhook payload.
github.graphql_urlstringThe URL of the GitHub GraphQL API.
github.head_refstringThe 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.
github.jobstringThe job_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.
github.pathstringPath 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 "GitHub Actions에 대한 워크플로 명령."
github.refstring워크플로 실행을 트리거한 분기 또는 태그의 완전한 형식 참조 입니다. push에 의해 트리거된 워크플로의 경우 푸시된 분기 또는 태그 참조입니다. pull_request에 의해 트리거된 워크플로의 경우 끌어오기 요청 병합 분기입니다. release에 의해 트리거된 워크플로의 경우 생성된 릴리스 태그입니다. 다른 트리거의 경우 워크플로 실행을 트리거한 분기 또는 태그 참조입니다. 이벤트 유형에 대해 분기 또는 태그를 사용할 수 있는 경우에만 설정됩니다. 지정된 참조는 완전한 형식을 가집니다. 즉, 분기의 경우 refs/heads/<branch_name>, 끌어오기 요청의 경우 refs/pull/<pr_number>/merge, 태그의 경우 refs/tags/<tag_name> 형식을 따릅니다. 예들 들어 refs/heads/feature-branch-1입니다.
github.ref_namestring워크플로 실행을 트리거한 분기 또는 태그입니다. 해당 값은 GitHub에 표시된 분기 또는 태그 이름과 일치합니다. 예들 들어 feature-branch-1입니다.

끌어오기 요청의 경우 형식은 <pr_number>/merge입니다.
github.ref_protectedboolean분기 보호가 또는 규칙 집합이 워크플로 실행을 트리거한 ref에 대해 구성된 경우 true입니다.
github.ref_typestring워크플로 실행을 트리거한 ref의 형식입니다. 유효한 값은 branch 또는 tag입니다.
github.repositorystringThe owner and repository name. For example, octocat/Hello-World.
github.repository_idstring리포지토리 ID. 예들 들어 123456789입니다. 리포지토리 이름과는 다릅니다.
github.repository_ownerstringThe repository owner's username. For example, octocat.
github.repository_owner_idstring리포지토리 소유자 계정 ID. 예들 들어 1234567입니다. 소유자의 이름과는 다른 값입니다.
github.repositoryUrlstringThe Git URL to the repository. For example, git://github.com/octocat/hello-world.git.
github.retention_daysstringThe number of days that workflow run logs and artifacts are kept.
github.run_idstring리포지토리 내에서 실행되는 각 워크플로의 고유한 숫자입니다. 워크플로 실행을 다시 실행하는 경우 이 숫자는 변경되지 않습니다.
github.run_numberstring리포지토리에 있는 특정 워크플로의 실행마다 고유한 숫자입니다. 이 숫자는 워크플로의 첫 실행 시 1부터 시작하며 새 실행마다 증가합니다. 워크플로 실행을 다시 실행하는 경우 이 숫자는 변경되지 않습니다.
github.run_attemptstringA 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.
github.secret_sourcestringThe source of a secret used in a workflow. Possible values are None, Actions, Codespaces, or Dependabot.
github.server_urlstringThe URL of the GitHub server. For example: https://github.com.
github.shastring워크플로를 트리거한 커밋 SHA입니다. 이 커밋 SHA의 값은 워크플로를 트리거한 이벤트에 따라 달라집니다. 자세한 내용은 "워크플로를 트리거하는 이벤트"을(를) 참조하세요. 예들 들어 ffac537e6cbbf934b08745a378932722df287a53입니다.
github.tokenstringA 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 "자동 토큰 인증."
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.
github.triggering_actorstring워크플로 실행을 시작한 사용자의 사용자 이름입니다. 워크플로 실행이 다시 실행인 경우 이 값은 github.actor와 다를 수 있습니다. 다시 실행을 시작하는 행위자(github.triggering_actor)가 다른 권한을 갖고 있더라도 모든 워크플로 다시 실행은 github.actor의 권한을 사용합니다.
github.workflowstringThe 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.
github.workflow_refstring워크플로의 참조 경로입니다. 예들 들어 octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch입니다.
github.workflow_shastring워크플로 파일의 커밋 SHA입니다.
github.workspacestringThe default working directory on the runner for steps, and the default location of your repository when using the checkout action.

Example contents of the github context

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

참고: 이 컨텍스트는 예제일 뿐입니다. 컨텍스트의 내용은 실행 중인 워크플로에 따라 달라집니다. 컨텍스트, 개체 및 속성은 워크플로 실행 조건마다 크게 달라집니다.

{
  "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 the github context

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

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 context

The 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 "GitHub Actions에 대한 워크플로 구문."

You 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 "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.

Property nameTypeDescription
envobjectThis 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.
env.<env_name>stringThe value of a specific environment variable.

Example contents of the env context

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

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

Example usage of the env context

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

둘 이상의 변수가 동일한 이름으로 정의되면 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 context

참고: GitHub Actions에 대한 구성 변수는 beta 버전이며 변경될 수 있습니다.

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

Example contents of the vars context

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

{
  "mascot": "Mona"
}

Example usage of the vars context

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

Note: Configuration variables at the environment level are automatically available after their environment is declared by the runner.

구성 변수가 설정되지 않은 경우, 변수를 참조하는 컨텍스트는 빈 문자열을 반환합니다.

다음 예제는 워크플로 전체에서 vars 컨텍스트와 함께 구성 변수를 사용하는 방법을 나타냅니다. 다음 각각의 구성 변수는 리포지토리, 조직 또는 환경 수준에서 정의되었습니다.

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 context

The job context contains information about the currently running job.

Property nameTypeDescription
jobobjectThis 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.
job.containerobjectInformation about the job's container. For more information about containers, see "GitHub Actions에 대한 워크플로 구문."
job.container.idstringThe ID of the container.
job.container.networkstringThe ID of the container network. The runner creates the network used by all containers in a job.
job.servicesobjectThe service containers created for a job. For more information about service containers, see "GitHub Actions에 대한 워크플로 구문."
job.services.<service_id>.idstringThe ID of the service container.
job.services.<service_id>.networkstringThe ID of the service container network. The runner creates the network used by all containers in a job.
job.services.<service_id>.portsobjectThe exposed ports of the service container.
job.statusstringThe current status of the job. Possible values are success, failure, or cancelled.

Example contents of the job context

This 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 the status property.

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

Example usage of the job 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. The job context is used to access the number of the port that was assigned on the host.

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 context

The jobs context is only available in reusable workflows, and can only be used to set outputs for a reusable workflow. For more information, see "워크플로 다시 사용."

Property nameTypeDescription
jobsobjectThis 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.
jobs.<job_id>.resultstringThe result of a job in the reusable workflow. Possible values are success, failure, cancelled, or skipped.
jobs.<job_id>.outputsobjectThe set of outputs of a job in a reusable workflow.
jobs.<job_id>.outputs.<output_name>stringThe value of a specific output for a job in a reusable workflow.

Example contents of the jobs context

This example jobs 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 the jobs context

This 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 "워크플로 다시 사용."

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 context

The steps context contains information about the steps in the current job that have an id specified and have already run.

Property nameTypeDescription
stepsobjectThis 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.
steps.<step_id>.outputsobjectThe set of outputs defined for the step. For more information, see "GitHub Actions에 대한 메타데이터 구문."
steps.<step_id>.conclusionstringThe result of a completed step after continue-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.
steps.<step_id>.outcomestringThe result of a completed step before continue-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.
steps.<step_id>.outputs.<output_name>stringThe value of a specific output.

Example contents of the steps context

This example steps context shows two previous steps that had an id specified. The first step had the id named checkout, the second generate_number. The generate_number step had an output named random_number.

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

Example usage of the steps context

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

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 context

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

Property nameTypeDescription
runnerobjectThis context changes for each job in a workflow run. This object contains all the properties listed below.
runner.namestring작업을 실행하는 실행기의 이름입니다. 실행기 이름은 리포지토리의 실행기로 워크플로 실행 시 고유하지 않을 수 있으며 조직 수준에서 동일한 이름을 사용할 수 있습니다.
runner.osstring작업을 실행하는 실행기의 운영 체제입니다. 가능한 값은 Linux, Windows, 또는 macOS입니다.
runner.archstring작업을 실행하는 실행기의 아키텍처입니다. 가능한 값은 X86, X64, ARM, ARM64입니다.
runner.tempstring실행기의 임시 디렉터리에 대한 경로입니다. 이 디렉터리는 각 작업의 시작과 끝에 비워집니다. 실행기 사용자 계정에 삭제 권한이 없는 경우 파일이 제거되지 않습니다.
runner.tool_cachestringGitHub 호스팅 실행기에 대해 미리 설치된 도구가 포함된 디렉터리의 경로입니다. 자세한 내용은 "GitHub 호스팅 실행기 사용"을 참조하세요.
runner.debugstring디버그 로깅을 사용하도록 설정한 경우에만 설정되며 항상 값이 1입니다. 사용자 고유의 작업 단계에서 추가 디버깅 또는 자세한 로깅을 사용하도록 설정하는 지표로 유용할 수 있습니다.
runner.environmentstring작업을 실행하는 실행기의 환경입니다. 가능한 값은 GitHub에서 제공하는 GitHub 호스트형 실행기의 경우 github-hosted, 리포지토리 소유자가 구성한 자체 호스트형 실행기의 경우 self-hosted입니다.

Example contents of the runner 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 the runner context

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

YAML
name: Build
on: push

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

secrets context

The 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 "GitHub Actions에서 비밀 사용."

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 "자동 토큰 인증."

경고: 작업에서 비밀이 사용된 경우 GitHub는 로그에 출력된 비밀을 자동으로 수정합니다. 의도적으로 로그에 비밀을 출력하지 않아야 합니다.

Property nameTypeDescription
secretsobjectThis 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.
secrets.GITHUB_TOKENstringAutomatically created token for each workflow run. For more information, see "자동 토큰 인증."
secrets.<secret_name>stringThe value of a specific secret.

Example contents of the secrets context

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

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

Example usage of the secrets context

이 예제 워크플로는 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 context

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

Property nameTypeDescription
strategyobjectThis 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.
strategy.fail-fastbooleanWhen this evaluates to true, all in-progress jobs are canceled if any job in a matrix fails. For more information, see "GitHub Actions에 대한 워크플로 구문."
strategy.job-indexnumberThe 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.
strategy.job-totalnumberThe 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.
strategy.max-parallelnumberThe maximum number of jobs that can run simultaneously when using a matrix job strategy. For more information, see "GitHub Actions에 대한 워크플로 구문."

Example contents of the strategy context

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

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

Example usage of the strategy context

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

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 context

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

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

Property nameTypeDescription
matrixobjectThis 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.
matrix.<property_name>stringThe value of a matrix property.

Example contents of the matrix context

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

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

Example usage of the matrix context

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

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 context

The 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 "GitHub Actions에 대한 워크플로 구문."

Property nameTypeDescription
needsobjectThis 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.
needs.<job_id>objectA single job that the current job depends on.
needs.<job_id>.outputsobjectThe set of outputs of a job that the current job depends on.
needs.<job_id>.outputs.<output name>stringThe value of a specific output for a job that the current job depends on.
needs.<job_id>.resultstringThe result of a job that the current job depends on. Possible values are success, failure, cancelled, or skipped.

Example contents of the needs context

The following example contents of the needs 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 the needs context

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

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 context

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

The properties in the inputs context are defined in the workflow file. They are only available in a reusable workflow or in a workflow triggered by the workflow_dispatch event

Property nameTypeDescription
inputsobjectThis context is only available in a reusable workflow or in a workflow triggered by the workflow_dispatch event. You can access this context from any job or step in a workflow. This object contains the properties listed below.
inputs.<name>string or number or boolean or choiceEach input value passed from an external workflow.

Example contents of the inputs context

The following example contents of the inputs context is from a workflow that has defined the build_id, deploy_target, and perform_deploy inputs.

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

Example usage of the inputs context in a reusable workflow

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

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

Example usage of the inputs context in a manually triggered workflow

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

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