8.2. Terms M–Z

Matrix — strategy.matrix, generating one job per combination of axis values; reshaped by include/exclude, capped at 256 jobs. (§2.2.4)

needs — Job-level key declaring dependencies; provides ordering and access to needs.<job>.outputs and .result — not shared files or state. (§2.2.1)

OIDC (OpenID Connect) — Federation that exchanges a signed, claim-bearing token (requires id-token: write) for short-lived cloud credentials, eliminating stored cloud secrets. (§6.1.3)

PAT (personal access token) — A long-lived, user-scoped credential; prefer fine-grained PATs or GitHub App tokens, and prefer GITHUB_TOKEN wherever it suffices. (§6.1.1)

permissions — Block setting GITHUB_TOKEN scopes at workflow or job level; declaring it replaces the defaults rather than adding to them. (§2.1.4)

pull_request_target — Trigger running in the base repository's context with secrets and a write token; dangerous when combined with checking out PR head code. (§2.1, §6.1.2)

Reusable workflow — A workflow with on: workflow_call, invoked by a job via uses:; resolved at run time so updates propagate. Inputs are string/number/boolean only. (§2.1.3, §4.3.2)

Runner — The machine executing a job: GitHub-hosted (fresh VM, discarded) or self-hosted (yours, persistent by default). (§3.2.1)

Runner group — Access-control boundary determining which repositories and workflows may schedule on a set of runners. (§3.2.2)

Script injection — Executing attacker-controlled text because ${{ }} substitution precedes shell parsing; mitigated by routing untrusted values through env:. (§6.1.2)

Secret — Encrypted key/value, masked in logs, never readable through the API; scoped to organization, repository, or environment. (§3.3.1)

Service container — A Docker container attached to a job's lifecycle via services:; reached at localhost:<mapped port> from the host runner, or by service label from a job container. (§2.2.3)

SLSA provenance — Supply-chain framework the attestation format follows, describing how an artifact was built. (§6.1.4)

Starter workflow — A scaffold in the org's .github repository under workflow-templates (with .properties.json), copied at creation and independent thereafter. (§3.1.1, §4.3.1)

Step — The unit of sequence within a job, sharing the runner's filesystem and environment. (§1.2.2)

Variable (vars) — Plaintext, readable configuration following the same three-tier precedence as secrets. (§3.3.1)

workflow_call — Trigger making a workflow reusable, declaring inputs, secrets, and outputs. (§2.1.3)

workflow_dispatch — Manual trigger with up to 25 typed inputs (string, number, boolean, choice, environment); requires the file on the default branch to appear. (§2.1.2)

Workflow command — A specially formatted log line (::error::, ::add-mask::, ::group::) instructing the runner; wrapped by @actions/core functions. (§2.2.2, §5.2.2)