GitHub Actions

Published on August 17, 2023

GitHub Actions executes workflows in response to repository events. The important design boundary is trust: a workflow can run unreviewed code, read repository data, create artifacts, and sometimes acquire deployment authority.

Minimal workflow


name: verify
on:
  pull_request:
 
permissions:
  contents: read
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version-file: .nvmrc
          cache: pnpm
      - run: corepack enable
      - run: pnpm install --frozen-lockfile
      - run: pnpm build

Security and delivery controls

Declare minimal GITHUB_TOKEN permissions and raise them only for the job that needs them.
Treat pull requests from forks and dependency automation as untrusted input.
Never expose deployment secrets to a job that executes unreviewed code.
Pin third-party actions to reviewed commit SHAs where the threat model requires stronger immutability.
Prefer OpenID Connect and short-lived cloud credentials over stored access keys.
Protect environments and require review for high-risk production changes.
Build once, identify the artifact, preserve provenance, and promote the same artifact.

Reusable workflows can standardize a delivery contract, but version them and provide migrations. A central workflow that changes every repository without compatibility testing creates organization-wide blast radius.

Measure queue time, time to first useful failure, flake rate, artifact availability, deployment outcome, and recovery. Continue with the DevOps path for the larger delivery architecture.

For Kubernetes-hosted self-hosted runners, see Actions Runner Controller, which I have used to run GitHub Actions jobs.