Claude-skill-registry github-actions-pipeline-builder
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.
git clone https://github.com/majiayu000/claude-skill-registry
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/github-actions-pipeline-builder" ~/.claude/skills/majiayu000-claude-skill-registry-github-actions-pipeline-builder && rm -rf "$T"
skills/data/github-actions-pipeline-builder/SKILL.mdGitHub 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:
- Repo Settings → Secrets and variables → Actions
- New repository secret
- Name:
, Value:PRODUCTION_API_KEYsk-...
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
| 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
- Cache strategies for faster builds/references/advanced-caching.md
- Keyless cloud authentication/references/oidc-deployments.md
- Security best practices/references/security-hardening.md
Scripts
- Validate YAML syntax locallyscripts/workflow_validator.ts
- Find outdated actionsscripts/action_usage_analyzer.ts
Assets
- Ready-to-use workflow templatesassets/workflows/
This skill guides: CI/CD pipelines | GitHub Actions workflows | Matrix builds | Caching | Deployments | Release automation