GitHub Actions · DevOps & CI/CD Deep Dive

Anatomy

How a Workflow Runs

Workflow — a YAML file in .github/workflows/; one or more jobs.
Event — what triggers it: push, pull_request, schedule, workflow_dispatch, release, issues, …
Job — runs on a runner (Linux, Windows, macOS); jobs run in parallel by default, with needs: to chain them.
Step — either a shell command or a reusable action (uses: actions/checkout@v4).
Matrix — fan out a job across versions/OSes (Node 18/20/22 × Ubuntu/macOS).
Artifact / cache — pass build outputs between jobs; cache deps across runs.

Trigger to Deploy

Push / PR

→

Runner provisioned

→

Checkout + setup

→

Build & test

→

Upload artifact

→

Deploy job (OIDC → cloud)

Power Features

Reusable workflows (workflow_call) — share pipelines across many repos without copy-paste.
Composite actions — bundle several steps into one reusable unit.
OIDC federation — runners assume cloud roles short-lived; no long-lived AWS/GCP/Azure secrets in repo.
Environments — gate deploys with required reviewers, wait timers, and per-env secrets.
Concurrency groups — cancel superseded PR runs, or serialize prod deploys.
Self-hosted runners — for GPUs, on-prem VPC access, or custom hardware. ARC (Actions Runner Controller) runs them on Kubernetes.

Tradeoffs

Supply-chain risk. Pin third-party actions to a SHA, not @v1. Compromised actions run with your secrets.
YAML fatigue. Big workflows get unwieldy fast; reach for reusable workflows before they sprawl.
Cost. macOS minutes are 10× Linux. Self-hosted runners bring big savings for heavy use.
Forks & secrets. By default secrets aren't passed to PRs from forks — for good reason. Don't override without thought.
Vendor lock-in. Workflows don't port cleanly to Jenkins or GitLab — moving off is a real project.

Continue