github-actions-pipeline-builder

license	Apache-2.0
name	github-actions-pipeline-builder
description	Build production CI/CD pipelines with GitHub Actions. Implements matrix builds, caching, deployments, testing, security scanning. Use for automated testing, deployments, release workflows. Activate on "GitHub Actions", "CI/CD", "workflow", "deployment pipeline", "automated testing". NOT for Jenkins/CircleCI, manual deployments, or non-GitHub repositories.
allowed-tools	Read,Write,Edit,Bash
category	DevOps & Infrastructure
tags	["github-actions","ci-cd","pipeline","automation","workflows"]

GitHub Actions Pipeline Builder

Expert in building production-grade CI/CD pipelines with GitHub Actions that are fast, reliable, and secure.

When to Use

✅ Use for:

• Automated testing on every commit
• Deployment to staging/production
• Docker image building and publishing
• Release automation with versioning
• Security scanning and dependency audits
• Code quality checks (linting, type checking)
• Multi-environment workflows

❌ NOT for:

• Non-GitHub repositories (use Jenkins, CircleCI, etc.)
• Complex pipelines better suited for dedicated CI/CD tools
• Self-hosted runners (covered in advanced patterns)

Quick Decision Tree

Does your project need:
├── Testing on every PR? → GitHub Actions
├── Automated deployments? → GitHub Actions
├── Matrix builds (Node 16, 18, 20)? → GitHub Actions
├── Secrets management? → GitHub Actions secrets
├── Multi-cloud deployments? → GitHub Actions + OIDC
└── Sub-second builds? → Consider build caching

---

Technology Selection

GitHub Actions vs Alternatives

Why GitHub Actions in 2024:

• Native integration: No third-party setup
• Free for public repos: 2000 minutes/month for private
• Matrix builds: Test multiple versions in parallel
• Marketplace: 10,000+ pre-built actions
• OIDC support: Keyless cloud deployments

Timeline:

• 2019: GitHub Actions released
• 2020: Became standard for OSS projects
• 2022: OIDC support for secure cloud auth
• 2024: De facto CI/CD for GitHub repos

When to Use Alternatives

Scenario	Use	Why
Self-hosted GitLab	GitLab CI	Native integration
Complex enterprise workflows	Jenkins	More flexible
Bitbucket repos	Bitbucket Pipelines	Native integration
Extremely large repos (>10GB)	BuildKite	Better for monorepos

---

Common Anti-Patterns

Anti-Pattern 1: No Dependency Caching

Novice thinking: "Install dependencies fresh every time for consistency"

Problem: Wastes 2-5 minutes per build installing unchanged dependencies.

Wrong approach:

# ❌ Slow: Downloads all dependencies every run
- name: Install dependencies
  run: npm install

Correct approach:

# ✅ Fast: Cache dependencies, only download changes
- name: Cache node_modules
  uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

- name: Install dependencies
  run: npm ci  # Faster than npm install

Impact: Reduces install time from 3 minutes → 30 seconds.

Timeline:

• Pre-2020: Most workflows had no caching
• 2020+: Caching became standard
• 2024: Setup actions include built-in caching

---

Anti-Pattern 2: Duplicate YAML (No Matrix Builds)

Problem: Copy-paste workflows for different Node versions.

Wrong approach:

# ❌ Duplicated workflows
jobs:
  test-node-16:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 16
      - run: npm test

  test-node-18:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
      - run: npm test

  test-node-20:
    # ... same steps again

Correct approach:

# ✅ DRY: Matrix build
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [16, 18, 20]
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npm test

Benefits: 66% less YAML, tests run in parallel.

---

Anti-Pattern 3: Secrets in Code

Problem: Hardcoded API keys, tokens visible in repo.

Symptoms: Security scanner alerts, leaked credentials.

Correct approach:

# ✅ Use GitHub Secrets
- name: Deploy to production
  env:
    API_KEY: ${{ secrets.PRODUCTION_API_KEY }}
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY }}
  run: |
    ./deploy.sh

Setting secrets:

1. Repo Settings → Secrets and variables → Actions
2. New repository secret
3. Name: PRODUCTION_API_KEY, Value: sk-...

Timeline:

• Pre-2022: Some teams committed .env files
• 2022+: GitHub secret scanning blocks commits with keys
• 2024: OIDC eliminates need for long-lived credentials

---

Anti-Pattern 4: No Failure Notifications

Problem: CI fails silently, team doesn't notice for hours.

Correct approach:

# ✅ Slack notification on failure
- name: Notify on failure
  if: failure()
  uses: slackapi/slack-github-action@v1
  with:
    payload: |
      {
        "text": "❌ Build failed: ${{ github.event.head_commit.message }}",
        "blocks": [
          {
            "type": "section",
            "text": {
              "type": "mrkdwn",
              "text": "*Build Failed*\n<${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}|View logs>"
            }
          }
        ]
      }
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}

---

Anti-Pattern 5: Running All Tests on Every Commit

Problem: Slow feedback loop (10+ minute test suites).

Symptom: Developers avoid committing frequently.

Correct approach:

# ✅ Fast feedback: Run subset on PR, full suite on merge
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  quick-tests:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - run: npm run test:unit  # Fast: 2 minutes

  full-tests:
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - run: npm run test  # Slow: 10 minutes (unit + integration + e2e)

Alternative: Use changed-files action to run only affected tests.

---

Implementation Patterns

Pattern 1: Basic CI Pipeline

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Run type check
        run: npm run typecheck

      - name:  
          

        
           

Pattern 2: Multi-Environment Deployment

name: Deploy

on:
  push:
    branches:
      - main        # → staging
      - production  # → production

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: ${{ github.ref_name }}  # staging or production

    steps:
      - uses: actions/checkout@v3

      - name: Deploy to ${{ github.ref_name }}
        run: |
          if [ "${{ github.ref_name }}" == "production" ]; then
            ./deploy.sh production
          else
            ./deploy.sh staging
          fi
        env:
          API_KEY: ${{ secrets.API_KEY }}
          DATABASE_URL: ${{ secrets.DATABASE_URL }}

Pattern 3: Release Automation

name: Release

on:
  push:
    tags:
      - 'v*'  # Trigger on version tags (v1.0.0)

jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      contents: write  # Required for creating releases

    steps:
      - uses: actions/checkout@v3

      - name: Build artifacts
        run: npm run build

      - name: Create GitHub Release
        uses: softprops/action-gh-release@v1
        with:
          files: |
            dist/**
          body: |
            ## What's Changed
            See CHANGELOG.md for details.
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Publish to npm
        run: npm publish
        env:
             

Pattern 4: Docker Build & Push

name: Docker

on:
  push:
    branches: [main]

jobs:
  build-and-push:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Login to DockerHub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Build and push
        uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          tags: |
            myapp:latest
            myapp:${{ github.sha }}
          cache-from: type=gha
           

---

Production Checklist

□ Dependency caching configured
□ Matrix builds for multiple versions
□ Secrets stored in GitHub Secrets (not code)
□ Failure notifications (Slack, email, etc.)
□ Deploy previews for pull requests
□ Staging → Production promotion workflow
□ Release automation with versioning
□ Docker layer caching enabled
□ CODEOWNERS file for required reviews
□ Branch protection rules enabled
□ Status checks required before merge
□ Security scanning (Dependabot, CodeQL)

---

When to Use vs Avoid

Scenario	Use GitHub Actions?
GitHub-hosted repo	✅ Yes
Need matrix builds	✅ Yes
Deploying to AWS/GCP/Azure	✅ Yes (with OIDC)
GitLab repo	❌ No - use GitLab CI
Extremely large monorepo	⚠️ Maybe - consider BuildKite
Need GUI pipeline builder	❌ No - use Jenkins/Azure DevOps

---

References

• /references/advanced-caching.md - Cache strategies for faster builds
• /references/oidc-deployments.md - Keyless cloud authentication
• /references/security-hardening.md - Security best practices

Scripts

• scripts/workflow_validator.ts - Validate YAML syntax locally
• scripts/action_usage_analyzer.ts - Find outdated actions

Assets

• assets/workflows/ - Ready-to-use workflow templates

---

This skill guides: CI/CD pipelines | GitHub Actions workflows | Matrix builds | Caching | Deployments | Release automation