Stop pretending Vercel is an option
It was never used. The repository lives on a self-hosted Gitea, which Vercel's git integration cannot connect to at all — so the documented route amounted to "mirror to GitHub first", and nobody did. vercel.json is gone, and with it the branch in next.config.ts that switched off `output: "standalone"` when the VERCEL variable was present. That branch was the only functional trace; everything else was documentation and comments describing a second deployment path that did not exist. DEPLOYMENT.md loses its "two supported ways" framing and the whole Vercel section — about fifty lines. Several statements next to it were stale for a different reason and are corrected in the same pass: the outbound-firewall table still listed Supabase's pooler (the database is a container now, nothing leaves the server), the prerequisites still demanded an existing Supabase project, and the .env table still asked for a pooler connection string instead of the two new passwords. The nightly job is described as what it is — a container in docker-compose.yml — rather than as a replacement for Vercel Cron. Migrations keep their references: two comments from July mention Vercel Cron, and they describe what was true when they were written. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -99,10 +99,9 @@ Ein einziges Rollenmodell, kein Mehrfach-Rollen-System:
|
||||
Funktion, deren Ausführungsrecht explizit auf `service_role` beschränkt ist
|
||||
(`revoke ... from public, anon, authenticated; grant ... to service_role`).
|
||||
Sie wird von `app/api/cron/apply-pending-changes/route.ts` aufgerufen —
|
||||
täglich per Vercel Cron (`vercel.json`), außerhalb von Vercel per
|
||||
Ersatz-Scheduler (siehe `DEPLOYMENT.md`, Docker-Cron-Sidecar). Die Route
|
||||
selbst authentifiziert per `CRON_SECRET`-Bearer-Token, nicht per
|
||||
Supabase-Session — es gibt keine anfragende Person, nur den Scheduler.
|
||||
täglich vom `cron`-Container aus `docker-compose.yml`. Die Route selbst
|
||||
authentifiziert per `CRON_SECRET`-Bearer-Token, nicht über eine Sitzung — es
|
||||
gibt keine anfragende Person, nur den Zeitplan.
|
||||
|
||||
Idempotenz: `pending_org_changes.status` läuft `pending` → `applied` (oder
|
||||
`cancelled` bei Reorg-Undo); die Auswahl-Query filtert immer auf
|
||||
|
||||
Reference in New Issue
Block a user