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.

GitHub Actions Contexts Reference

Every GitHub Actions context in one place

GitHub Actions exposes runtime data through contexts — 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.

How it works

An expression is written inside the ${{ }} delimiters and evaluated by the Actions runner before steps execute. Contexts are the variables those expressions read. Each context covers a different scope: github describes the event and repository, env/vars/secrets carry configuration, job/steps/runner describe execution state, and matrix/needs/inputs/strategy carry build-fan-out and dependency data.

Availability matters as much as the value. Some contexts only exist in certain positions — steps is populated only after a step with an id runs, needs only when a job declares dependencies, and secrets is intentionally withheld from composite actions. The reference notes these constraints so you do not reference a context that evaluates to empty.

Property paths use dot notation, and some have a placeholder segment like steps.<id>.outputs.<name> where you substitute your own identifiers.

Tips and examples

Conditionally run a step based on the branch:

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

Pass an output from one step to another:

- id: meta
  run: echo "tag=v1.2.3" >> "$GITHUB_OUTPUT"
- run: echo "Releasing ${{ steps.meta.outputs.tag }}"

Branch on the runner OS in a cross-platform matrix with runner.os, and read upstream results with needs.<job_id>.result.
Never print secrets.* to logs intentionally — they are masked, but echoing them risks exposure through transformations.

GitHub Actions Contexts Reference

Email me this result

Every GitHub Actions context in one place

How it works

Tips and examples