Design and secure production-grade GitHub Actions workflows

Provides production-grade guidance for designing, debugging, and securing GitHub Actions workflows across nine areas: security hardening (declare least-privilege permissions: at workflow and job level, pin third-party actions to a full commit SHA rather than a mutable tag, route PR-controlled values like a title through env: instead of interpolating ${{ }} directly into run: to prevent script injection, gate pull_request_target behind a label plus author_association check since it runs with repo secrets, and add step-security/harden-runner to monitor egress); reusable workflows (workflow_call with typed inputs/secrets/outputs, an _-prefix naming convention, secrets: inherit versus explicit passing); matrix builds (exclude/include overrides, a dynamic matrix generated from a script's $GITHUB_OUTPUT); caching (language-specific setup-* actions' built-in cache, manual actions/cache with restore-keys fallbacks, Docker layer caching via type=gha); OIDC keyless cloud authentication for AWS, GCP, and Azure so no long-lived credentials are stored as secrets; environment protection rules (required reviewers, wait timers, branch restrictions); secrets management (environment-over-repo-over-org precedence, ::add-mask:: for dynamic values, passing secrets to composite actions via env: since they can't be passed as inputs); composite actions; self-hosted runners (label matching, Actions Runner Controller for ephemeral runners, isolating them from fork PRs); and conditional execution with job-output chaining.

- env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: echo "$PR_TITLE"

Use it for anything touching .github/workflows - designing a new pipeline, debugging a failing one, or hardening an existing one for production. It routes explicitly elsewhere: GitLab CI to gitlab-ci-patterns, other CI platforms like CircleCI or Jenkins are out of scope entirely, pure Docker image building without GitHub context to docker-expert, and Kubernetes deployment configuration to kubernetes-architect. Before responding it inspects the actual repo - existing workflows, composite actions, and the tech stack (package.json, requirements.txt, go.mod, and similar) - to tailor recommendations rather than giving generic YAML. An eight-row "Common Pitfalls & Fixes" table catches specific failure classes: a workflow not triggering on a fork PR because fork PRs get a restricted GITHUB_TOKEN, a "masked" secret that's actually exposed because a dynamically-generated value was never passed through ::add-mask::, a cache that never hits across branches because its key is too specific, a matrix job silently cancelling its siblings under the default fail-fast: true, a job hanging forever with no timeout-minutes, use of the deprecated set-output command instead of $GITHUB_OUTPUT, an OIDC token request failing from a missing id-token: write permission, and a reusable workflow unable to reach the caller's secrets without secrets: inherit.

Output is complete, runnable workflow YAML for four production pipeline patterns: build-test-push-deploy with SLSA provenance: true and sbom: true on the pushed image and staged staging-then-production deploys gated by GitHub Environments, automated release-with-changelog on a version tag, scheduled dependency auto-update opening a PR, and a security-scanning pipeline combining CodeQL and Trivy with SARIF upload to the Security tab. Every example pins third-party actions to a commit SHA with the version in a trailing comment. A closing four-section Production Readiness Checklist - Security, Reliability, Performance, Maintainability, roughly 18 items total - is meant to gate any workflow before it merges to main.

Names the specific actions and CLIs for each concern: aws-actions/configure-aws-credentials, google-github-actions/auth, and azure/login for OIDC; docker/build-push-action with type=gha cache; step-security/harden-runner for egress monitoring; github/codeql-action and aquasecurity/trivy-action for security scanning; softprops/action-gh-release and peter-evans/create-pull-request for release and dependency-update automation; and Actions Runner Controller, a Helm chart, for ephemeral self-hosted runners on Kubernetes. It cross-references four sibling skills: gha-security-review for a deeper audit, github-actions-templates for copy-paste starting points, docker-expert, and kubernetes-architect.

DevOps engineers and developers designing, debugging, or hardening GitHub Actions CI/CD pipelines who want production-grade, SHA-pinned, least-privilege workflow patterns and the specific pitfalls that cause silent failures, rather than assembling YAML from scattered docs.