Konfiguracja CI/CD za pomocą Cursor Agent

Twój zestaw testów przechodzi lokalnie. Wypychasz na main. Piętnaście minut później Slack się rozświetla: build się nie powiódł. Komunikat błędu odnosi się do niezgodności wersji Node, która istnieje tylko w środowisku CI. Łączysz się przez SSH z runnerem, grzebiasz, naprawiasz problem, wypychasz ponownie. Teraz inny test się nie powodzi, ponieważ migracja bazy danych nie została uruchomiona. Dwie godziny twojego popołudnia przepadły — a nie napisałeś ani jednej linii kodu funkcjonalności.

Pipeline’y CI/CD to infrastruktura, którą większość deweloperów buduje raz, a potem boi się jej dotykać. Cursor Agent zmienia tę dynamikę, ponieważ może generować, debugować i iterować pliki workflow tak samo, jak obsługuje kod aplikacji.

Co wyniesiesz

• Kompletny workflow GitHub Actions wygenerowany przez Cursor, z etapami build, test, lint i deploy
• Workflow promptów do debugowania błędów CI bez wychodzenia z IDE
• Integrację Cursor CLI dla zautomatyzowanych workflow’ów code review i naprawiania CI
• Techniki generowania konfiguracji wdrożeń specyficznych dla środowiska
• Konfigurację reguł projektu, która utrzymuje świadomość Cursora o twoich konwencjach CI/CD

Generowanie pierwszego pipeline’u

Najszybszym sposobem na uzyskanie działającego pipeline’u jest podanie Cursor Agent pełnego kontekstu narzędzi twojego projektu i pozwolenie mu wygenerować plik workflow. Kluczem jest bycie konkretnym co do runtime’u, menedżera pakietów i celu wdrożenia.

Wskazówka

Prompt do skopiowania i wklejenia do generowania pipeline’u CI w GitHub Actions:

@package.json @tsconfig.json

Wygeneruj workflow GitHub Actions w .github/workflows/ci.yml dla tego projektu:

1. Wyzwalanie na push do main i na pull requesty do main
2. Użyj Node.js 22 na ubuntu-latest
3. Cachuj node_modules używając hashu package-lock.json
4. Uruchom te kroki po kolei: instalacja zależności, type-check, lint, test
5. Użyj npm ci do instalacji (nie npm install)
6. Ustaw 10-minutowy timeout na całym jobie
7. Dodaj grupę concurrency, która anuluje uruchomienia w toku dla tej samej gałęzi

Sprawdź skrypty w package.json, aby określić dokładne komendy dla type-check, lint i test.

Ten prompt działa, ponieważ odnosi się do rzeczywistych plików projektu. Agent odczytuje package.json, aby odkryć nazwy twoich skryptów (może to być npm run type-check zamiast npx tsc --noEmit), sprawdza tsconfig.json pod kątem konfiguracji TypeScript i generuje workflow, który pasuje do twojej rzeczywistej konfiguracji — nie generyczny szablon.

Po wygenerowaniu pliku przez Agent przejrzyj diff. Typowe problemy, na które należy uważać:

• Brakujące zmienne środowiskowe. Jeśli twoje testy potrzebują DATABASE_URL lub API_KEY, Agent nie będzie o tym wiedział, chyba że o tym wspominasz.
• Zła wersja Node. Agent może domyślnie użyć Node 20, gdy twój projekt używa 22. Pole engines w package.json tutaj pomaga.
• Brakujące usługi. Jeśli twoje testy potrzebują PostgreSQL lub Redis, musisz to określić w swoim prompcie.

Dodawanie usług bazodanowych

Dla projektów, które potrzebują bazy danych w CI:

@.github/workflows/ci.yml @docker-compose.yml

Zaktualizuj workflow CI, aby uwzględnić kontener usługi PostgreSQL 16. Krok testowy powinien:
1. Czekać, aż PostgreSQL będzie zdrowy przed uruchomieniem testów
2. Ustawić DATABASE_URL jako zmienną środowiskową wskazującą na kontener usługi
3. Uruchomić migracje bazy danych przed testami używając "npm run db:migrate"
4. Użyć tej samej nazwy bazy danych i poświadczeń co nasz docker-compose.yml

Zachowaj istniejące kroki w nienaruszonym stanie. Dodaj usługę i zmodyfikuj tylko krok testowy.

Dodawanie etapów wdrożeń

Gdy CI przechodzi, chcesz zautomatyzowanego wdrożenia. Wzorzec zależy od twojego celu, ale workflow Cursora jest ten sam: daj Agentowi kontekst wdrożenia i pozwól mu wygenerować konfigurację.

Wskazówka

Prompt do skopiowania i wklejenia do dodania wdrożenia do istniejącego workflow CI:

@.github/workflows/ci.yml

Dodaj job wdrożenia produkcyjnego do tego workflow, który:
1. Uruchamia się tylko na push do main (nie na PR-ach)
2. Zależy od przejścia joba CI
3. Wdraża na Cloudflare Workers używając wrangler
4. Używa CLOUDFLARE_API_TOKEN i CLOUDFLARE_ACCOUNT_ID z sekretów GitHub
5. Uruchamia "npm run build" przed wdrożeniem
6. Zawiera job preview deployment, który uruchamia się na PR-ach i dodaje URL preview jako komentarz do PR-a

Zachowaj istniejący job CI bez zmian. Dodaj nowe joby po nim.

Konfiguracje specyficzne dla środowiska

Dla zespołów, które wdrażają najpierw na staging przed produkcją:

@.github/workflows/ci.yml @wrangler.toml

Utwórz pipeline wdrożeń wielośrodowiskowych:
1. Job CI uruchamia się na wszystkich pushach i PR-ach (istniejący)
2. Wdrożenie na staging: uruchamia się na push do main po przejściu CI
   - Używa wrangler z --env staging
   - Uruchamia smoke testy przeciwko URL-owi staging po wdrożeniu
3. Wdrożenie na produkcję: ręczne wyzwalanie (workflow_dispatch) lub push tagu (v*)
   - Wymaga, aby wdrożenie staging się powiodło
   - Używa wrangler z --env production
   - Wysyła powiadomienie o wdrożeniu na webhook Slack

Użyj środowisk GitHub z regułami ochrony dla produkcji.

Debugowanie nieudanych buildów

To tutaj Cursor naprawdę błyszczy. Zamiast czytać surowe logi CI w zakładce przeglądarki, możesz wkleić wynik błędu bezpośrednio do Cursora i otrzymać praktyczne poprawki.

Gdy build się nie powiedzie, skopiuj odpowiedni wynik błędu z GitHub Actions. Przełącz się do trybu Ask w Cursorze:

Mój job CI GitHub Actions nie powiódł się z tym błędem:

Error: src/lib/utils.ts(15,3): error TS2322: Type 'string | undefined'
is not assignable to type 'string'.

Krok, który się nie powiódł, to "npm run type-check". Przechodzi lokalnie na moim komputerze.
Oto odpowiedni plik: @src/lib/utils.ts

Dlaczego to się nie powodzi w CI, ale nie lokalnie? Jak to naprawić?

Tryb Ask przeanalizuje plik i zidentyfikuje problem — często bardziej rygorystyczny tsconfig.json w CI, inna wersja TypeScript lub brakujące twierdzenie typu, które twój lokalny edytor milcząco ignorował. Gdy zrozumiesz problem, przełącz się do trybu Agent, aby zaimplementować poprawkę.

Zautomatyzowany workflow naprawiania CI

Cursor CLI wspiera potężny wzorzec: automatyczne naprawianie błędów CI w GitHub Actions. Możesz skonfigurować workflow, który wyzwala się, gdy twój zestaw testów się nie powiedzie i używa headless agenta Cursora do analizy i naprawienia problemu.

.github/workflows/fix-ci.yml

name: Fix CI Failures

on:
  workflow_run:
    workflows: [CI]
    types: [completed]

permissions:
  contents: write
  pull-requests: write
  actions: read

jobs:
  attempt-fix:
    if: >-
      ${{ github.event.workflow_run.conclusion == 'failure'
      && github.event.workflow_run.name != 'Fix CI Failures' }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install Cursor CLI
        run: |
          curl https://cursor.com/install -fsS | bash
          echo "$HOME/.cursor/bin" >> $GITHUB_PATH

      - name: Configure git
        run: |
          git config user.name "Cursor Agent"
          git config user.email "cursoragent@cursor.com"

      - name: Fix CI failure
        env:
          CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          agent -p "Przeanalizuj błąd CI dla workflow run
          ${{ github.event.workflow_run.id }} w repo ${{ github.repository }}.
          Użyj gh CLI, aby pobrać logi błędów. Zidentyfikuj nieudany PR.
          Wykonaj minimalne, celowane poprawki zgodne ze stylem repo.
          Utwórz branch naprawczy i wypchnij go. Dodaj komentarz do PR-a
          z linkiem do szybkiego utworzenia PR-a z brancha naprawczego." \
          --force --model claude-opus-4-6 --output-format=text

Jest to bezpośrednio wspierane przez oficjalny cookbook CLI Cursora. Agent odczytuje logi błędów, identyfikuje pierwotną przyczynę i tworzy branch naprawczy — wszystko bez interwencji człowieka. Warunek zabezpieczający zapobiega wyzwalaniu workflow naprawczego przez samego siebie w nieskończonej pętli.

Konfiguracja zautomatyzowanego code review w CI

Poza naprawianiem błędów możesz użyć Cursor CLI do automatycznego przeglądania każdego PR-a:

.github/workflows/code-review.yml

name: Cursor Code Review

on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          ref: ${{ github.event.pull_request.head.sha }}

      - name: Install Cursor CLI
        run: |
          curl https://cursor.com/install -fsS | bash
          echo "$HOME/.cursor/bin" >> $GITHUB_PATH

      - name: Review PR
        env:
          CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}
          GH_TOKEN: ${{ github.token }}
        run: |
          agent --force --model claude-opus-4-6 --print \
          "Przejrzyj PR #${{ github.event.pull_request.number }}.
          Pobierz diff z gh pr diff. Oznacz tylko problemy o wysokiej wadze.
          Max 10 komentarzy inline. Użyj gh pr review --comment."

Zablokuj to, co agent może zrobić, plikiem uprawnień:

.cursor/cli.json

{
  "permissions": {
    "deny": [
      "Shell(git push)",
      "Shell(gh pr create)",
      "Shell(gh pr merge)",
      "Write(**)"
    ]
  }
}

Notatka

Dla większości zespołów BugBot (zarządzana usługa przeglądania PR-ów Cursora) jest prostsza w konfiguracji i nie wymaga pliku workflow. Powyższe podejście CLI jest dla zespołów, które potrzebują niestandardowej logiki przeglądania — jak wymuszanie określonych wzorców architektonicznych lub sprawdzanie wymagań zgodności.

Reguły projektu dla CI/CD

Utwórz plik reguł, który utrzymuje świadomość Agenta o twoich konwencjach CI:

.cursor/rules/ci-cd.md

# Konwencje CI/CD

## GitHub Actions
- Wszystkie workflow'y znajdują się w .github/workflows/
- Użyj runnerów ubuntu-latest
- Zawsze cachuj node_modules z hashem package-lock.json
- Użyj npm ci, nigdy npm install
- Ustaw timeout-minutes na każdym jobie
- Użyj grup concurrency do anulowania starych uruchomień

## Wdrożenie
- Wdrożenia staging na push do main
- Wdrożenia produkcyjne na push tagu (v*) z ręcznym zatwierdzeniem
- Wszystkie wdrożenia używają Cloudflare Workers przez wrangler
- Sekrety są przechowywane w środowiskach GitHub, nie w sekretach na poziomie repozytorium

## Testowanie w CI
- Testy wymagają kontenera usługi PostgreSQL 16
- DATABASE_URL: postgresql://postgres:postgres@localhost:5432/test
- Uruchom migracje przed testami
- Wygeneruj raport pokrycia i prześlij jako artefakt

Gdy to się psuje

Agent generuje workflow z błędami składni YAML. Błędy wcięć to najczęstszy problem CI. Jeśli workflow nie może być parsowany, wklej błąd do trybu Ask: “Ten workflow GitHub Actions ma błąd składni YAML: [błąd]. Napraw wcięcia.” Agent doskonale radzi sobie z naprawianiem YAML, ponieważ może zobaczyć pełną strukturę.

Cachowanie nie działa i instalacje są wolne. Agent czasami generuje nieprawidłowe klucze cache lub ścieżki. Bądź precyzyjny: “Cachuj node_modules używając actions/cache z hashem package-lock.json jako kluczem. Ścieżka powinna być node_modules, nie ~/.npm.”

Krok wdrożenia uruchamia się, gdy nie powinien. Logika warunkowa w GitHub Actions (wyrażenia if:) jest trudna. Jeśli twoje wdrożenie uruchamia się na PR-ach, gdy powinno tylko na main, wklej workflow do trybu Ask: “W jakich warunkach uruchamia się job deploy? Chcę, aby uruchamiał się tylko na pushach do main.”

Brakuje sekretów w runnerze. Agent nie może uzyskać dostępu do konfiguracji sekretów GitHub. Gdy widzisz błędy typu CLOUDFLARE_API_TOKEN is not set, to problem konfiguracji w ustawieniach twojego repozytorium GitHub, nie problem z kodem.

Agent CLI Cursora wprowadza niezamierzone zmiany. Zawsze konfiguruj .cursor/cli.json z regułami deny dla destrukcyjnych operacji. Zapobiegaj git push --force, gh pr merge i Write(**) podczas uruchamiania agenta w środowiskach CI.

Co dalej

Code Review Skonfiguruj kompleksowe workflow'y przeglądania wzmocnione AI.

Monitoring Dodaj logowanie i obserwowalność do swojego pipeline'u wdrożeń.

DevOps Zarządzaj infrastrukturą jako kod obok swojej aplikacji.