ci-cd-pipeline-builder

CI/CD Pipeline Builder

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "ci-cd-pipeline-builder" with this command: npx skills add borghei/claude-skills/borghei-claude-skills-ci-cd-pipeline-builder

CI/CD Pipeline Builder

Tier: POWERFUL Category: Engineering / DevOps Maintainer: Claude Skills Team

Overview

Generate production-grade CI/CD pipelines from detected project stack signals. Analyzes lockfiles, manifests, and scripts to produce optimized pipelines with proper caching, matrix strategies, security scanning, and deployment gates. Supports GitHub Actions, GitLab CI, CircleCI, and Buildkite with deployment strategies including blue-green, canary, and rolling updates.

Keywords

CI/CD, GitHub Actions, GitLab CI, pipeline, deployment, caching, matrix builds, blue-green deployment, canary deployment, security scanning, SAST, container builds, environment gates

Core Capabilities

  1. Stack Detection
  • Language/runtime detection from lockfiles and manifests

  • Package manager inference from lock file format

  • Build/test/lint command extraction from scripts

  • Framework detection (Next.js, FastAPI, Go modules, etc.)

  • Infrastructure detection (Docker, Kubernetes, Terraform)

  1. Pipeline Generation
  • Lint, test, build, deploy stages with correct dependencies

  • Caching strategies matched to package manager

  • Matrix builds for multi-version support

  • Artifact passing between jobs

  • Conditional execution (path filters, branch rules)

  1. Deployment Strategies
  • Blue-green with instant rollback

  • Canary with percentage-based traffic shifting

  • Rolling updates with health checks

  • Feature flags integration

  • Manual approval gates for production

  1. Security Integration
  • SAST scanning (CodeQL, Semgrep, Snyk)

  • Dependency vulnerability scanning

  • Container image scanning (Trivy, Grype)

  • Secret scanning in CI

  • SBOM generation

When to Use

  • Bootstrapping CI/CD for a new repository

  • Migrating between CI platforms

  • Optimizing slow or flaky pipelines

  • Adding deployment stages to an existing CI-only pipeline

  • Implementing security scanning in the pipeline

  • Setting up multi-environment deployment (staging, production)

Stack Detection Heuristics

File Found → Inference ───────────────────────────────────────────────── package-lock.json → Node.js + npm pnpm-lock.yaml → Node.js + pnpm yarn.lock → Node.js + yarn bun.lockb → Bun requirements.txt / Pipfile → Python + pip/pipenv pyproject.toml + uv.lock → Python + uv poetry.lock → Python + poetry go.mod → Go Cargo.lock → Rust Gemfile.lock → Ruby composer.lock → PHP next.config.* → Next.js (Node.js) nuxt.config.* → Nuxt (Node.js) Dockerfile → Container build needed docker-compose.yml → Multi-service setup terraform/*.tf → Infrastructure as Code k8s/ or kubernetes/ → Kubernetes deployment

GitHub Actions Pipeline Templates

Node.js (pnpm + Vitest + Next.js)

name: CI/CD

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

concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true

env: NODE_VERSION: '20' PNPM_VERSION: '9'

jobs: lint-and-typecheck: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: pnpm/action-setup@v4 with: version: ${{ env.PNPM_VERSION }} - uses: actions/setup-node@v4 with: node-version: ${{ env.NODE_VERSION }} cache: 'pnpm' - run: pnpm install --frozen-lockfile - run: pnpm lint - run: pnpm typecheck

test: runs-on: ubuntu-latest needs: lint-and-typecheck services: postgres: image: postgres:16 env: POSTGRES_USER: test POSTGRES_PASSWORD: test POSTGRES_DB: testdb ports: ['5432:5432'] options: >- --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5 steps: - uses: actions/checkout@v4 - uses: pnpm/action-setup@v4 with: version: ${{ env.PNPM_VERSION }} - uses: actions/setup-node@v4 with: node-version: ${{ env.NODE_VERSION }} cache: 'pnpm' - run: pnpm install --frozen-lockfile - run: pnpm test:ci env: DATABASE_URL: postgresql://test:test@localhost:5432/testdb

build: runs-on: ubuntu-latest needs: test steps: - uses: actions/checkout@v4 - uses: pnpm/action-setup@v4 with: version: ${{ env.PNPM_VERSION }} - uses: actions/setup-node@v4 with: node-version: ${{ env.NODE_VERSION }} cache: 'pnpm' - run: pnpm install --frozen-lockfile - run: pnpm build - uses: actions/upload-artifact@v4 with: name: build-output path: .next/ retention-days: 1

security-scan: runs-on: ubuntu-latest permissions: security-events: write steps: - uses: actions/checkout@v4 - uses: github/codeql-action/init@v3 with: languages: javascript-typescript - uses: github/codeql-action/analyze@v3

deploy-staging: if: github.ref == 'refs/heads/main' && github.event_name == 'push' needs: [build, security-scan] runs-on: ubuntu-latest environment: name: staging url: https://staging.myapp.com steps: - uses: actions/checkout@v4 - uses: actions/download-artifact@v4 with: name: build-output path: .next/ - name: Deploy to staging run: | # Replace with your deployment command echo "Deploying to staging..." env: DEPLOY_TOKEN: ${{ secrets.STAGING_DEPLOY_TOKEN }}

deploy-production: if: github.ref == 'refs/heads/main' && github.event_name == 'push' needs: deploy-staging runs-on: ubuntu-latest environment: name: production url: https://myapp.com steps: - uses: actions/checkout@v4 - uses: actions/download-artifact@v4 with: name: build-output path: .next/ - name: Deploy to production run: | echo "Deploying to production..." env: DEPLOY_TOKEN: ${{ secrets.PROD_DEPLOY_TOKEN }}

Python (uv + pytest + FastAPI)

name: CI/CD

on: push: branches: [main] pull_request:

jobs: lint: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: astral-sh/setup-uv@v4 - run: uv sync --frozen - run: uv run ruff check . - run: uv run ruff format --check . - run: uv run mypy src/

test: runs-on: ubuntu-latest needs: lint strategy: matrix: python-version: ['3.11', '3.12', '3.13'] services: postgres: image: postgres:16 env: POSTGRES_USER: test POSTGRES_PASSWORD: test POSTGRES_DB: testdb ports: ['5432:5432'] options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5 steps: - uses: actions/checkout@v4 - uses: astral-sh/setup-uv@v4 with: python-version: ${{ matrix.python-version }} - run: uv sync --frozen - run: uv run pytest --cov --cov-report=xml -v env: DATABASE_URL: postgresql://test:test@localhost:5432/testdb - uses: codecov/codecov-action@v4 if: matrix.python-version == '3.12' with: file: coverage.xml

build-container: needs: test runs-on: ubuntu-latest permissions: contents: read packages: write steps: - uses: actions/checkout@v4 - uses: docker/setup-buildx-action@v3 - uses: docker/login-action@v3 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - uses: docker/build-push-action@v6 with: context: . push: ${{ github.ref == 'refs/heads/main' }} tags: ghcr.io/${{ github.repository }}:${{ github.sha }} cache-from: type=gha cache-to: type=gha,mode=max

container-scan: needs: build-container if: github.ref == 'refs/heads/main' runs-on: ubuntu-latest steps: - uses: aquasecurity/trivy-action@master with: image-ref: ghcr.io/${{ github.repository }}:${{ github.sha }} severity: 'CRITICAL,HIGH' exit-code: '1'

Deployment Strategy Decision Framework

How critical is zero-downtime? │ ├─ Critical (payment processing, real-time systems) │ └─ BLUE-GREEN DEPLOYMENT │ Pro: Instant rollback, zero-downtime guaranteed │ Con: Requires 2x infrastructure during deployment │ ├─ Important but can tolerate brief errors │ ├─ Need to validate with real traffic first? │ │ └─ CANARY DEPLOYMENT │ │ Pro: Test with small % of traffic before full rollout │ │ Con: Complex routing, need observability for canary metrics │ │ │ └─ Standard web app with health checks │ └─ ROLLING UPDATE │ Pro: Simple, built into K8s/ECS, gradual rollout │ Con: Both versions serve traffic during rollout │ └─ Development/staging environment └─ RECREATE (stop old, start new) Pro: Simplest, cleanest Con: Brief downtime during deployment

Caching Strategy Reference

Package Manager Cache Path Key Pattern

npm ~/.npm

${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}

pnpm Detected by setup-node cache: 'pnpm' in setup-node

yarn ~/.cache/yarn

${{ runner.os }}-yarn-${{ hashFiles('yarn.lock') }}

pip ~/.cache/pip

${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}

uv ~/.cache/uv

Handled by setup-uv

Go ~/go/pkg/mod

${{ runner.os }}-go-${{ hashFiles('go.sum') }}

Cargo ~/.cargo/registry

${{ runner.os }}-cargo-${{ hashFiles('Cargo.lock') }}

Docker GHA cache cache-from: type=gha in build-push-action

Pipeline Optimization Techniques

  1. Path Filtering (Skip Unnecessary Runs)

on: push: paths: - 'src/' - 'tests/' - 'package.json' - 'pnpm-lock.yaml' paths-ignore: - '.md' - 'docs/' - '.github/ISSUE_TEMPLATE/**'

  1. Job Dependency Graph

lint ──────┐ ├──→ test ──→ build ──→ deploy-staging ──→ deploy-production typecheck ─┘ │ └──→ security-scan

  1. Matrix Strategy with Fail-Fast

strategy: fail-fast: true # cancel all if one fails matrix: node-version: [18, 20, 22] os: [ubuntu-latest] include: - node-version: 20 os: macos-latest # test one combo on macOS

GitLab CI Equivalent

stages:

  • validate
  • test
  • build
  • deploy

variables: NODE_VERSION: "20"

.node-setup: &node-setup image: node:${NODE_VERSION} cache: key: ${CI_COMMIT_REF_SLUG} paths: - node_modules/ - .pnpm-store/ before_script: - corepack enable - pnpm install --frozen-lockfile

lint: stage: validate <<: *node-setup script: - pnpm lint - pnpm typecheck

test: stage: test <<: node-setup services: - postgres:16 variables: POSTGRES_DB: testdb POSTGRES_USER: test POSTGRES_PASSWORD: test DATABASE_URL: postgresql://test:test@postgres:5432/testdb script: - pnpm test:ci coverage: '/All files[^|]|[^|]*\s+([\d.]+)/'

build: stage: build <<: *node-setup script: - pnpm build artifacts: paths: - .next/ expire_in: 1 hour

deploy_staging: stage: deploy environment: name: staging url: https://staging.myapp.com rules: - if: $CI_COMMIT_BRANCH == "main" script: - echo "Deploy to staging"

deploy_production: stage: deploy environment: name: production url: https://myapp.com rules: - if: $CI_COMMIT_BRANCH == "main" when: manual needs: [deploy_staging] script: - echo "Deploy to production"

Validation Checklist

Before merging a generated pipeline:

  • YAML parses without syntax errors

  • All referenced commands exist in the repository (test , lint , build )

  • Cache strategy matches the detected package manager

  • Required secrets are documented (not embedded in YAML)

  • Branch protection rules match organization policy

  • Deployment jobs are gated by protected environments

  • Security scanning runs on the appropriate code paths

  • Artifact retention is set (do not keep build artifacts indefinitely)

  • Concurrency group prevents duplicate runs on the same branch

  • Path filters exclude documentation-only changes from full CI runs

Common Pitfalls

  • Copying pipelines between projects without adapting to the actual stack

  • No concurrency control leading to redundant parallel runs on rapid pushes

  • Missing cache keys causing cache misses on every run (slow builds)

  • Running full matrix on every PR when only main needs multi-version testing

  • Hardcoding secrets in YAML instead of using CI secret stores

  • No path filtering so documentation changes trigger full build+test+deploy

  • Deploy jobs without environment gates allowing accidental production deployments

  • No artifact retention policy causing storage costs to grow indefinitely

Best Practices

  • Detect stack first, then generate pipeline — never guess at build commands

  • Keep the generated baseline under version control and customize incrementally

  • One optimization at a time — add caching, then matrix, then split jobs

  • Require green CI before any deployment job can execute

  • Use protected environments for production credentials and manual approval gates

  • Track pipeline duration and flakiness as first-class engineering metrics

  • Separate deploy jobs from CI jobs to keep feedback fast for developers

  • Regenerate the pipeline when the stack changes significantly (new language, new framework)

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

product-designer

No summary provided by upstream source.

Repository SourceNeeds Review
2.2K-borghei
General

business-intelligence

No summary provided by upstream source.

Repository SourceNeeds Review
General

brand-strategist

No summary provided by upstream source.

Repository SourceNeeds Review
General

senior-mobile

No summary provided by upstream source.

Repository SourceNeeds Review