Automatyzacja Pipeline z AI

CI twojego monorepo uruchamia każde zadanie przy każdym pushu. Jednolinijkowa edycja README wyzwala 38-minutowy build wszystkich sześciu serwisów, zadanie testowe staje się czerwone w 30% przypadków na tych samych trzech niestabilnych specach, a piątkowe wdrożenie na Cloudflare Workers wprowadziło regresję, której nikt nie wyłapał, dopóki nie zaczęły spływać zgłoszenia od supportu. Nie potrzebujesz „samonaprawiających się pipeline napędzanych przez AI” — potrzebujesz, żeby build uruchamiał tylko to, co się zmieniło, niestabilne testy były poddane kwarantannie, a wdrożenie samo się wycofywało, gdy wskaźniki błędów skaczą w górę.

Ten artykuł pokazuje konkretny workflow, dzięki któremu agent AI napisze te zmiany w pipeline za ciebie — we wszystkich trzech narzędziach, wraz z prawdziwym kodem YAML GitHub Actions, który produkują.

Co Z Tego Wyniesiesz

• Zadanie wykrywania zmian dorny/paths-filter, które pomija nietknięte serwisy (i prompt, który je generuje)
• Workflow triage niestabilnych testów: podajesz agentowi nieudane uruchomienie, dostajesz listę kwarantanny i politykę ponawiania prób
• Progresywne wdrożenie na Cloudflare Workers z wrangler versions + stopniowym rolloutem i automatycznym rollbackiem
• Gotowe do skopiowania prompty dla każdego z nich, dostrojone pod Cursor, Claude Code i Codex
• Tryby awarii, które dają o sobie znać, gdy pozwolisz agentowi edytować CI, oraz jak z nich wyjść

Workflow: Buildy Świadome Zmian

Pojedyncza zmiana w CI o największej dźwigni w monorepo to przestać budować wszystko. dorny/paths-filter czyta diff i ustawia wyjścia per-ścieżka, na których bramkujesz zadania. Poproś agenta, żeby napisał filtr pod twój rzeczywisty układ katalogów, a nie pod szablon.

Agent powinien wyprodukować coś takiego — prawdziwe, uruchamialne zadanie, a nie jego opis:

.github/workflows/ci.yml

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  changes:
    runs-on: ubuntu-latest
    outputs:
      api: ${{ steps.filter.outputs.api }}
      web: ${{ steps.filter.outputs.web }}
    steps:
      - uses: actions/checkout@v5
      - uses: dorny/paths-filter@v3
        id: filter
        with:
          filters: |
            api:
              - 'services/api/**'
              - 'packages/shared/**'
            web:
              - 'services/web/**'
              - 'packages/shared/**'

  test-api:
    needs: changes
    if: ${{ needs.changes.outputs.api == 'true' }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - run: npm ci && npm run test --workspace=services/api

Zwróć uwagę, że packages/shared/** pojawia się pod oboma filtrami: zmiana w kodzie współdzielonym poprawnie przebudowuje obu konsumentów. To mapowanie zależności krzyżowych jest dokładnie tym, co chcesz, żeby agent wywnioskował z twojego repo, zamiast utrzymywać je ręcznie.

Interakcja różni się w zależności od narzędzia. Cursor edytuje YAML w miejscu, w edytorze; Claude Code działa headless w terminalu i potrafi zweryfikować wynik za pomocą gh; Codex uruchamia ten sam prompt jako nieinteraktywne zadanie exec albo jako zadanie Cloud wywodzące się ze zgłoszenia na GitHubie.

Cursor

W trybie Agent otwórz repo i wskaż mu rzeczywisty układ. Cursor czyta workspaces z package.json oraz drzewo services/, a następnie zapisuje .github/workflows/ci.yml jako diff w miejscu, który przeglądasz przed zaakceptowaniem:

Add a changes job using dorny/paths-filter@v3 to .github/workflows/ci.yml. Derive one filter per package in my workspaces array, and make every filter also match packages/shared/**. Gate each existing test job behind its matching needs.changes.outputs.* value. Use actions/checkout@v5.

Użyj checkpointu przed zaakceptowaniem, żeby móc cofnąć całą edycję jednym kliknięciem, jeśli bramkowanie okaże się błędne.

Claude Code

Uruchom to headless z katalogu głównego repo, żeby Claude Code mógł obejrzeć drzewo i zweryfikować wynik za pomocą GitHub CLI:

claude "Read package.json workspaces and the services/ directory, then rewrite \
.github/workflows/ci.yml to add a dorny/paths-filter@v3 'changes' job. One filter \
per workspace, each also matching packages/shared/**, and gate every test job behind \
its needs.changes.outputs.* flag."

# Validate the YAML parses and lists the new job before you push
gh workflow view ci.yml

Do wielokrotnego użytku opakuj prompt we własną komendę slash (.claude/commands/affected.md) i uruchamiaj ją ponownie za każdym razem, gdy dodasz serwis.

Codex

Codex uruchamia to samo zadanie nieinteraktywnie. Lokalnie ogranicz go do workspace, żeby mógł edytować pliki, ale nie dotykał twojego shella:

codex exec --sandbox workspace-write \
  "Rewrite .github/workflows/ci.yml: add a dorny/paths-filter@v3 changes job with one \
filter per npm workspace (each also matching packages/shared/**), and gate each test \
job on its needs.changes.outputs.* flag."

Żeby uruchomić to jako zadanie Cloud wywodzące się ze zgłoszenia na GitHubie, wyślij je do swojego środowiska Codex za pomocą codex cloud exec --env <ENV_ID> "..." (środowiska wylistujesz przez codex cloud). Codex otworzy gałąź i PR z wyedytowanym workflow.

Gotowy prompt: CI monorepo świadome zmian

Użyj go dosłownie w dowolnym z trzech narzędzi. Jest opiniotwórczy co do wersji akcji i pułapki współdzielonego pakietu, więc otrzymasz uruchamialny wynik, a nie szkic:

Read my package.json workspaces field and the services/ directory. Rewrite .github/workflows/ci.yml to add a changes job using dorny/paths-filter@v3 with actions/checkout@v5. Create one output filter per workspace, and make EVERY filter also match packages/shared/** so shared-code changes rebuild all dependents. Gate each existing build/test/lint job behind if: ${{ needs.changes.outputs.<name> == 'true' }} and add needs: changes. Do not change the steps inside the jobs. Show me the final file as a diff.

Workflow: Triage Niestabilnych Testów

Niestabilne testy nie potrzebują „analizatora stabilności” napędzanego przez AI — potrzebują kogoś, kto przejrzy ostatnie N uruchomień, znajdzie speki zawodzące niedeterministycznie, podda je kwarantannie i otworzy zgłoszenie. Tym „kimś” może być agent, bo potrafi czytać logi nieudanego uruchomienia bezpośrednio przez serwer GitHub MCP.

Serwer GitHub MCP to zdalny endpoint Streamable HTTP. Zainstaluj go raz — konfiguracja jest identyczna we wszystkich trzech narzędziach, bo MCP to wspólny standard:

claude mcp add --transport http github https://api.githubcopilot.com/mcp/

Po podłączeniu agent może pobrać logi nieudanego zadania, zamiast żebyś kopiował-wklejał je ręcznie. Sedno tkwi w różnicy „przed/po”: bez serwera MCP wklejasz zrzut logu; z nim mówisz „ostatnie uruchomienie CI na tym PR”, a agent sam pobiera adnotacje, nazwy zawodzących speków i otaczający output.

Cursor

W trybie Agent z włączonym serwerem GitHub MCP odwołaj się do nieudanego uruchomienia i pozwól Cursorowi pobrać logi, a następnie zaproponować diff kwarantanny dla twojej konfiguracji testów:

The last CI run on this branch failed. Pull the failing job’s logs via the GitHub MCP server, list the specs that fail intermittently (passing on retry), and mark them with test.skip plus a // FLAKY: <run-url> comment. Open a checklist of what you skipped.

Claude Code

Claude Code potrafi sterować GitHub CLI bezpośrednio, więc tutaj nawet nie potrzebujesz koniecznie serwera MCP — przekieruj nieudany log prosto do niego:

gh run view --log-failed | claude "These are the failing jobs from our latest CI run. \
Identify which Vitest specs are flaky (timeouts, race conditions, order-dependence) \
versus genuinely broken. For the flaky ones, output a vitest.config.ts 'retry: 2' \
setting and a list of describe blocks to move into a @flaky tag we exclude from \
required checks."

Codex

Uruchom triage jako nieinteraktywne zadanie, które czyta ten sam plik logu i edytuje konfigurację pod sandboxem:

gh run view --log-failed > failed.log
codex exec --sandbox workspace-write \
  "Read failed.log. Classify each failing Playwright test as flaky or real. For flaky \
ones, add 'test.fixme' with a link comment and add { retries: 2 } to playwright.config.ts \
for that project. Summarize the real failures separately so I can fix them by hand."

Gotowy prompt: kwarantanna niestabilnych speków

Wskaż go na prawdziwe nieudane uruchomienie. Wymusza na agencie oddzielenie niestabilnych od naprawdę zepsutych — rozróżnienie, które ma największe znaczenie i które strategie „ponawiaj wszystko” psują:

Here is the log from our last failed CI run. Split the failures into two lists: (1) flaky — fails nondeterministically, typically timeouts, race conditions, or test-order dependence; (2) real — a genuine regression. For each flaky spec, add a skip/quarantine marker with a comment linking the run URL, and propose a bounded retries: 2 policy scoped to that suite only. For each real failure, give me the file, the assertion that failed, and your best guess at the root cause. Do not quarantine anything you classify as real.

Workflow: Progresywne Wdrożenie z Auto-Rollbackiem

Binarne wdrożenie albo w pełni się udaje, albo w pełni zawodzi. Progresywne wdrożenie wysyła nową wersję do wycinka ruchu, obserwuje wskaźniki błędów i automatycznie wycofuje zmiany, jeśli te skaczą w górę. Na Cloudflare Workers jest to wbudowane w wrangler versions — nie wymaga service mesh.

Każ agentowi napisać zadanie wdrożeniowe, które wysyła nową wersję, kieruje do niej 10% ruchu i bramkuje pełny rollout na health checku:

# .github/workflows/deploy.yml (excerpt)
- name: Upload new version
  run: npx wrangler versions upload --json > version.json

- name: Canary 10% of traffic
  run: |
    VID=$(jq -r '.id' version.json)
    npx wrangler versions deploy "$VID@10%" "${PREV}@90%" --yes

- name: Health gate
  run: ./scripts/check-error-rate.sh   # exits non-zero if 5xx rate > threshold

- name: Promote to 100%
  if: success()
  run: npx wrangler versions deploy "$(jq -r .id version.json)@100%" --yes

- name: Rollback on failure
  if: failure()
  run: npx wrangler rollback --message "Auto-rollback: health gate failed"

Cursor

Write .github/workflows/deploy.yml for a Cloudflare Worker. Use wrangler versions upload, then wrangler versions deploy to send 10% of traffic to the new version, run scripts/check-error-rate.sh as a gate, promote to 100% on success, and wrangler rollback on failure. Pin actions/checkout@v5.

Claude Code

claude "Generate .github/workflows/deploy.yml that does a gradual Cloudflare Workers \
rollout: wrangler versions upload, deploy at 10% canary, run scripts/check-error-rate.sh \
as a health gate, promote to 100% on pass, wrangler rollback on fail. Also stub \
check-error-rate.sh to query the Workers analytics 5xx rate and exit 1 above 1%."

Agentowy skill wrangler od Cloudflare oraz kontekst MCP wrangler pomagają tutaj — ale powyższy prompt już produkuje uruchamialny workflow.

Codex

Przy wdrożeniach uruchom Codex w samym CI z oficjalną akcją, a nie lokalnie. openai/codex-action@v1 instaluje CLI i uruchamia codex exec wewnątrz zadania:

- uses: actions/checkout@v5
- name: Generate deploy workflow
  uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    prompt: 'Write a progressive Cloudflare Workers deploy using wrangler versions with a 10% canary, a health gate, and wrangler rollback on failure.'
    sandbox: workspace-write
    safety-strategy: drop-sudo

Gotowy prompt: progresywne wdrożenie Workers

Ten wpisuje na stałe ścieżkę auto-rollbacku, o której większość zespołów zapomina. Dostosuj próg i zapytanie analityczne do swojej konfiguracji:

Write .github/workflows/deploy.yml for a Cloudflare Worker using wrangler versions. Steps: (1) wrangler versions upload and capture the version id; (2) deploy a 10% canary against the previous version with wrangler versions deploy "<id>@10%" "<prev>@90%" --yes; (3) run scripts/check-error-rate.sh, which queries the Workers 5xx rate over the last 5 minutes and exits non-zero above 1%; (4) on success promote to 100%; (5) on failure() run wrangler rollback. Also write check-error-rate.sh. Pin actions/checkout@v5 and add a manual workflow_dispatch trigger.

Wybór Modelu

Przy edycjach CI sterowanych przez agenta rozumowanie obejmujące wiele plików liczy się bardziej niż czysta szybkość — agent musi odczytać układ twojego workspace, wywnioskować zależności i wyprodukować poprawny YAML za jednym razem. Gdy budżet ma mniejsze znaczenie niż skuteczność za pierwszym razem, użyj Claude Fable 5 (/model fable w Claude Code lub selektorem modeli w Cursorze) — to najbardziej zaawansowany model Anthropic, który znakomicie radzi sobie właśnie z tego typu pracą obejmującą wiele plików. Gdy budżet ma znaczenie, wybieraj Claude Opus 4.8 do wykrywania zmian i progresywnego wdrożenia, a do tańszego, bardziej mechanicznego triage niestabilnych testów — Claude Sonnet 4.6. Porównanie cen i pełną hierarchię możliwości znajdziesz w porównaniu modeli. Codex domyślnie działa na GPT-5.5 w CLI, IDE i Cloud; użyj gpt-5.2-codex, gdy uwierzytelnisz CLI kluczem API (jak robi to powyższa akcja GitHub).

Kiedy To Się Psuje

CI to jedno miejsce, gdzie pewna siebie, ale błędna edycja agenta kosztuje cię zepsuty main. Tryby awarii są specyficzne.

Agent bramkuje zadanie na złym filtrze

Wyjścia dorny/paths-filter to stringi, nie wartości logiczne. if: ${{ needs.changes.outputs.api }} jest prawdziwe dla dosłownego stringa 'false' — zadanie uruchamia się bez względu na wszystko. Agenci mylą się tu nieustannie. Zawsze wymagaj jawnego porównania == 'true' i testuj, pushując zmianę dotyczącą tylko dokumentacji oraz potwierdzając, że zadania buildu są pomijane, a nie zielone-z-zerową-liczbą-kroków.

Polityka ponawiania prób maskuje prawdziwą regresję

Jeśli pozwolisz agentowi przykleić retries do całego zestawu, prawdziwa sporadyczna regresja przejdzie za drugim razem i trafi na produkcję. Ogranicz ponawianie prób do konkretnych speków poddanych kwarantannie, nigdy do globalnej konfiguracji, i ustaw kwarantannowane testy na zegarze — komentarz // FLAKY since 2026-06-05, którego pozostawienie ktoś musi uzasadnić. Lista kwarantanny to księga długów, a nie cmentarz.

Auto-rollback nie widzi tego, czego nie mierzy

Progresywne wdrożenie wycofuje się tylko na sygnałach, które twój health gate faktycznie sprawdza. Strona zwracająca 200, która renderuje zepsuty checkout, prześlizguje się przez bramkę opartą na wskaźniku 5xx. Dodaj co najmniej jeden syntetyczny check, który przechodzi ścieżkę krytyczną, i zachowaj wrangler rollback jako ręczne wyjście awaryjne — potwierdź, że potrafisz uruchomić go ręcznie, zanim zaufasz mu w if: failure().

Jeśli workflow wygenerowany przez agenta nie parsuje się, nie proś agenta, żeby „naprawił YAML” na ślepo — wklej z powrotem dokładny błąd z gh workflow view lub z Actions. Przypięcie każdej akcji do wersji major (@v5, @v3) także zapobiega klasycznej awarii typu „wczoraj działało”, gdy zmienny tag wprowadza zmianę łamiącą kompatybilność.

Co Dalej

Orkiestracja Kontenerów Rozszerz te pipeline na wdrożenia Docker i Kubernetes z manifestami i skalowaniem wspieranymi przez AI.

Infrastructure as Code Generuj i przeglądaj konfigurację Terraform i Wrangler tym samym, świadomym zmian, sterowanym przez agenta workflow.

Monitoring Wydajności Podłącz powyższe health gate do prawdziwego monitoringu, żeby progresywne wdrożenia wycofywały się na właściwych sygnałach.

Operacje Bezpieczeństwa Dodaj skanowanie SAST, zależności i sekretów do tych pipeline bez spowalniania wewnętrznej pętli.