GitHub Actions
Workflows, matrices, secrets, reusable actions.
Theory
GitHub Actions is a CI/CD platform built into GitHub. Workflows are YAML files in .github/workflows/ that trigger on repository events (push, pull_request, schedule, workflow_dispatch for manual runs). Each workflow contains jobs; each job runs on a runner (GitHub-hosted or self-hosted) and consists of steps (shell commands or pre-built actions).
Triggers: on: push runs on every push; on: pull_request runs CI on PR branches; on: schedule uses cron syntax for periodic runs; on: workflow_dispatch adds a manual "Run workflow" button in the GitHub UI. Filters: branches: [main, 'release/*'] and paths: ['src/**'] reduce unnecessary runs.
Actions are reusable steps from the Marketplace or your own repos. actions/checkout@v4 clones the repo. actions/setup-python@v5 installs a Python version. docker/build-push-action@v5 builds and pushes a Docker image. Each action is pinned by SHA or tag in production workflows for reproducibility and security (supply chain attacks via action tag hijacking are real).
Matrix builds run one job across multiple dimension combinations: matrix: python-version: [3.10, 3.11, 3.12] os: [ubuntu-latest, macos-latest] spawns 6 parallel jobs. This ensures your library works across supported environments without writing duplicate jobs.
Secrets and environments: repository secrets (Settings → Secrets) inject credentials at runtime. Environment secrets add a protection rule (require reviewers before deployment to production). OIDC tokens: configure an AWS IAM role to trust GitHub's OIDC provider — runners assume the role with a short-lived token, no stored AWS keys needed.
Caching: actions/cache@v4 persists pip/npm/gradle caches between runs, dramatically speeding up dependency installation. Cache key on requirements hash: key: ${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}. Cache miss: install dependencies; cache hit: restore and skip install. Typical speedup: 2–5× on Python/Node projects.
Reusable workflows (workflow_call trigger) let you define CI/CD pipelines once and call them from multiple repositories. This is the recommended pattern for platform teams enforcing org-wide standards — update one workflow, all consuming repos pick up the change on next run. Composite actions bundle multiple steps into one reusable unit within a single repo.
Architecture Diagram
Users / clients
|
GitHub Actions
|
Core services
|
Data + observabilityExamples
# GitHub Actions
# Workflows, matrices, secrets, reusable actions.
# Validate in staging before production rollout.Interview Questions
What problem does GitHub Actions solve?
It addresses the core use case described in production architecture — map features to reliability, scale, or velocity outcomes.
Key components of GitHub Actions?
Identify inputs, outputs, control plane, data plane, and failure domains — interviewers want structured decomposition.
Common production pitfalls?
Misconfiguration, missing observability, no rollback path, and scaling bottlenecks under peak load.
How do you test changes safely?
Staging parity, canary/gradual rollout, automated health checks, and documented rollback.
Metrics to prove success?
Error rate, latency percentiles, throughput, cost, and toil reduction — pick one primary SLO.
Beginner vs advanced concern?
Beginners focus on setup; advanced teams focus on blast radius, security boundaries, and operability at 10× scale.
Best Practices
- Treat GitHub Actions config as code with review and CI validation.
- Define SLOs and dashboards before production cutover.
- Document rollback and ownership for on-call.
- Use least privilege for credentials.
Common Mistakes
- Adopting GitHub Actions without measurable success criteria.
- No staging environment mirroring production constraints.
- Missing rollback path during incidents.
- Undocumented on-call expectations.
Cheat Sheet
Practical Exercises
Stand up GitHub Actions locally or in free tier; document commands and failure recovery.
Introduce misconfiguration; practice detection and rollback under time limit.