GitHub Actions
Build pipelines with GitHub Actions — workflows, jobs, steps, and reusable actions.
Theory
GitHub Actions runs CI/CD pipelines defined as YAML in .github/workflows/. The
hierarchy:
- Workflow — a file triggered by events (
push,pull_request, schedule) - Job — runs on a fresh runner; jobs run in parallel unless they
needseach other - Step — a shell command or a reusable action (
uses:)
Pass data with secrets (${{ secrets.X }}), cache dependencies, and use a
matrix to test across versions. For cloud deploys, use OIDC to assume a role
without storing long-lived keys.
Real-World Example
name: CI
on:
push: { branches: [main] }
pull_request:
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix: { node: [18, 20] }
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: ${{ matrix.node }} }
- run: npm ci
- run: npm test
deploy:
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- run: ./deploy.sh Hands-On Exercise
- Write a workflow that runs tests on every pull request.
- Add a matrix to test against two language versions.
- Make a deploy job depend on a test job with
needs. - Reference a secret and explain why it’s not hardcoded.
Cheat Sheet▾
| Concept | Key |
|---|---|
| Trigger | on: [push, pull_request] |
| Job runner | runs-on: ubuntu-latest |
| Use an action | uses: owner/action@v4 |
| Run a command | run: npm test |
| Job dependency | needs: [job] |
| Matrix | strategy.matrix |
| Secret | ${{ secrets.NAME }} |
Common Interview Questions▾
What are the building blocks of a GitHub Actions workflow?
A workflow triggered by events contains jobs (each on a fresh runner, parallel unless chained with needs), and each job has steps that run commands or reusable actions.
How should a workflow authenticate to a cloud provider?
Via OIDC, exchanging the workflow’s identity for short-lived cloud credentials, so no long-lived secret keys are stored in GitHub.
Official Documentation
📝 My notes on this topic
Auto-saves as you type