The parts a pipeline keeps to itself

A pipeline that works is a temptation. The first one takes a week to get right; the second is a copy of the first with two words changed; by the thirty-first, an organisation has thirty-one YAML files that all build, test, and deploy in almost exactly the same way — and the day someone decides every deploy must now run a security scan, that is thirty-one files to edit, thirty-one reviews to chase, and one file quietly missed that becomes the gap an auditor finds a year later. Copy-paste is not a time-saver here; it is a debt that compounds silently, paid in the one pipeline nobody remembered to change. This part is about not incurring it — about writing the shared thing once and pointing many pipelines at it.

GitHub Actions provides repository and organization variables, secrets, workflow/job/step environment variables, reusable workflows, and composite actions. Use variables for non-secret settings, secrets for credentials, and reusable components when repeated work should have one maintained definition. Neither reusable mechanism automatically enforces organization policy; configure repository rules separately.

GitHub Actions expressions read context values such as github (event and repository), needs (outputs from earlier jobs), vars (configuration), and secrets (sensitive settings). Each context is permitted only in certain workflow fields. When a value is empty or rejected, check the context availability for that specific field in the workflow syntax.

Inside a shell script, Bash and PowerShell use their own variable syntax. To share a value with a later step in the same job, write it to the runner environment file; to share it with a later job, define a job output. A GitHub expression, a shell variable, and an environment variable are three different things. Keep secrets out of outputs, artifacts, and logs.

Pick the wrong brace, ship an empty string.

Ask when a value becomes available and where that context is allowed. A later step can read an earlier step’s declared output using the steps context. A dependent job reads a declared job output through needs. Do not call every GitHub expression compile-time: context availability depends on the field and execution stage. Pass untrusted values through an environment variable rather than inserting them directly into shell code.

Never commit passwords, API keys, or private tokens to a workflow file. GitHub secrets can be scoped to a repository, organization, or environment. Use the narrowest scope needed and restrict which workflows or environments can access them. Forked pull-request workflows do not receive repository secrets by default.

For Azure, prefer OIDC federation as taught in Class Twenty-Three so the workflow does not store a reusable Azure client secret. If an application still needs a secret held in Azure Key Vault, authenticate with a narrowly scoped federated identity and retrieve only what the job needs at run time. Log masking is a backstop, not permission to print secret values.

GitHub variable and secret

A variable stores non-sensitive configuration such as an app name. A secret stores a credential or key. Both can be scoped to a repository, organization, or environment; GitHub variables and secrets do not automatically link to Azure Key Vault.

For Azure login, prefer the Class 23 OIDC pattern so the workflow does not need a reusable Azure client secret. If an application must read a secret from Azure Key Vault, use OIDC to authenticate first and grant the workflow identity only the Key Vault permissions it needs. Keep other credentials in narrowly scoped GitHub secrets.

A reusable workflow declares typed inputs under on: workflow_call, then the caller supplies values under with:. Keep this interface separate from variables and secrets. Inputs describe options the reusable workflow accepts; secrets remain sensitive values and must be scoped to trusted jobs.

Inputs to a reusable workflow can be typed as strings, numbers, or booleans and are declared under workflow_call. The calling job supplies those values under with:. Regular variables hold configuration values; they do not determine the reusable workflow interface. Keep the interface small and validate what callers are allowed to select.

# .github/workflows/deploy.yml  (the reusable one)
on:
  workflow_call:
    inputs:
      environment: { type: string, required: true }
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to ${{ inputs.environment }}"

# .github/workflows/release.yml  (the caller)
jobs:
  test-env:
    uses: ./.github/workflows/deploy.yml
    with: { environment: test }

GitHub Actions has two common ways to share workflow logic. A reusable workflow is called at the job level and can define one or more jobs; a composite action packages steps that run inside a job. Both reduce copy-and-paste, but neither one alone forces every repository or caller to use the shared logic. Configure repository rules and protected environments separately when a control must be mandatory.

A reusable workflow is called at the job level and can contain one or more jobs. A composite action is called inside a job and packages repeated steps. Reuse reduces drift, but neither one automatically prevents a caller from adding other workflow logic. Use repository or organization rules and protected environments when enforcement is required.

Reusable workflow

Called from a job with uses:. It can own a multi-job process and accepts declared inputs and secrets.

Composite action

Called from a step with uses:. It packages steps for reuse inside a job; it does not create a separate job.

Enforcement

Repository rulesets, required status checks, permissions, and protected environments make controls mandatory. Reuse alone does not.

This example shares the build job. A caller can still define other jobs, so the repository must enforce any security requirement separately:

# .github/workflows/shared-build.yml — reusable workflow
name: Shared build
on:
  workflow_call:
    inputs:
      app-name:
        required: true
        type: string
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - run: echo "Build the requested app"

# .github/workflows/warehouse.yml — caller
name: Warehouse
on:
  push:
    branches: [main]
jobs:
  build:
    uses: ./.github/workflows/shared-build.yml
    with:
      app-name: basecamp-warehouse

The shared workflow reduces duplicated logic. Callers may still add other jobs unless repository policy prevents it, so keep release enforcement in protected settings.