Claude w CI/CD — automatyzacja pipeline-u i code review z AI

Seria Claude Code · JSystems

CI/CD to jedno z najbardziej niedocenianych miejsc do wdrożenia AI. Claude wbudowany w pipeline GitHub Actions może automatycznie reviewować każdy PR, generować changelog, analizować logi nieudanych testów i wykrywać podatności bezpieczeństwa — zanim ktokolwiek z zespołu spojrzy na kod. Ten artykuł pokazuje jak to zrobić praktycznie.

Co to jest CI/CD i dlaczego warto wpiąć tam AI?

CI (Continuous Integration — Ciągła Integracja) to praktyka gdzie kod jest automatycznie testowany za każdym razem gdy ktoś z zespołu coś commituje. Zamiast sprawdzać "czy działa?" ręcznie, maszyna sprawdza to automatycznie.

CD (Continuous Delivery/Deployment — Ciągłe Dostarczanie/Wdrażanie) to automatyczne wdrożenie kodu na serwer gdy przeszedł testy. Bez manualnego "kliknij tutaj żeby wdrożyć".

Co to jest pipeline? Pipeline to sekwencja kroków automatycznie wykonywanych po sobie. W CI/CD: checkout kodu → install dependencies → uruchom testy → jeśli przeszły → wdróż. Każdy krok to "stage" lub "job".

Dlaczego AI w CI/CD to świetny pomysł? Każdy PR (Pull Request — propozycja zmian w kodzie) trafia do pipeline automatycznie. Claude może przejrzeć go w 10 sekund i zakomentować potencjalne problemy — zanim inny programista znajdzie czas na manualny review. Jeden znaleziony bug na etapie PR zaoszczędza godziny debugowania na produkcji.

Czym jest GitHub Actions i jak go uruchomić?

GitHub Actions to wbudowany w GitHub system CI/CD. Definiujesz workflow w pliku YAML (format danych jak JSON, ale czytelniejszy) w katalogu .github/workflows/. GitHub automatycznie uruchamia ten workflow przy określonych zdarzeniach (np. otwarcie PR).

Możesz myśleć o GitHub Actions jak o serwerze który czeka na zdarzenia w Twoim repozytorium — każdy push, każdy PR, każdy merge — i w odpowiedzi na nie uruchamia zdefiniowane przez Ciebie zadania. To serwer który pracuje za Ciebie 24/7, bez dodatkowych kosztów (do 2 000 minut/miesiąc gratis w publicznych repozytoriach).

Krok po kroku — pierwsze workflow AI code review

Automatyczny code review przy każdym PR

GitHub Actions — pełny workflow

Diff to zapis zmian między dwiema wersjami kodu — co zostało dodane (linie z +), co usunięte (linie z -). Claude analizuje diff i ocenia zmiany — nie widzi całego projektu, tylko to co się zmieniło w PR.

# .github/workflows/ai-code-review.yml
# Plik YAML definiujący workflow — każda linia ma znaczenie, wcięcia są ważne!
name: AI Code Review  # Nazwa widoczna w zakładce Actions na GitHub


on:
  # Uruchom gdy ktoś otworzy PR lub zaktualizuje istniejący
  pull_request:
    types: [opened, synchronize]  # opened = nowy PR, synchronize = nowy commit do PR

jobs:
  review:
    runs-on: ubuntu-latest  # Uruchom na maszynie wirtualnej z Ubuntu
    permissions:
      contents: read         # Uprawnienie do czytania kodu repozytorium
      pull-requests: write   # Uprawnienie do dodawania komentarzy do PR

    steps:
      # Krok 1: Pobierz kod repozytorium na maszynę GitHub Actions
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Pobierz całą historię git (potrzebne do git diff)

      # Krok 2: Wygeneruj diff — co zmieniło się w tym PR?
      - name: Get PR diff
        id: diff  # ID kroku — możemy odwołać się do jego wyników
        run: |
          # git diff między bazową gałęzią a HEAD (najnowszy commit PR)
          git diff origin/${{ github.base_ref }}...HEAD > pr_diff.txt
          # Zapisz rozmiar diffu do zmiennej — użyjemy do warunku poniżej
          echo "diff_size=$(wc -c < pr_diff.txt)" >> $GITHUB_OUTPUT

      # Krok 3: Wyślij diff do Claude i opublikuj wynik jako komentarz
      - name: AI Code Review
        # Pomiń krok jeśli diff jest bardzo duży (ponad 50 000 znaków) — Claude ma limit kontekstu
        if: steps.diff.outputs.diff_size < 50000
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}  # Klucz z GitHub Secrets
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}  # Token GitHub (automatyczny, nie musisz go tworzyć)
        run: |
          # "python3 << 'EOF' ... EOF" = uruchom skrypt Python wbudowany w YAML
          python3 << 'EOF'
          import anthropic, subprocess, os

          # Wczytaj diff z pliku — to co się zmieniło w PR
          with open('pr_diff.txt') as f:
              diff = f.read()

          client = anthropic.Anthropic()
          review = client.messages.create(
              model="claude-sonnet-4-6",
              max_tokens=2048,
              # System prompt mówi Claude jak formatować review
              system="""Jesteś doświadczonym senior developerem przeprowadzającym code review.
              Analizujesz diff PR i zwracasz uwagi w formacie Markdown.

              Struktura odpowiedzi:
              ## 🔴 Krytyczne (blokują merge)
              ## 🟡 Ważne (do rozważenia)
              ## 🟢 Dobre praktyki i sugestie

              Bądź konkretny — podawaj numer linii i nazwę pliku.
              Chwal dobre decyzje. Nie komentuj trywialnych spraw.""",
              messages=[{
                  "role": "user",
                  # Przekazujemy diff (max 30000 znaków — bezpieczny limit)
                  "content": f"Przeanalizuj ten diff PR:\n\n```diff\n{diff[:30000]}\n```"
              }]
          ).content[0].text

          # Pobierz numer PR z zmiennej środowiskowej GitHub Actions
          pr_number = os.environ['GITHUB_REF'].split('/')[2]
          # gh pr comment = komenda GitHub CLI do dodawania komentarza do PR
          subprocess.run([
              'gh', 'pr', 'comment', pr_number,
              '--body', f"## 🤖 AI Code Review\n\n{review}"
          ])
          EOF

Analiza nieudanych testów — "dlaczego to padło?"

Gdy testy padają, programista otwiera logi i szuka przyczyny. To może zająć 15-30 minut. Claude może zrobić to w 10 sekund i wysłać analizę na Slack — zanim ktokolwiek otworzy laptop.

# .github/workflows/test-failure-analysis.yml
name: Analyze Test Failures


on:
  # Uruchom gdy workflow "Tests" się zakończy
  workflow_run:
    workflows: ["Tests"]
    types: [completed]  # "completed" = zakończony (niezależnie czy udany czy nie)

jobs:
  analyze:
    # Uruchom TYLKO gdy testy się nie powiodły — nie analizuj sukcesów
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    runs-on: ubuntu-latest

    steps:
      # Pobierz artefakty z nieudanego workflow (pliki z wynikami testów)
      - name: Download test logs
        uses: actions/download-artifact@v4
        with:
          name: test-results  # Nazwa artefaktu zdefiniowana w workflow "Tests"
          run-id: ${{ github.event.workflow_run.id }}  # ID nieudanego runu

      - name: Analyze with Claude
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}
        run: |
          python3 << 'EOF'
          import anthropic, json, urllib.request

          # Wczytaj XML z wynikami testów (format JUnit — standardowy)
          with open('test-results.xml') as f:
              test_output = f.read()

          client = anthropic.Anthropic()
          # Używamy Haiku — tańszy model, wystarczy do analizy logów
          analysis = client.messages.create(
              model="claude-haiku-4-5",
              max_tokens=1024,
              messages=[{
                  "role": "user",
                  "content": f"""Przeanalizuj te wyniki testów i podaj:
                  1. Które testy padły i dlaczego (krótko)
                  2. Prawdopodobna przyczyna (jeden akapit)
                  3. Sugerowane pierwsze kroki debugowania

                  Logi testów:
                  {test_output[:10000]}"""  # Pierwsze 10k znaków — limit kontekstu
              }]
          ).content[0].text

          # Wyślij analizę na Slack przez Webhook (proste HTTP POST)
          payload = {"text": f":x: *Testy padły*\n\n{analysis}"}
          req = urllib.request.Request(
              SLACK_WEBHOOK,
              data=json.dumps(payload).encode(),
              headers={'Content-Type': 'application/json'}
          )
          urllib.request.urlopen(req)  # Wysyła żądanie HTTP POST
          EOF

Automatyczny changelog z commit messages

Changelog to dokument opisujący co się zmieniło między wersjami oprogramowania. Tradycyjnie pisany ręcznie przez deweloperów (i często zapominany). Claude może wygenerować go automatycznie na podstawie historii commitów.

# .github/workflows/generate-changelog.yml
name: Generate Changelog


on:
  # Uruchom gdy ktoś pusha tag zaczynający się od 'v' (np. v1.2.3)
  push:
    tags: ['v*']  # glob pattern — 'v*' pasuje do v1.0.0, v2.3.1 itd.

jobs:
  changelog:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Pełna historia — potrzebujemy commitów od poprzedniego tagu

      - name: Generate AI Changelog
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          python3 << 'EOF'
          import anthropic, subprocess, os

          # Znajdź poprzedni tag — to będzie punkt startowy naszego changelog
          prev_tag = subprocess.check_output(
              ['git', 'describe', '--tags', '--abbrev=0', 'HEAD~1'],
              text=True  # Zwróć jako string, nie bytes
          ).strip()

          # Pobierz wszystkie commity od poprzedniego tagu do obecnego
          # --pretty=format:%s (%an) = temat commitu (imię autora)
          commits = subprocess.check_output(
              ['git', 'log', f'{prev_tag}..HEAD', '--pretty=format:%s (%an)'],
              text=True
          )

          client = anthropic.Anthropic()
          # Haiku wystarczy — to proste zadanie transformacji tekstu
          changelog = client.messages.create(
              model="claude-haiku-4-5",
              max_tokens=1024,
              # System prompt określa format i styl changelog
              system="""Generujesz changelog dla release notes.
              Format: Markdown z sekcjami:
              ### 🆕 Nowe funkcje
              ### 🐛 Naprawione błędy
              ### ⚡ Ulepszenia wydajności
              ### 💥 Breaking Changes (jeśli są)

              Używaj języka zrozumiałego dla użytkowników końcowych,
              nie dla developerów. Grupuj powiązane zmiany.""",
              messages=[{
                  "role": "user",
                  "content": f"Wygeneruj changelog na podstawie tych commitów:\n{commits}"
              }]
          ).content[0].text

          # Pobierz nazwę tagu z zmiennej środowiskowej (np. "refs/tags/v1.2.3")
          tag = os.environ['GITHUB_REF'].replace('refs/tags/', '')
          # Zaktualizuj release notes na GitHub dla tego tagu
          subprocess.run([
              'gh', 'release', 'edit', tag,
              '--notes', changelog
          ])
          EOF

Security scanning — AI wykrywa podatności

Podatność bezpieczeństwa to luka w kodzie którą atakujący może wykorzystać. OWASP Top 10 to lista 10 najpowszechniejszych typów podatności w aplikacjach webowych — SQL injection, XSS, nieprawidłowe uwierzytelnianie itd. Claude zna te wzorce i może ich szukać automatycznie w każdym PR.

# Dodaj jako osobny step do istniejącego workflow review
- name: Security Analysis
  env:
    ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
  run: |
    python3 << 'EOF'
    import anthropic


    with open('pr_diff.txt') as f:
        diff = f.read()

    client = anthropic.Anthropic()
    # Sonnet (nie Haiku) bo security analysis wymaga głębszego rozumowania
    security = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=1024,
        # Precyzyjne instrukcje co szukać — OWASP Top 10 to standard branżowy
        system="""Jesteś security engineer. Analizujesz kod pod kątem podatności OWASP Top 10.
        Szukaj: SQL injection (wstrzyknięcie kodu SQL), XSS (cross-site scripting),
        CSRF (fałszowanie żądań), insecure deserialization, hardcoded secrets (hasła w kodzie),
        improper authentication (złe uwierzytelnianie), sensitive data exposure (wyciek danych).
        Zwróć TYLKO znalezione problemy. Jeśli nic nie znalazłeś — napisz "✅ Brak podatności".""",
        messages=[{"role": "user", "content": f"Przeanalizuj diff:\n{diff[:20000]}"}]
    ).content[0].text

    # Jeśli Claude NIE napisał "✅" — znalazł problemy
    if "✅" not in security:
        print("SECURITY ISSUES FOUND:")
        print(security)
        exit(1)  # exit(1) = błąd — GitHub Actions zatrzyma pipeline i ZABLOKUJE merge!
    EOF

Claude Code w lokalnym pre-commit hooku

Pre-commit hook to skrypt który Git automatycznie uruchamia zanim zapisze commit. Jeśli skrypt zwróci błąd (kod wyjścia != 0), commit zostaje odrzucony. To "ochrona tuż przed wysłaniem" — sprawdzasz kod zanim trafi na serwer.

#!/bin/bash
# .git/hooks/pre-commit
# Ten plik musi być wykonywalny: chmod +x .git/hooks/pre-commit (Linux/Mac)
# Na Windows: użyj Git Bash lub WSL


# Pobierz listę staged plików .py (tylko Python — możesz dodać inne rozszerzenia)
# --diff-filter=ACM = Added, Copied, Modified (nie Deleted)
STAGED=$(git diff --cached --name-only --diff-filter=ACM | grep '\.py$')
if [ -z "$STAGED" ]; then exit 0; fi  # Jeśli brak plików Python — pomiń

echo "🤖 Running AI pre-commit check..."
# Wygeneruj diff tylko dla staged plików i wyślij do Claude
# "claude --print" uruchamia Claude Code w trybie nieinteraktywnym i drukuje odpowiedź
git diff --cached -- $STAGED | claude --print "
Sprawdź ten diff pod kątem:
1. Hardcoded secrets lub credentials (hasła, klucze API wpisane w kod)
2. Oczywistych błędów logicznych
3. Brakujących null checks (sprawdzenia czy wartość nie jest null)

Jeśli wszystko OK — odpowiedz tylko: LGTM
Jeśli są problemy — wypisz je krótko.
" | tee /dev/stderr | grep -q "LGTM"
# "tee /dev/stderr" = wypisuje na ekran I jednocześnie przekazuje do grep
# grep -q "LGTM" = szuka słowa LGTM (cicho — bez wypisywania)

if [ $? -ne 0 ]; then  # $? = kod wyjścia ostatniego polecenia, 0 = sukces
    echo "❌ AI found potential issues. Fix them or use --no-verify to skip."
    exit 1  # Odrzuć commit
fi
echo "✅ AI pre-commit check passed"

Co to Ci da? Korzyści biznesowe

Automatyczne code review AI to nie gadżet. To inwestycja która ma mierzalny zwrot. Oto co się zmienia w praktyce po uruchomieniu Claude w pipeline:

Częste błędy przy wdrożeniu CI/CD z Claude

Dobre praktyki AI w CI/CD

• Używaj cache dla system promptów — ten sam system prompt przy każdym PR = prompt caching = 90% taniej. System prompt (jak masz analizować) jest stały — cache_control: ephemeral go zapamiętuje


• Haiku dla logów, Sonnet dla code review — nie przepłacaj za prostą analizę. Haiku jest 4× tańszy od Sonnet i wystarczy do analizy logów testów czy generowania changelog


• Limit rozmiaru diffów — przy bardzo dużych PR (>50k tokenów) rozdziel na pliki lub pomiń. Claude ma limit kontekstu i lepiej przeanalizować 5 kluczowych plików niż powierzchownie przejrzeć 50


• Nie blokuj merge automatycznie — AI review jako dodatkowa informacja, nie gate (bramka blokująca). Wyjątek: security check — tu blokowanie jest uzasadnione


• Loguj wszystkie wywołania API — monitoruj koszty (console.anthropic.com), wykrywaj anomalie (nagle 10× więcej wywołań)


• Timeout na wywołania — pipeline nie może czekać w nieskończoność na Claude. Ustaw timeout 60-120 sekund i obsłuż przypadek gdy Claude nie odpowie w czasie

Koszt AI w CI/CD — kalkulacja dla sceptycznych

Przy 50 PR/miesiąc, średni diff 5000 tokenów, Sonnet ($3/1M input):

• Input: 50 × 5000 = 250 000 tokenów = $0.75/miesiąc


• Output: 50 × 1000 tokenów = 50 000 tokenów = $0.75/miesiąc


• Łącznie: ~$1.50/miesiąc czyli około 6 zł/miesiąc za AI review każdego PR

Jeden znaleziony bug który by poszedł na produkcję kosztuje minimum kilka godzin pracy (debugowanie + fix + deploy + komunikacja z klientem). Przy stawce $50/h to $200-$500 za jeden bug. ROI z $1.50/miesiąc na AI review jest oczywisty.