How do I reference a context in a GitHub Actions workflow?

Wrap the expression in the dollar-double-brace syntax, for example the run number is referenced as github.run_number inside a ${{ }} block. Contexts are accessed with dot notation and evaluated before the job runs on the runner.

How do I pass data between steps?

Give a step an id, write to the GITHUB_OUTPUT file, then read it from a later step via steps. .outputs. . The outputs are only available after the producing step has completed within the same job.

Why can't I access secrets in a composite action?

Secrets are not automatically passed into composite action expressions. You must forward them explicitly as inputs from the calling workflow. This is a deliberate isolation boundary to avoid leaking secrets into reusable actions.

What is the difference between outcome and conclusion for a step?

steps. .outcome is the raw result before continue-on-error is applied, while steps. .conclusion is the final result after it. A step that fails but has continue-on-error true has outcome failure and conclusion success.

How do I get the operating system inside a matrix job?

Use runner.os, which returns Linux, Windows or macOS. Combine it with matrix. to branch behaviour per matrix dimension, and strategy.job-index to identify which matrix instance is running.

What is the GitHub Actions Contexts Reference?

Searchable GitHub Actions context reference covering github, env, vars, secrets, job, steps, runner, matrix, needs and inputs — with each context's key properties, types and where they are available. It runs free in your browser on Gera Tools, with nothing uploaded.

GitHub Actions Contexts Reference

Name: GitHub Actions Contexts Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Every GitHub Actions context in one place

GitHub Actions exposes runtime data through contexts — structured objects you read inside ${{ }} expressions to make workflows dynamic. This reference lists each context with its most-used properties, their types, and where each context is available. Search by context name or property path.

The context system

An expression inside ${{ }} is evaluated by the Actions runner before the step runs. Contexts provide all the runtime data those expressions need:

Context	What it covers
`github`	Event type, repository, branch, SHA, actor, and run metadata
`env`	Environment variables set in the workflow file
`vars`	Repository/organisation variables (non-secret configuration)
`secrets`	Encrypted secrets
`job`	Current job’s status and container info
`steps`	Outputs and status of previously completed steps
`runner`	The runner’s OS, architecture, temp dir, and workspace
`matrix`	Current matrix dimension values
`needs`	Results and outputs of upstream jobs
`inputs`	Workflow inputs (for manually triggered or reusable workflows)
`strategy`	Matrix strategy metadata (job count, index, fail-fast setting)

Availability matters as much as value

Some contexts are only populated in certain positions:

steps.<id> — only available after a step with that id has completed within the same job
needs.<job> — only available when the current job declares that job in its needs: list
secrets — not automatically forwarded into composite actions; must be passed as explicit inputs
inputs — only available in workflow_call or workflow_dispatch triggered workflows
matrix — only available inside jobs that define a strategy.matrix

Referencing an unavailable context evaluates to empty string or null, not an error — which can cause silent failures.

Commonly used properties

github.ref_name       # branch or tag name (e.g. "main", "v1.2.3")
github.sha            # full commit SHA
github.event_name     # "push", "pull_request", "workflow_dispatch", etc.
github.actor          # username who triggered the workflow
github.run_number     # incrementing integer for this workflow's runs
runner.os             # "Linux", "Windows", or "macOS"
job.status            # "success", "failure", "cancelled"
steps.<id>.outputs.<name>   # output written with echo "key=val" >> $GITHUB_OUTPUT
needs.<job>.result    # "success", "failure", "skipped", "cancelled"
strategy.job-index    # 0-based index of this matrix instance

Practical examples

Conditionally deploy only from the main branch:

- if: github.ref_name == 'main'
  run: ./deploy.sh

Pass a value from one step to the next using GITHUB_OUTPUT:

- id: version
  run: echo "tag=$(cat VERSION)" >> "$GITHUB_OUTPUT"
- run: echo "Deploying ${{ steps.version.outputs.tag }}"

Fan out across operating systems:

strategy:
  matrix:
    os: [ubuntu-latest, macos-latest, windows-latest]
runs-on: ${{ matrix.os }}
steps:
  - if: runner.os == 'Windows'
    run: echo "Windows-specific step"

Gate a publish job on a successful test job:

publish:
  needs: test
  if: needs.test.result == 'success' && github.ref_name == 'main'

A caution: never print secrets.* values to logs intentionally. GitHub masks them, but transformations (base64, URL-encoding, substring) can produce output that bypasses masking.