---
name: github-actions-pro
description: "CI/CD workflows that scale — reusable workflows, matrix builds, caching, OIDC, secrets, releases. Production GitHub Actions: reusable workflows (workflow_call), composite actions, matrix builds, cache-action, OIDC for keyless AWS/GCP auth, deployment environments + approvals, release-please for changelog automation, and the cost-optimization patterns."
license: MIT
---

# GitHub Actions Pro

A working knowledge base for building GitHub Actions pipelines that survive growth: DRY workflows shared across repos, fast caches, keyless cloud auth, and gated deployments. It's aimed at platform and DevOps engineers who already write basic `.yml` workflows but are fighting copy-paste sprawl, slow runners, long-lived cloud keys, and ballooning Actions minutes.

## When to use it

- You have the same build/test steps duplicated across a dozen repos and want one source of truth via `workflow_call`.
- CI takes too long because dependencies reinstall every run, or you're paying for idle matrix legs.
- You're storing static `AWS_ACCESS_KEY_ID` secrets and want to move to OIDC federation instead.
- You need manual approvals before a production deploy, or automated semver releases and changelogs.

## What it does

It generates and reviews real Actions primitives: **reusable workflows** (`on: workflow_call` with typed `inputs`/`secrets`, called via `uses: org/repo/.github/workflows/ci.yml@v1`), **composite actions** (`runs.using: "composite"` in `action.yml`), and **matrix builds** with `strategy.matrix`, `include`/`exclude`, `fail-fast`, and `max-parallel`. For speed it wires `actions/cache` with correct `key`/`restore-keys` and the `setup-*` actions' built-in caching. For auth it configures **OIDC**: `permissions: id-token: write`, `aws-actions/configure-aws-credentials` with `role-to-assume`, or `google-github-actions/auth` with Workload Identity Federation — no stored keys. It sets up **deployment environments** with required reviewers and wait timers, and **release automation** via `googleapis/release-please-action` or `softprops/action-gh-release`.

## Example

```yaml
# .github/workflows/deploy.yml
name: deploy
on: { push: { branches: [main] } }
permissions:
  id-token: write   # required for OIDC
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production   # triggers required-reviewer gate
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gha-deploy
          aws-region: us-east-1
      - run: aws s3 sync ./dist s3://my-bucket
```

## Tips & gotchas

- Pin the OIDC trust policy's `sub` claim tightly (e.g. `repo:org/repo:ref:refs/heads/main`); a wildcard lets any branch assume the role.
- `secrets: inherit` on a reusable workflow call passes the *caller's* secrets — convenient, but it widens the blast radius. Prefer explicit `secrets:` mapping.
- Cache `key` must change when the lockfile does; hash it (`${{ hashFiles('**/package-lock.json') }}`) or you'll restore stale deps silently.
- Concurrency groups (`concurrency: { group: ${{ github.ref }}, cancel-in-progress: true }`) stop redundant runs and cut minutes on busy PRs.

## FAQ

**Can a reusable workflow call another reusable workflow?** Yes, but nesting is capped at 4 levels, and you can't use a matrix to call reusable workflows with `strategy` on the calling job in older setups — check the current limit.

**OIDC vs. a stored PAT/key?** OIDC issues a short-lived token per run and removes secret rotation entirely. Use stored secrets only for providers without an OIDC integration.

**Does release-please cut the release itself?** It opens/maintains a release PR from Conventional Commits; merging that PR tags the version and publishes the GitHub Release and changelog.