The database moved to a container of our own; the platform is gone. This takes out what was left of it — and, where the leftovers were load bearing, moves rather than deletes. Moved, not deleted: supabase/migrations/ -> db/migrations/ the schema's source of truth supabase/build-org.ts -> scripts/build-org.ts lib/supabase/types.ts -> lib/types.ts 52 import sites repointed The bookkeeping needed care. It lived in `supabase_migrations.schema_migrations`, and simply renaming the schema would have left the runner facing an empty table: it would have called all 67 migrations pending and replayed them against a database that is long since current. So the runner now creates `migrationen.schema_migrations` and, once, copies the old rows across — guarded so a second run does nothing and a fresh database skips it entirely. Only then does migration 20260907100000 drop the old schema. Deleted: the CLI config, the seed, the historical schema/function dumps (nothing read them), scripts/umzug-von-supabase.sh (the move is done), and both Supabase packages plus the CLI. Nothing in the application imported them — the build now succeeds with no environment variables at all, which is the proof. Integration tests: six of them signed in through Supabase Auth and asserted against the anon key and the service role. That model is gone, so the tests were not portable — they are deleted. session-context and employee-status-filter already ran on pg and are untouched; om-reporting is ported to a direct connection because it guards a real risk (the reporting line rule exists twice, once in SQL and once in TypeScript). CI: the integration job started a Supabase stack. It now runs a postgres service, applies deploy/db-init and every migration to an empty database — that was the valuable part, and it still holds — then checks that a second run is a no-op, which is what proves the bookkeeping works. Docs: security-review.md audited a service-role key, a cookie adapter and auth.users, none of which exist. Restating findings about removed components would suggest today's system had been reviewed; it has not. It now records what was removed and says a fresh review is due. data-model.md was already marked obsolete and described the pre-OM schema; azure-migration.md was a plan for a route not taken. Both deleted. Verified: npm ci, typecheck, lint, 445 tests, build — all clean without the packages. Integration tests skip cleanly with no database. Migration SQL and the runner are reviewed but NOT executed: no Docker here, and the old instance no longer resolves. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
115 lines
3.5 KiB
YAML
115 lines
3.5 KiB
YAML
name: CI
|
|
|
|
on:
|
|
push:
|
|
branches: [master, main]
|
|
pull_request:
|
|
|
|
concurrency:
|
|
group: ${{ github.workflow }}-${{ github.ref }}
|
|
cancel-in-progress: true
|
|
|
|
jobs:
|
|
check:
|
|
name: Lint, Typen, Tests, Build
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
|
|
- uses: actions/setup-node@v4
|
|
with:
|
|
node-version: 22
|
|
cache: npm
|
|
|
|
- run: npm ci
|
|
|
|
- name: Lint
|
|
run: npm run lint
|
|
|
|
- name: Typecheck
|
|
run: npm run typecheck
|
|
|
|
# Fängt die Abweichung, die `tsc` nicht sehen kann: lib/types.ts wird von
|
|
# Hand gepflegt, eine Migration mit einer neuen Spalte lässt sie also
|
|
# stillschweigend veralten.
|
|
- name: Schema/Typen-Abgleich
|
|
run: npm run types:check
|
|
|
|
- name: Unit- und Komponententests
|
|
run: npm test
|
|
|
|
# Ohne Umgebungsvariablen: seit dem Wegfall der Browser-Anbindung wird
|
|
# zur Bauzeit nichts mehr aus der Umgebung gelesen, und das Abbild ist
|
|
# für jede Umgebung dasselbe.
|
|
- name: Build
|
|
run: npm run build
|
|
|
|
migrationen:
|
|
name: Migrationen auf leerer Datenbank
|
|
runs-on: ubuntu-latest
|
|
|
|
# Derselbe Stand wie im Betrieb. Ein eigener Dienst statt einer fremden
|
|
# Plattform — die Datenbank gehört seit dem Umzug zum Projekt.
|
|
services:
|
|
postgres:
|
|
image: postgres:17-alpine
|
|
env:
|
|
POSTGRES_PASSWORD: ci
|
|
POSTGRES_DB: alpenwerk
|
|
ports:
|
|
- 5432:5432
|
|
options: >-
|
|
--health-cmd "pg_isready -U postgres"
|
|
--health-interval 5s
|
|
--health-timeout 5s
|
|
--health-retries 20
|
|
|
|
env:
|
|
MIGRATE_DATABASE_URL: postgresql://postgres:ci@127.0.0.1:5432/alpenwerk
|
|
DATABASE_SSL: "false"
|
|
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
|
|
- uses: actions/setup-node@v4
|
|
with:
|
|
node-version: 22
|
|
cache: npm
|
|
|
|
- run: npm ci
|
|
|
|
# Was das Schema von der Umgebung erwartet: die Anwendungsrolle ohne
|
|
# BYPASSRLS, zwei Erweiterungen und die Attrappe des `auth`-Schemas, ohne
|
|
# die sich die Migrationen von Juni 2026 nicht abspielen lassen.
|
|
- name: Rollen, Erweiterungen, auth-Attrappe
|
|
env:
|
|
PGPASSWORD: ci
|
|
APP_DB_PASSWORD: ci-anwendungsrolle
|
|
run: |
|
|
for f in deploy/db-init/*.sql; do
|
|
echo "── $f"
|
|
psql -v ON_ERROR_STOP=1 -h 127.0.0.1 -U postgres -d alpenwerk -f "$f"
|
|
done
|
|
|
|
# Der eigentliche Zweck dieses Jobs: jede Migration muss sich auf einer
|
|
# leeren Datenbank abspielen lassen. Eine, die das nicht kann, fällt hier
|
|
# auf — und nicht beim Wiederherstellen einer Sicherung oder beim
|
|
# Aufsetzen einer neuen Umgebung.
|
|
- name: Migrationen einspielen
|
|
run: node scripts/migrate.mjs
|
|
|
|
# Zweiter Lauf: die Buchführung muss greifen. Meldet er etwas anderes als
|
|
# „nichts anzuwenden", verbucht der Läufer nicht richtig — und ein
|
|
# Ausrollen spielte Migrationen doppelt ein.
|
|
- name: Zweiter Lauf ist ein Nichts
|
|
run: |
|
|
ausgabe=$(node scripts/migrate.mjs)
|
|
echo "$ausgabe"
|
|
echo "$ausgabe" | grep -q "^Nichts anzuwenden" \
|
|
|| { echo "Der zweite Lauf wollte erneut anwenden — die Buchführung greift nicht."; exit 1; }
|
|
|
|
# Die Integrationstests brauchen einen befüllten Bestand; der Seed lag
|
|
# in der abgelösten Umgebung und ist noch nicht nachgezogen (siehe
|
|
# README, offene Punkte). Bis dahin laufen sie gegen eine erreichbare
|
|
# Datenbank von Hand, nicht hier.
|