CI/CD z Codex GitHub Action

Twój pipeline CI uruchamia lint, type-check i testy. To łapie błędy składniowe i regresje. Ale nie łapie dryfu architektonicznego, problemów bezpieczeństwa w nowym kodzie ani faktu, że ktoś właśnie dodał 500-liniową funkcję bez żadnej dokumentacji. Chcesz, aby kontrole jakości wspomagane AI działały na każdym PR, automatycznie, bez konieczności instalowania dodatkowych narzędzi przez kogokolwiek. Codex GitHub Action (openai/codex-action@v1) daje ci dokładnie to — Codex w CI, z tymi samymi możliwościami, które ma wszędzie indziej.

Czego się nauczysz

• Działający workflow GitHub Actions uruchamiający Codex na każdym PR
• Pliki promptów do przeglądu kodu, skanowania bezpieczeństwa i przygotowania wydań
• Konfigurację bezpieczeństwa do bezpiecznego uruchamiania Codex w CI (drop-sudo, sandboxing)
• Techniki przechwytywania i publikowania wyników Codex z powrotem na PR

Przepływ pracy

Krok 1: Skonfiguruj podstawową akcję

Minimalna integracja Codex z CI wymaga około dziesięciu linii YAML workflow. Zapisz klucz API OpenAI jako sekret GitHub, pobierz kod i uruchom akcję.

Wskazówka

Workflow do skopiowania — przegląd PR:

name: Codex PR Review
on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  codex-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    outputs:
      final_message: ${{ steps.codex.outputs.final-message }}
    steps:
      - uses: actions/checkout@v5
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge

      - name: Fetch base and head refs
        run: |
          git fetch --no-tags origin \
            ${{ github.event.pull_request.base.ref }} \
            +refs/pull/${{ github.event.pull_request.number }}/head

      - name: Run Codex review
        id: codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt-file: .github/codex/prompts/review.md
          sandbox: read-only
          safety-strategy: drop-sudo

  post-review:
    runs-on: ubuntu-latest
    needs: codex-review
    if: needs.codex-review.outputs.final_message != ''
    permissions:
      pull-requests: write
    steps:
      - name: Post review comment
        uses: actions/github-script@v7
        with:
          github-token: ${{ github.token }}
          script: |
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.payload.pull_request.number,
              body: process.env.CODEX_MESSAGE,
            });
        env:
          CODEX_MESSAGE: ${{ needs.codex-review.outputs.final_message }}

Krok 2: Napisz pliki promptów

Przechowuj prompty Codex w .github/codex/prompts/, aby były wersjonowane i przeglądalne. Plik promptu jest w Markdown — Codex czyta go jako instrukcje.

Utwórz .github/codex/prompts/review.md:

Review this pull request. Focus on:

1. Correctness: Logic errors, off-by-one bugs, unhandled edge cases
2. Security: Input validation, auth checks, data exposure
3. Performance: N+1 queries, unnecessary computation, missing indexes
4. Maintainability: Overly complex functions, missing error handling, unclear naming

Rules:
- Flag only P0 (must fix before merge) and P1 (should fix before merge) issues
- Include the file path and line number for each finding
- Suggest a specific fix, not just "this could be better"
- If the PR is clean, say so explicitly

Do not flag:
- Style preferences (formatting, naming conventions) unless they violate project standards
- Test file structure choices
- Comment content or documentation style

Krok 3: Dodaj skanowanie bezpieczeństwa do CI

Utwórz osobny workflow, który uruchamia analizę bezpieczeństwa na PR dotykających wrażliwych ścieżek:

name: Security scan
on:
  pull_request:
    paths:
      - 'src/routes/**'
      - 'src/middleware/**'
      - 'src/lib/db/**'
      - 'package.json'
      - 'package-lock.json'

jobs:
  security:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v5

      - name: Security scan
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt-file: .github/codex/prompts/security.md
          sandbox: read-only
          safety-strategy: drop-sudo
          output-file: security-report.md

      - name: Upload security report
        uses: actions/upload-artifact@v4
        with:
          name: security-report
          path: security-report.md

Z .github/codex/prompts/security.md:

Perform a security audit of the changes in this pull request:

1. Scan for SQL injection, XSS, command injection, and path traversal
2. Verify all new endpoints have authentication middleware
3. Check that error responses do not expose internal details
4. Flag any new dependencies with known CVEs (check npm audit)
5. Verify secrets are not committed in any file

Report only security findings. Format as a severity-sorted list.

Krok 4: Automatyzuj przygotowanie wydań

Użyj Codex w CI do przygotowania notatek wydania, gdy zmiany są scalane do main:

Wskazówka

Workflow do skopiowania — przygotowanie wydania:

name: Release preparation
on:
  push:
    branches: [main]

jobs:
  prepare:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0

      - name: Generate release notes
        id: codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt: |
            Analyze commits since the last git tag. Generate:
            1. A changelog in Keep a Changelog format
            2. A suggested semver version bump (major/minor/patch)
            3. A release summary for GitHub Releases

            Group changes into: Added, Changed, Fixed, Security.
            Write user-facing descriptions, not commit messages.
          sandbox: read-only
          safety-strategy: drop-sudo
          output-file: release-notes.md

Krok 5: Skonfiguruj bezpieczeństwo i uprawnienia

Codex GitHub Action działa z uprawnieniami, które przyznaje twój workflow. Stosuj zasadę minimalnych uprawnień.

Strategie bezpieczeństwa:

• drop-sudo (domyślna, zalecana) — usuwa dostęp sudo przed uruchomieniem Codex. Nieodwracalne w ramach zadania.
• unprivileged-user — uruchamia Codex jako użytkownik bez uprawnień root. Najbardziej restrykcyjne.
• unsafe — brak ograniczeń. Tylko dla runnerów Windows. Nigdy nie używaj na współdzielonych runnerach z sekretami.

Tryby sandboxa:

• read-only — Codex może czytać pliki, ale nie może ich modyfikować ani uzyskiwać dostępu do sieci. Najlepsze do przeglądów.
• workspace-write — Codex może edytować pliki w repozytorium. Potrzebne do przepływów napraw i commitów.
• danger-full-access — Pełny dostęp do systemu plików i sieci. Używaj tylko gdy absolutnie konieczne (na przykład uruchamianie testów wymagających dostępu do sieci).

Ograniczanie wyzwalaczy:

• Użyj allow-users, aby ograniczyć, kto może wyzwalać workflow
• Użyj allow-bots, aby kontrolować, które boty mogą go wywoływać
• Filtruj po ścieżkach plików, aby uniknąć uruchamiania na nieistotnych zmianach

Uwaga

Nigdy nie uruchamiaj akcji Codex z safety-strategy: unsafe na runnerach mających dostęp do sekretów produkcyjnych. Strategia bezpieczeństwa akcji chroni tylko podproces Codex — inne kroki w tym samym zadaniu mogą nadal normalnie uzyskiwać dostęp do sekretów.

Zaawansowane: Strukturalne wyjście i zbieranie artefaktów

Dla przepływów pracy wymagających strukturalnych wyników (nie tylko komentarza), użyj --output-schema przez wejście codex-args, aby wymusić kształt odpowiedzi JSON:

- uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    prompt: "Analyze this PR and categorize each finding by type and severity."
    codex-args: '["--output-schema", "{\"findings\": [{\"type\": \"string\", \"severity\": \"string\", \"file\": \"string\", \"line\": \"number\", \"description\": \"string\"}]}"]'
    sandbox: read-only
    output-file: findings.json

To pozwala kolejnym krokom parsować ustalenia programowo — na przykład, aby tworzyć adnotacje GitHub check lub nie przechodzić builda tylko gdy istnieją ustalenia o statusie Critical.

Połącz output-file z uploadem artefaktów, aby zachować pełne transkrypty do celów audytu:

- name: Upload Codex transcript
  if: always()
  uses: actions/upload-artifact@v4
  with:
    name: codex-review-transcript
    path: codex-output.md
    retention-days: 30

Łączenie CI i lokalnych automatyzacji

GitHub Action działa po stronie serwera na infrastrukturze GitHub. Automatyzacje aplikacji Codex działają lokalnie na twojej maszynie. Te się wzajemnie uzupełniają:

• GitHub Action: działa na każdym PR, łapie problemy przed scaleniem, widoczne dla całego zespołu
• Lokalne automatyzacje: działają według harmonogramu (codziennie, cotygodniowo), wyłapują dryf w głównej gałęzi, trafiają do twojej osobistej skrzynki

Solidna konfiguracja używa obu: GitHub Action przegląda przychodzące zmiany, a lokalne automatyzacje monitorują zdrowie bazy kodu między PR. GitHub Action zapewnia jakość na wejściu; automatyzacje zapewniają, że jakość nie degraduje się z czasem.

Kiedy to nie działa

Przegląd Codex trwa zbyt długo i blokuje scalanie PR. Ustaw timeout na zadaniu workflow i uczyń przegląd nieblokującym: zmień workflow, aby działał jako osobny check, który nie jest wymagany do przejścia. Zespoły powinny traktować przegląd Codex jako doradczy, a nie bramkę, dopóki nie zaufają dokładności.

Oba prompt i prompt-file są ustawione. Akcja wymaga dokładnie jednego źródła promptu. Usuń duplikat. Preferuj prompt-file dla wersjonowanych promptów i prompt dla jednorazowych instrukcji inline.

Klucz API jest widoczny w logach. Akcja używa proxy Responses API, które nie powinno logować klucza, ale jeśli safety-strategy jest unsafe i wcześniejszy krok zapisał klucz w zmiennej środowiskowej, może wyciec. Zawsze używaj drop-sudo i sprawdź, że żaden krok nie wypisuje OPENAI_API_KEY.

Codex publikuje przegląd przy każdym pushu, tworząc szum. Jeśli wiele commitów jest pushowanych szybko (rebase, fixup), dostajesz wiele komentarzy przeglądu. Dodaj grupę współbieżności, aby anulować trwające uruchomienia:

concurrency:
  group: codex-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

Co dalej

Przepływ automatyzacji PR Automatyzuj cały cykl życia PR poza samym przeglądem kodu

Zaplanowana automatyzacja zadań Uzupełnij kontrole CI o zaplanowane lokalne automatyzacje