Build & Secure GitHub Actions CI/CD Pipelines

This skill guides building GitHub Actions CI/CD pipelines with proper structure and best practices. It covers core workflow syntax (triggers like push, pull_request, and workflow_dispatch with typed inputs, path filters, and workflow-level env variables), job dependencies via needs, and matrix strategies (strategy.matrix across OS and language versions with fail-fast: false and include overrides for extra combinations).

Security guidance covers scoped permissions blocks (contents: read, packages: write), OIDC-style AWS credential configuration (aws-actions/configure-aws-credentials with role-to-assume), and container vulnerability scanning with aquasecurity/trivy-action producing SARIF output. Performance optimization covers dependency and Docker-layer caching with actions/cache keyed on lockfile hashes and restore-keys fallbacks. Conditional execution patterns use dorny/paths-filter to detect which parts of a monorepo changed and gate backend/frontend deploy jobs accordingly, plus environment-based conditionals (github.ref == 'refs/heads/main' && 'production' || 'staging').

jobs:
  deploy:
    needs: [test, build]
    if: github.ref == 'refs/heads/main'
    environment: production
    runs-on: ubuntu-latest

Error handling covers retry logic (nick-invision/retry with max_attempts), always-run artifact uploads (if: always()), and failure notifications (8398a7/action-slack on if: failure()). Reusability is covered through workflow_call-triggered reusable workflows with typed inputs, secrets, and outputs, plus advanced patterns like concurrency groups to prevent overlapping deployments and dynamic matrix generation from a prior job's JSON output (fromJson(needs.setup.outputs.matrix)).

Use this skill when building or hardening a GitHub Actions pipeline that needs matrix testing across environments, security scanning and least-privilege permissions, dependency/build caching, monorepo-aware conditional deploys, retry/notification handling, or reusable workflow components shared across repos. It is well suited to teams standardizing CI/CD conventions across multiple services.

It is not the right fit for a trivial single-job workflow (e.g. running one linter on every push) where the full matrix/caching/reusable-workflow machinery would be unnecessary overhead, or for CI systems other than GitHub Actions, since the syntax and actions referenced here are GitHub-specific.

Input: the project's build/test/deploy requirements (languages/OS matrix, security scanning needs, caching targets, deployment environments and conditions, notification channels). Output: one or more .github/workflows/*.yml files defining triggers, jobs with dependencies and matrix strategies, scoped permissions, caching steps, conditional deploy jobs, error-handling steps (retry, artifact upload, failure notification), and optionally a reusable workflow_call workflow consumed by other pipelines.

Built on GitHub Actions' native YAML workflow syntax and marketplace actions: actions/checkout, actions/setup-node, actions/cache, actions/upload-artifact, aws-actions/configure-aws-credentials, aquasecurity/trivy-action, dorny/paths-filter, nick-invision/retry, and 8398a7/action-slack for Slack notifications.

DevOps and platform engineers building or maintaining CI/CD pipelines on GitHub Actions - particularly teams needing matrix testing, security scanning, monorepo-aware conditional builds, and reusable workflow components across multiple repositories.