CI/CD Pipeline Conventions

ci-cddevopsgithub-actions

Conventions for writing reliable, fast, and maintainable CI/CD pipelines in GitHub Actions and GitLab CI, covering job structure, caching, secrets, and deployment patterns.

Целевые файлы

Файл	Формат
.cursorrules	plaintext
CLAUDE.md	markdown

Содержимое

# CI/CD Pipeline Conventions ## Workflow/Pipeline Structure - Organize workflows by trigger and purpose: `ci.yml` (PRs), `release.yml` (tags), `deploy.yml` (manual/scheduled). - Each workflow should have a clear `name:` that describes its purpose. - Structure jobs in stages: lint → test → build → deploy. Each stage depends on the previous. - Keep individual jobs focused: one job = one concern. Avoid monolithic jobs that do everything. ## GitHub Actions Specifics - Pin action versions to a full SHA for security: `actions/checkout@v4` is acceptable; `actions/checkout@abc1234` is safest for critical workflows. - Use `actions/checkout@v4` with `fetch-depth: 0` only when you need full git history (e.g., changelog generation). - Always define `permissions:` explicitly at workflow or job level — use the principle of least privilege. - Use `concurrency:` groups to cancel superseded runs on the same branch. ## Job Design - Set `timeout-minutes` on every job to prevent hung runners from consuming quota. - Use `if:` conditions to skip jobs when not relevant (e.g., skip deploy on draft PRs). - Use `continue-on-error: true` only for non-critical jobs (e.g., code coverage upload). - Use `strategy.matrix` for cross-platform or multi-version testing. Keep matrix small — prefer testing critical combinations. ## Caching - Cache package manager directories: `~/.npm`, `~/.pnpm-store`, `~/.cache/pip`, `~/.gradle/caches`. - Include the lockfile in the cache key: `key: ${{ runner.os }}-pnpm-${{ hashFiles('**/pnpm-lock.yaml') }}`. - Add a restore-key without the lockfile hash as fallback: `restore-keys: ${{ runner.os }}-pnpm-`. - Cache build artifacts between jobs using `actions/cache` or `actions/upload-artifact` + `download-artifact`. ## Secrets Management - Never hardcode secrets in workflow files. Use `${{ secrets.MY_SECRET }}` references only. - Prefix environment-specific secrets: `PROD_DATABASE_URL`, `STAGING_API_KEY`. - Use environment protection rules (GitHub) or protected variables (GitLab) for production secrets. - Rotate secrets immediately if they appear in CI logs. Treat any logged secret as compromised. - Use OIDC authentication to cloud providers (AWS, GCP, Azure) instead of long-lived access keys. ## Linting & Testing Jobs - Run linting before tests — fast feedback on style errors before slow test suites. - Run tests in parallel where possible. Use test sharding for large suites. - Upload test results as artifacts for failed runs: `if: failure()`. - Enforce coverage thresholds as a CI gate — fail the job if coverage drops below the threshold. ## Build & Artifact Management - Build artifacts once per pipeline. Upload with `actions/upload-artifact` and download in deploy jobs. - Tag Docker images with both the git SHA and a semantic version tag on release. - Push to a container registry only after all tests pass — never push from a failing pipeline. - Use multi-stage Docker builds in CI; build the target stage explicitly: `--target production`. ## Deployment - Use deployment environments with protection rules for staging and production. - Implement blue-green or rolling deploys — never deploy directly to production with downtime. - Run smoke tests after deployment. Roll back automatically on failure. - Deploy to staging on every merge to main; deploy to production on explicit tag or manual approval. ## Anti-Patterns - Do not use `set -x` in CI scripts that handle secrets — it prints values to logs. - Do not run CI as root in containers — use a non-root user. - Do not install dependencies without lockfile validation: always use `--frozen-lockfile` / `--ci` flags. - Do not skip the test job when "only docs changed" without explicit path filters. - Do not use `self-hosted runners` for public repos without strict network isolation.

CLI

npx mindaxis apply ci-cd-rules --target cursor --scope project

Используется в паках

DevOps Pipeline

CI/CD and deployment automation

Открыть пак →

← Правила