GitHub Actions patterns that look advanced are mostly just composing a few primitives well. The teams shipping fast CI on GitHub Actions are using reusable workflows, smart caching, matrix strategies, and conditional execution to keep build times under five minutes even on substantial repos. The teams stuck on 30-minute pipelines usually have not learned five specific patterns. Here is what makes the difference.
Table of Contents
Reusable Workflows Beat Composite Actions
For sharing logic between repos or workflows, reusable workflows (`workflow_call` trigger) win over composite actions in most cases. They support secrets, run as separate workflow runs (visible in the UI), and accept inputs with proper typing.
Composite actions are still useful for tightly-coupled steps that always run together. Reusable workflows shine for multi-job pipelines you want to share across repos. The official reusable workflows documentation shows the syntax.
Cache Aggressively With Real Keys
The default `actions/cache` is great, but only if your cache keys are good. Use lockfile hashes for dependency caches (`hashFiles(‘**/pnpm-lock.yaml’)`), build-tool-specific keys for build caches, and OS+arch in the key for native deps.
A well-cached pnpm install drops from 90 seconds to 3 seconds. A well-cached Turbo or Nx run skips entirely when nothing changed. Setup actions for popular tools (`actions/setup-node`, `pnpm/action-setup`) handle most of this for you with `cache: ‘pnpm’` parameters.
Matrix Builds for Cross-Platform Testing
Matrix strategies parallelize across OS, language version, and any other dimension you care about. Add `fail-fast: false` so you see all failures, not just the first one.
For tests that take longer, shard across matrix instances. The `setup-` actions and Jest/Vitest both support sharding natively. A 20-minute test suite split 4 ways finishes in 5. See our CI/CD pipeline setup guide for the broader pipeline architecture.
Conditional Steps and Path Filters
Run jobs only when relevant files change. The `paths` filter on push/pull_request triggers prevents running the API tests on a docs-only PR. For monorepos, this is essential — without it, every change runs every test.
For more nuanced logic, the `dorny/paths-filter` action lets you set outputs based on changed file patterns and branch downstream jobs accordingly. Combine with `if:` conditionals on each step.
OIDC for Cloud Auth
Stop storing long-lived AWS/GCP/Azure credentials as GitHub secrets. OIDC federation lets GitHub Actions assume a cloud role at runtime, scoped to the specific workflow and repo.
The setup is a one-time IAM trust policy in your cloud provider plus the `aws-actions/configure-aws-credentials` (or equivalent) action with `role-to-assume`. No more rotating credentials, no more secret leaks. The OIDC security hardening docs walk through the setup.
Wrap Up
GitHub Actions patterns that save real time focus on caching, parallelism, conditional execution, and proper secrets management. Reusable workflows for sharing, OIDC for cloud auth, matrix builds for parallelism, and path filters to skip unnecessary work. Most teams can cut their CI time by half in a focused day of optimization. Combine these patterns with Docker best practices for a fast, secure deployment pipeline.
Frequently Asked Questions
Should I use self-hosted runners?
Self-hosted for jobs that need specific hardware (GPUs), are bandwidth-heavy (large artifacts), or need access to private networks. GitHub-hosted for everything else — the operational savings outweigh the per-minute cost for most teams.
How do I keep secrets out of logs?
GitHub auto-masks values stored in secrets, but only if they are present at job start. Avoid concatenating secrets with other data, use `::add-mask::` for runtime-derived sensitive values, and review logs of any new workflow before promoting it.
Are GitHub Actions cheaper than CircleCI/Buildkite?
For small-to-medium teams on public or modestly-sized private repos, generally yes. For very high-volume CI or complex orchestration needs, dedicated CI platforms still have advantages.
How do I handle long-running jobs that exceed the 6-hour limit?
Split the job. If you genuinely need a long-running task, use a self-hosted runner with no timeout, or move the task to a dedicated background worker outside CI.
Can I run Actions locally?
Yes — `act` is the most popular tool for running GitHub Actions workflows locally for debugging. It is not 100% feature-complete but handles most workflows.
