GitHub Actions Recipes — The Practical Guide

GitHub Actions Recipes — The Practical Guide#

GitHub Actions is easy to start with and easy to get subtly wrong. The result is pipelines that are slow, leak secrets, rebuild everything on every push, or quietly burn through your minutes budget. Almost all of it comes down to a small set of jobs that everyone needs and few people set up correctly the first time. This guide is the map: the recipes that matter, what each one fixes, and where the full walkthrough lives.

A workflow is just YAML describing jobs, steps, and triggers. The leverage is in the details: what you cache, how you scope permissions, and how much you run in parallel.

name: ci
on: [push, pull_request]
permissions:
  contents: read          # least privilege by default; widen per-job only when needed
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

Making it fast#

• Cache dependencies: the single biggest speedup, so CI stops re-downloading the same packages every run. Set up in caching dependencies in GitHub Actions, which pairs with the strategy in CI pipeline caching that pays off.
• Matrix builds: test across versions and OSes in parallel without copy-pasting jobs, covered in matrix builds that don't waste minutes.
• Speed up a slow pipeline: the full toolkit (parallelism, caching, path filters, bigger runners) is in how to speed up a slow CI pipeline. When minutes get expensive, self-hosted runners change the cost model.

Doing it securely#

• Secrets: how to use repository and environment secrets without leaking them in logs or to forks, in using secrets in GitHub Actions safely.
• Keyless deploys: stop storing long-lived cloud keys in secrets and use OIDC to assume a role at runtime, walked through in keyless deploys to AWS via OIDC. The broader pattern is keyless cloud authentication.

Common jobs#

• Build and push Docker images: buildx, layer caching, and multi-arch, in build and push Docker images in CI.
• Conditional jobs and path filters: only run the jobs that a change actually affects, in conditional jobs and path filters.
• Reusable workflows: stop copy-pasting the same YAML across dozens of repos, covered in reusable workflows at org scale.

The starter checklist#

Run through this once for any new workflow — each row is one recipe above, in the order it usually pays off:

The mental model#

Every workflow improvement falls into one of three buckets: faster (cache, parallelize, skip unaffected jobs), safer (least-privilege permissions, scoped secrets, OIDC instead of static keys), or cheaper (fewer wasted minutes, right-sized runners). Set a restrictive permissions: block at the top, cache aggressively, and pin third-party actions to a commit SHA, and most problems never appear. Picking the platform itself is a separate decision, compared in best CI/CD platforms.

The call we'd make#

Start every workflow from least-privilege permissions and a dependency cache, because those two lines fix the most common security and speed problems at once. Add OIDC before you ever paste a cloud key into a secret. Then reach for matrix builds, path filters, and reusable workflows as the repo grows. Each linked recipe is a focused fix; adopt them in that order and a GitHub Actions setup stays fast, secure, and cheap as it scales.