Integracja z GitHubem

Integracja łączy główny projekt z repozytorium w układzie Supabase CLI:

supabase/
  migrations/20261015120000_add_orders.sql
  functions/hello/index.ts
  functions/_shared/cors.ts      # opcjonalnie, dołączany do funkcji, które go importują
  config.toml                    # opcjonalnie: [functions.hello] verify_jwt = false

Podłączenie

1. Utwórz fine-grained token (GitHub → Settings → Developer settings) z dostępem tylko do tego repozytorium i uprawnieniami: Contents: read, Pull requests: write, Commit statuses: write.
2. W panelu: Integracje → GitHub, podaj repozytorium (właściciel/nazwa), gałąź produkcyjną (domyślnie main), katalog (supabase) i token. Token jest szyfrowany (AES-256-GCM).
3. Dodaj w repozytorium webhook: Payload URL https://host.ulewicz.space/api/integrations/github/webhook/<ref>, Content type application/json, Secret z panelu, zdarzenia Pushes i Pull requests.

Push do gałęzi produkcyjnej

Nowe migracje są stosowane w kolejności wersji — tak jak supabase db push (ta sama tabela supabase_migrations.schema_migrations, więc możesz mieszać CLI i GitHuba). Migracja starsza niż ostatnia zastosowana blokuje wdrożenie (nadaj jej nowszą wersję). Wdrażane są tylko funkcje zmienione w pushu; zmiana _shared/ lub config.toml wdraża wszystkie. Funkcje usunięte z repozytorium nie są kasowane automatycznie. Wynik widać jako status commita HostBase i w panelu (historia wdrożeń z logami, przycisk „Wdróż ponownie”).

Pull requesty (gałęzie podglądowe)

PR do gałęzi produkcyjnej (z tego samego repozytorium — PR z forków są ignorowane) tworzy gałąź bazy pr-<numer> (tryb schema), stosuje na niej migracje z PR i wdraża wszystkie funkcje. Na PR pojawia się status HostBase Preview i komentarz z adresem API gałęzi (bez kluczy). Kolejne commity aktualizują gałąź; jeśli historia migracji się rozjedzie (rebase), gałąź jest odtwarzana z main. Zamknięcie lub merge PR usuwa gałąź. Gałęzie wliczają się do limitu planu (Pro: 3, Team: 20).

Niezawodność

Webhooki są weryfikowane podpisem X-Hub-Signature-256, duplikaty dostaw ignorowane, a zadania zapisywane w bazie panelu i ponawiane przy błędach przejściowych (do 5 prób z rosnącym odstępem). Nowszy push zastępuje oczekujący starszy. Błąd wdrożenia trafia do powiadomień organizacji.

API: GET /api/integrations/github/{ref}/deployments (token dostępu) zwraca historię wdrożeń z logami.