GitHub Actions: Zero to Hero

CI/CD built into GitHub, hands-on. You'll write your first workflow, understand events and jobs, cache dependencies, run matrices, use secrets and environments, and build a secure deploy pipeline.

---

Prerequisites

Nothing to install locally — Actions runs on GitHub-hosted runners. You just need push access to a repo.

---

1. The model

GitHub Actions runs workflows — YAML files in .github/workflows/ — in response to events (a push, a pull request, a schedule, a manual click). Each workflow has jobs; each job runs on a fresh runner (VM) and contains steps (shell commands or reusable actions).

event  ->  workflow  ->  job(s) on runners  ->  step(s)

Jobs run in parallel by default and get a clean environment each time — so builds are reproducible.

---

2. Your first workflow

Create .github/workflows/ci.yml:

name: CI
on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm test

Commit it. On the next push or PR, GitHub runs the job and shows a green check or red X on the commit. actions/checkout pulls your code; actions/setup-node installs Node and — with cache: npm — caches ~/.npm between runs.

---

3. Events and triggers

on: decides when a workflow runs. The common ones:

on:
  push:
    branches: [main]
    paths: ['src/**']        # only when source changes
  pull_request:
  schedule:
    - cron: '0 6 * * *'      # daily at 06:00 UTC
  workflow_dispatch:          # a manual "Run workflow" button

Use paths: filters to avoid running heavy jobs on docs-only changes, and workflow_dispatch for on-demand deploys.

---

4. Matrices: test everything at once

Run the same job across versions or OSes in parallel:

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, macos-latest]
        node: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '${{ matrix.node }}' }
      - run: npm ci && npm test

That's 6 parallel jobs. fail-fast: false lets the others finish even if one combination fails, so you see the full picture.

---

5. Caching and artifacts

• Cache speeds up repeat runs by restoring a directory keyed on a lockfile hash:

- uses: actions/cache@v4
  with:
    path: ~/.cache/pip
    key: pip-${{ hashFiles('requirements.txt') }}

• Artifacts pass files between jobs or hand them to you (test reports, build output):

- uses: actions/upload-artifact@v4
  with: { name: dist, path: dist/ }

A downstream job restores it with download-artifact.

---

6. Secrets, environments, and job dependencies

Store credentials in Settings → Secrets and variables → Actions, then reference them — never hard-code:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t app:${{ github.sha }} .

  deploy:
    needs: build                 # runs only after build succeeds
    runs-on: ubuntu-latest
    environment: production      # gate + protection rules
    steps:
      - run: ./deploy.sh
        env:
          API_TOKEN: ${{ secrets.PROD_API_TOKEN }}

• needs: creates a dependency, turning parallel jobs into a pipeline.
• environment: unlocks required reviewers, wait timers, and environment-scoped secrets — so a prod deploy can require manual approval.

---

7. Secure your pipeline

CI has access to your code and secrets — treat it as production:

• Pin actions to a version. Prefer @v4 at minimum; for third-party actions, pin to a full commit SHA to prevent a hijacked tag from running in your pipeline.
• Least-privilege token. Set the default GITHUB_TOKEN to read-only and grant per-job:

permissions:
  contents: read

• Prefer OIDC over long-lived cloud keys. Exchange a short-lived token with AWS/GCP/Azure instead of storing static credentials:

permissions:
  id-token: write
  contents: read

• Never echo secrets or interpolate untrusted input (like a PR title) into a run: shell — that's a script-injection path. Pass it via env: instead.

---

8. Don't repeat yourself

• Reusable workflows — call one workflow from another with uses: ./.github/workflows/deploy.yml and pass inputs/secrets. Define your deploy once, call it per environment.
• Composite actions — bundle repeated steps into action.yml and share across repos.
• Concurrency — cancel superseded runs so a rapid series of pushes doesn't queue up:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

---

9. A realistic build → deploy pipeline

name: Release
on:
  push:
    tags: ['v*']
permissions:
  contents: read
  id-token: write
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t ghcr.io/acme/app:${{ github.ref_name }} .
      - run: docker push ghcr.io/acme/app:${{ github.ref_name }}
  deploy:
    needs: build
    environment: production
    runs-on: ubuntu-latest
    steps:
      - run: kubectl set image deploy/app app=ghcr.io/acme/app:${{ github.ref_name }}

Tag a release (git tag v1.2.0 && git push --tags) and the image builds, pushes, and — after the production environment's approval — deploys.

---

Common mistakes to avoid

• Interpolating untrusted input into run:. A PR title like $(rm -rf /) becomes a script-injection path. Pass it via env:, never inline into the shell.
• Default read-write token. The GITHUB_TOKEN is broad by default. Set permissions: contents: read and grant more per-job only when needed.
• Floating third-party action tags. A hijacked @v3 tag runs in your pipeline with your secrets. Pin third-party actions to a full commit SHA.
• Long-lived cloud keys in secrets. Prefer OIDC (id-token: write) to exchange a short-lived token with AWS/GCP/Azure.
• echoing secrets. Even masked, it's a leak risk. Never print them.
• No caching. Every run reinstalls from scratch. Cache the package dir keyed on the lockfile hash.
• No concurrency control. Rapid pushes queue redundant runs. Add a concurrency group with cancel-in-progress.
• Copy-pasting the deploy job across environments. Use a reusable workflow or composite action instead.

---

Practice: try it yourself

1. First green check. Add the ci.yml from Part 2 to a repo, push, and watch the check appear on the commit. Break a test and confirm it goes red.
2. Matrix it. Expand the test job to run on [ubuntu-latest, macos-latest] × [18, 20, 22] with fail-fast: false. How many jobs run in parallel?
3. Gate a deploy. Add a deploy job with needs: build and environment: production, and configure a required reviewer so it waits for approval.
4. Lock it down. Set permissions: contents: read, pin one third-party action to a SHA, and add a concurrency block that cancels superseded runs.

Self-check:

• Why is interpolating a PR title into run: dangerous, and what's the fix?
• What does needs: change about how jobs execute?
• Why pin a third-party action to a SHA rather than a tag?
• What does an environment: give you that a plain job doesn't?

---

Where to go next

• Generate a hardened container for your build with the Dockerfile linter & generator.
• Deploy the result with GitOps via Argo CD instead of kubectl in CI.
• Practice CI/CD interview questions in the question bank.

You can now build multi-job, cached, matrixed pipelines with least-privilege secrets and gated deploys — production-grade GitHub Actions.