# How to Generate CI/CD Configs with Cursor - Tool: Cursor - Difficulty: Intermediate - Time required: 15-20 min - Compatibility: Cursor Pro+, GitHub Actions / Azure DevOps / GitLab CI - Last updated: March 2026 ## TL;DR Generate CI/CD pipeline configurations with Cursor by referencing your project's package.json, Dockerfile, and test scripts as @file context. Use .cursorrules to specify your CI platform (GitHub Actions, Azure DevOps, GitLab CI), and prompt Composer to create complete YAML pipelines with build, test, lint, and deploy stages. ## Why Cursor Excels at CI/CD Configuration CI/CD pipeline configuration is repetitive YAML that follows predictable patterns, making it ideal for AI generation. Cursor can generate complete pipeline files for GitHub Actions, Azure DevOps, GitLab CI, and other platforms when given the right project context. The key is referencing your package.json, Dockerfile, and test configuration so Cursor knows your exact build commands, dependencies, and deployment targets. This tutorial covers the complete workflow from initial generation through debugging pipeline failures. ## Before you start - Cursor installed (Pro recommended for agent mode) - A project with a package.json or equivalent build config - A target CI/CD platform (GitHub Actions, Azure DevOps, or GitLab CI) - Basic understanding of CI/CD pipeline concepts ## Step-by-step guide ### 1. Add CI/CD rules to your project Create a .cursor/rules/cicd.mdc file that specifies your CI/CD platform, deployment targets, and pipeline conventions. This ensures Cursor generates valid YAML for your specific platform and follows your team's conventions for stage naming, caching, and secrets management. ``` --- description: CI/CD pipeline generation rules globs: ".github/workflows/**, azure-pipelines.yml, .gitlab-ci.yml" alwaysApply: false --- - CI platform: GitHub Actions - Node.js version: 22 - Package manager: pnpm (use pnpm/action-setup@v4) - Always cache node_modules using actions/cache - Run in this order: install → lint → typecheck → test → build → deploy - Use matrix strategy for Node 20 and 22 - Secrets are in GitHub Settings, reference with ${{ secrets.NAME }} - Never hardcode secrets in YAML - Add step-level comments explaining what each step does - Use concurrency groups to cancel redundant runs ``` > Pro tip: If you use Azure DevOps instead of GitHub Actions, change the platform line and Cursor will switch to azure-pipelines.yml syntax with pool, stages, and tasks instead of jobs and steps. **Expected result:** CI/CD rules auto-attach whenever you edit pipeline configuration files. ### 2. Generate a complete pipeline with Composer Open Composer with Cmd+I and reference your project configuration files. Ask Cursor to generate a complete pipeline. The more context files you reference, the more accurate the generated YAML will be. Always include package.json for build commands and any Dockerfile for containerized deployments. ``` // Prompt to type in Cursor Composer (Cmd+I): // @package.json @Dockerfile @tsconfig.json @vitest.config.ts // Generate a GitHub Actions CI/CD workflow at .github/workflows/ci.yml // Requirements: // - Trigger on push to main and pull requests // - Install deps with pnpm, cache node_modules // - Run: pnpm lint, pnpm typecheck, pnpm test -- --coverage // - Build: pnpm build // - Deploy to Vercel on main branch only (use VERCEL_TOKEN secret) // - Cancel in-progress runs for the same branch // - Add comments explaining each step ``` > Pro tip: Reference @vitest.config.ts or @jest.config.js so Cursor knows the exact test command and can add proper coverage reporting steps. **Expected result:** Cursor generates a complete .github/workflows/ci.yml file with all specified stages and proper caching. ### 3. Review and refine the generated pipeline Open Chat with Cmd+L and ask Cursor to review the generated pipeline for common issues. Reference the generated YAML file. Cursor will identify missing caching, incorrect action versions, redundant steps, and security issues like exposed secrets. ``` // Prompt to type in Cursor Chat (Cmd+L): // @.github/workflows/ci.yml // Review this GitHub Actions workflow for: // 1. Outdated action versions (should use latest stable) // 2. Missing cache configuration // 3. Security issues (hardcoded secrets, excessive permissions) // 4. Missing concurrency controls // 5. Unnecessary steps that slow down the pipeline // List each issue with the fix. ``` **Expected result:** Cursor identifies specific issues in the pipeline YAML with line-by-line recommendations. ### 4. Generate an Azure DevOps pipeline variant If your team uses Azure DevOps, use Cmd+K to convert the GitHub Actions workflow to Azure Pipelines syntax. Select the entire YAML file, press Cmd+K, and ask for the conversion. Cursor understands the mapping between platforms. ``` // Select the entire .github/workflows/ci.yml content, // then press Cmd+K and type: // Convert this GitHub Actions workflow to Azure DevOps // azure-pipelines.yml format. Use: // - vmImage: 'ubuntu-latest' // - task: NodeTool@0 for Node.js setup // - script steps for pnpm commands // - stages: Build, Test, Deploy // - condition: succeeded() for deployment gate ``` > Pro tip: You can also ask Cursor to generate GitLab CI (.gitlab-ci.yml) using the same conversion approach. Just specify the target platform. **Expected result:** The GitHub Actions YAML is converted to valid Azure DevOps pipeline syntax with equivalent stages. ### 5. Debug pipeline failures with Cursor When a pipeline fails, copy the error output from your CI/CD dashboard and paste it into Cursor Chat. Reference the pipeline YAML file and ask Cursor to diagnose and fix the issue. Cursor is particularly effective at fixing YAML syntax errors and missing dependency issues. ``` // Prompt to type in Cursor Chat (Cmd+L): // @.github/workflows/ci.yml // My CI pipeline failed with this error: // [paste the full error output from GitHub Actions] // Diagnose the root cause and provide the exact fix. // Show me the corrected YAML for the failing step. ``` > Pro tip: Use the @web context to have Cursor search for the specific error message online. Type: '@web [error message] GitHub Actions fix' for the latest solutions. **Expected result:** Cursor identifies the pipeline failure cause and provides the corrected YAML configuration. ## Complete code example File: `.github/workflows/ci.yml` ```yaml name: CI/CD Pipeline on: push: branches: [main] pull_request: branches: [main] concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true jobs: build-and-test: runs-on: ubuntu-latest strategy: matrix: node-version: [20, 22] steps: # Checkout repository code - uses: actions/checkout@v4 # Install pnpm package manager - uses: pnpm/action-setup@v4 with: version: 9 # Setup Node.js with caching - uses: actions/setup-node@v4 with: node-version: ${{ matrix.node-version }} cache: 'pnpm' # Install dependencies - run: pnpm install --frozen-lockfile # Run linting checks - run: pnpm lint # Run TypeScript type checking - run: pnpm typecheck # Run tests with coverage - run: pnpm test -- --coverage # Build the project - run: pnpm build # Upload coverage report - uses: actions/upload-artifact@v4 if: matrix.node-version == 22 with: name: coverage-report path: coverage/ deploy: needs: build-and-test runs-on: ubuntu-latest if: github.ref == 'refs/heads/main' && github.event_name == 'push' steps: - uses: actions/checkout@v4 - name: Deploy to Vercel uses: amondnet/vercel-action@v25 with: vercel-token: ${{ secrets.VERCEL_TOKEN }} vercel-org-id: ${{ secrets.VERCEL_ORG_ID }} vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }} vercel-args: '--prod' ``` ## Common mistakes - **Not referencing package.json when generating pipeline YAML** — Without package.json context, Cursor guesses at build commands and scripts, often generating npm commands when you use pnpm or yarn. Fix: Always include @package.json in your pipeline generation prompt so Cursor uses your exact script names and package manager. - **Hardcoding secret values in generated YAML** — Cursor may generate placeholder secret values that look real. Committing these to Git exposes them publicly. Fix: Add a .cursorrules entry: 'Never hardcode secrets in YAML — always use ${{ secrets.NAME }} syntax.' Review all generated YAML for hardcoded values before committing. - **Using outdated GitHub Action versions** — Cursor's training data may reference older action versions. Using deprecated versions (actions/checkout@v2) misses security fixes and features. Fix: Add a rule specifying current action versions: 'Use actions/checkout@v4, actions/setup-node@v4, actions/cache@v4.' - **Missing cache configuration in generated pipelines** — Uncached pipelines reinstall all dependencies on every run, adding 2-5 minutes per build and increasing CI costs. Fix: Explicitly request caching in your prompt and verify the cache key includes the lockfile hash. ## Best practices - Reference package.json, Dockerfile, and test config files when generating pipeline YAML - Create a .cursor/rules/cicd.mdc with auto-attaching globs for workflow files - Specify exact CI/CD platform and action versions in your rules to prevent outdated syntax - Use concurrency groups to cancel in-progress runs when new commits push to the same branch - Add step-level comments in pipeline YAML so future developers understand each stage - Test pipeline changes in a feature branch before merging to main - Use Cursor Chat to debug pipeline failures by pasting CI error output directly into the prompt ## Frequently asked questions ### Can Cursor deploy my application directly? No. Cursor generates and edits pipeline configuration files but does not execute deployments. The generated YAML runs in your CI/CD platform (GitHub Actions, Azure DevOps, etc.) which handles the actual deployment. ### How do I set up CI/CD for a Cursor project? Open Composer (Cmd+I), reference @package.json and other config files, and prompt Cursor to generate a workflow file for your CI platform. Commit the generated YAML and configure secrets in your CI platform's settings dashboard. ### Can Cursor fix a failing pipeline automatically? Yes, with the MCP GitHub integration, Cursor can push fixes and iterate through build cycles. Without MCP, paste the CI error output into Chat (Cmd+L) with the pipeline YAML referenced, and Cursor will provide the fix to apply manually. ### Does Cursor support Azure DevOps pipelines? Yes. Specify 'Azure DevOps' in your .cursorrules or prompt, and Cursor generates azure-pipelines.yml with proper stages, pools, tasks, and conditions. You can also convert existing GitHub Actions workflows to Azure format. ### How do I handle secrets in Cursor-generated pipelines? Cursor cannot access or create CI secrets. It generates references like ${{ secrets.VERCEL_TOKEN }} in YAML. You must manually configure the actual secret values in your CI platform's settings. Add a rule requiring secrets syntax in .cursorrules. ### Can Cursor generate multi-stage Docker builds for CI? Yes. Reference @Dockerfile and @package.json and ask Cursor to generate a multi-stage Dockerfile with separate build and production stages. Then generate a CI pipeline that builds and pushes the Docker image. --- Source: https://www.rapidevelopers.com/cursor-tutorial/how-to-instruct-cursor-ai-to-generate-yaml-pipelines-for-ci-cd-in-azure-devops © RapidDev — https://www.rapidevelopers.com/cursor-tutorial/how-to-instruct-cursor-ai-to-generate-yaml-pipelines-for-ci-cd-in-azure-devops