Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
erichowens avatar

Github Actions Pipeline Builder

  • 138 installs
  • 178 repo stars
  • Updated July 14, 2026
  • erichowens/some_claude_skills

Author GitHub Actions workflows that lint, test, build, and deploy on every push or PR, with caching, matrix jobs, secrets, and environment gates for reliable releases.

About

Helps design and implement GitHub Actions pipelines: trigger rules, job graphs, caching, test and build stages, deployment workflows, secret handling, and reusable workflow patterns for dependable continuous integration and delivery.

  • Workflow YAML scaffolding for common stacks
  • Matrix builds across OS and runtime versions
  • Reusable actions and composite steps
  • Secrets, environments, and approval gates
  • Artifact upload and deploy job patterns

Github Actions Pipeline Builder by the numbers

  • 138 all-time installs (skills.sh)
  • Ranked #475 of 1,435 DevOps & CI/CD skills by installs in the Skillselion catalog
  • Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/erichowens/some_claude_skills --skill github-actions-pipeline-builder

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs138
repo stars178
Last updatedJuly 14, 2026
Repositoryerichowens/some_claude_skills

What it does

Author GitHub Actions workflows that lint, test, build, and deploy on every push or PR, with caching, matrix jobs, secrets, and environment gates for reliable releases.

Files

SKILL.mdMarkdownGitHub ↗

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

ScenarioUseWhy
Self-hosted GitLabGitLab CINative integration
Complex enterprise workflowsJenkinsMore flexible
Bitbucket reposBitbucket PipelinesNative integration
Extremely large repos (>10GB)BuildKiteBetter 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: Run tests
        run: npm test

      - name: Build
        run: npm run build

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:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

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
          cache-to: type=gha,mode=max

---

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

ScenarioUse 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

Related skills

DevOps & CI/CDdevopstesting

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.