GitHub Actions key terms

A configurable automated process defined in a YAML file inside .github/workflows. It contains one or more jobs and is triggered by events, schedules, or manual dispatch.

A set of steps that execute on the same runner. Jobs in a workflow run in parallel by default unless dependencies are declared with the needs keyword.

A single task inside a job. A step either runs a shell command using run or invokes a reusable action using uses, and steps execute sequentially on the same runner.

The activity that starts a workflow, declared under the on key. Examples include push, pull_request, schedule, workflow_dispatch, and release.

A trigger that allows a workflow to be started manually from the GitHub UI, API, or CLI. It supports typed input parameters that are referenced through the inputs context.

A paths or paths-ignore condition on a trigger that limits workflow execution to changes in specified files or directories, reducing unnecessary runs.

A branches or branches-ignore condition on a trigger that restricts which branches cause a workflow to run, commonly used to separate feature-branch checks from main-branch deploys.

The server that executes a job. Runners can be GitHub-hosted with a chosen operating system label, or self-hosted and registered to a repository, organization, or enterprise.

A machine you provision and register to run jobs. It gives control over hardware, network access, and installed software, but you are responsible for patching and scaling it.

A tag such as ubuntu-latest or a custom name assigned to runners. The runs-on key matches jobs to runners that carry the requested labels.

The job-level key that selects where a job executes, accepting a GitHub-hosted label, a self-hosted label, or an array of labels that must all match.

A reusable unit of automation invoked with the uses keyword. Actions can be published on the Marketplace, written in JavaScript, or packaged as Docker containers.

A custom action composed of multiple steps defined in an action.yml file. It bundles shell commands and other actions without requiring JavaScript or Docker packaging.

The metadata file that defines an action's name, description, inputs, outputs, and execution method. It is required for custom actions and for reusable action references.

A publicly published action hosted in a repository and referenced by owner/repo@ref. Pinning to a full commit SHA is the safest way to avoid supply-chain surprises.

The step or job keyword that references an action or reusable workflow. For actions the value is owner/repo@ref or a local path; for workflows it is owner/repo/.github/workflows/file.yml@ref.

Referencing an action by its full 40-character commit hash instead of a mutable tag such as v3, which prevents a compromised or retagged release from changing what runs.

A structured object exposing runtime data to expressions, such as github, env, secrets, matrix, needs, and steps. Contexts are referenced with the ${{ }} expression syntax.

The context holding event and repository metadata, including github.event, github.ref, github.sha, github.repository, github.actor, and github.workspace.

The ${{ }} notation used to interpolate contexts and evaluate functions such as contains, startsWith, format, and toJSON inside workflow values and if conditions.

The if key on a job or step that evaluates an expression and skips execution when the result is false. It is commonly combined with status check functions.

A function such as success(), failure(), always(), or cancelled() used in if conditions to control whether later steps run after a failure or regardless of outcome.

A strategy that expands one job definition into multiple parallel jobs across combinations of variables, such as several language versions and operating systems.

Modifiers to a matrix that add extra variable combinations or remove unwanted ones, letting teams cover supported platforms without running every possible permutation.

A matrix setting, true by default, that cancels all in-progress and queued jobs in the matrix as soon as any one of them fails.

The job keyword that declares dependencies, forcing a job to wait for listed jobs and exposing their outputs through the needs context.

Values a job publishes for downstream jobs. They are declared with the outputs key and must be written to the GITHUB_OUTPUT file to survive across jobs.

A value produced by a step and read through steps..outputs. Steps set outputs by appending name=value lines to the file named by GITHUB_OUTPUT.

An environment variable pointing to a per-step file where a step writes key=value lines to publish outputs, replacing the deprecated ::set-output workflow command.

A file path environment variable. Lines written to this file become environment variables available to subsequent steps in the same job.

A file path environment variable. Directories appended to this file are prepended to PATH for later steps, which is how tools installed mid-job become callable.

A special stdout line beginning with :: that instructs the runner, for example ::error::, ::group::, or ::add-mask::. Several older commands are deprecated in favor of environment files.

Encrypted values stored at repository, environment, or organization level and referenced through the secrets context. They are masked in logs and never exposed to fork pull requests by default.

A short-lived token automatically issued to each workflow run. Its permissions are set with the permissions key and it expires when the job finishes.

The workflow or job key that scopes GITHUB_TOKEN access, such as contents: read or id-token: write. Setting least privilege explicitly is a core hardening practice.

OpenID Connect federation that lets a workflow obtain short-lived cloud credentials by presenting a signed identity token, removing the need for long-lived stored cloud secrets.

A named deployment target configured in repository settings that can require reviewers, wait timers, and environment-scoped secrets before a job referencing it proceeds.

A protection rule on an environment that blocks a job from starting until designated people approve it, providing a manual gate before production deployment.

A workflow or job key that groups runs under a shared name so only one proceeds at a time, optionally cancelling in-progress runs to avoid overlapping deployments.

A whole workflow called from another workflow via a job-level uses, accepting inputs and secrets and allowing standardized pipelines to be shared across repositories.

The actions/cache action that stores and restores dependency directories keyed by a hash, cutting install time on later runs. Built-in setup actions often cache automatically.

A file or directory uploaded from a run with actions/upload-artifact and downloaded later, used to persist build output, test reports, or logs beyond the job's lifetime.

A Docker container started alongside a job to provide a dependency such as a database or message broker, reachable by the job's steps over the network.

A YAML document stored under .github/workflows in the repository. Its filename identifies the workflow, and invalid syntax prevents the workflow from running.

The indentation-sensitive data format used for workflow and action files. Incorrect indentation and unquoted special characters are frequent causes of validation errors.

The directed acyclic graph formed by jobs linked through needs. It determines execution order and parallelism, and cycles are rejected at validation time.

The runner's automatic redaction of secret values in logs. Masking is best-effort, so printing secrets deliberately or transforming them can still leak data.

GitHub's automated dependency updater, which can also open pull requests that bump pinned action SHAs and versions, keeping workflow dependencies current.

A trigger that starts a workflow when an external system posts a custom event type to the repository's dispatch API, useful for cross-repository automation.

The context holding values passed to a workflow_dispatch or reusable workflow call, read as inputs.name and validated against declared types.