Ein Windmill-Repository importieren

SupaCloud kann ein Windmill-wmill sync-Repository — dessen Flows, rohe Apps und Skripte — als native Workflows in einen Workspace importieren. Wenn das Repository unter db/migrations/ Datenbankmigrationen mitbringt, wendet SupaCloud dieses Schema beim Import auf eine von dir gewählte PostgreSQL-Ressource an, sodass die importierten Flows ihre Tabellen schon beim ersten Lauf haben.

Das ist eine Admin-Aufgabe: der Import-Endpunkt erfordert einen Workspace-Admin.

Bevor du startest

Du bist Workspace-Admin.
Das Repository ist erreichbar: eine Git-URL und, für ein privates Repository, eine unter Ressourcen konfigurierte Git-Anmeldedatei.
Enthält das Repository einen db/migrations/-Ordner, lege unter Ressourcen eine PostgreSQL-Ressource für das gemeinsame Schema an (oder wähle eine vorhandene). Bevorzuge in der Produktion eine least-privileged Rolle mit Rechten nur auf dieses Schema statt eines Superusers.

Den Import durchführen

Den Import-Assistenten öffnen. Gehe zu Workflows und wähle Import → Windmill-Repository.
Auf das Repository zeigen. Gib die Git-URL ein und wähle für ein privates Repository die Git-Anmeldedatei. SupaCloud klont das Repository und scannt es zu einem Importplan — die gefundenen Flows, Apps und Skripte sowie ein eventuelles db/migrations/, das angewendet wird.
Die Datenbankressource binden. Enthält der Plan ein Datenbankschema, wähle die PostgreSQL-Ressource, auf die es angewendet wird. Diese Bindung ist die einzige deployment-spezifische Entscheidung; Schemaname und Isolierung liest SupaCloud aus dem Repository.
Prüfen und anwenden. Bestätige den Plan. SupaCloud erstellt die Workflows (jeder behält seinen Windmill-Ordner im Namen, f/blockworx/bank_sync wird also zu blockworx/bank_sync), erfasst Zeitpläne und HTTP-Trigger und wendet das Datenbankschema auf die gebundene Ressource an.

Zero-Touch-Datenbankschemas

Ein Repository, dessen db/migrations/-Ordner keine SupaCloud- db/namespace.yaml mitbringt, wird trotzdem ohne manuelle Einrichtung importiert: SupaCloud leitet den Schemanamen aus dem CREATE SCHEMA- Statement und die Mandantenisolierung aus dem SQL ab. Ein Schema, dessen Tabellen eine entity-Spalte deklarieren, wird pro Entität isoliert; sonst ist es gemeinsam genutzt ohne mandantenspezifische Überlagerung.

Das Schema wird per Name find-or-create angewendet, append-only und prüfsummengesichert — ein erneuter Import wendet eine bereits gelaufene Migration nie erneut an. Um die abgeleitete Form zu überschreiben, füge dem Repository eine db/namespace.yaml hinzu; sie hat Vorrang.

Ressourcen- und Variablen-Referenzen

Ein Windmill-Flow-Modul liest häufig eine Zugangsdaten oder eine Einstellung über eine resource("f/…")- oder eine variable("u/…")-Referenz. SupaCloud importiert diese als echte Bindungen am erzeugten Code-Node — nicht als tote Platzhalter.

resource("f/…") wird zu einer Ressourcen-Bindung. Ein Code-Node, der eine Ressource bindet, läuft in der berechtigungsgeführten Sandbox (Python/TypeScript) mit standardmäßig verweigertem Egress: das Skript erreicht nur den Host der gebundenen Ressource und liest die aufgelöste Zugangsdaten über einen host-vermittelten Accessor — es hält nie das rohe Secret. Eine postgresql-Ressource gewährt zusätzlich einen host-vermittelten, abgesicherten Datenbankaufruf (standardmäßig nur lesend; siehe unten). Der Konverter ordnet jede Referenz einer Workspace-Ressource per Name zu und gibt eine Warnung für jede Bindung aus, die du prüfen oder neu binden solltest — öffne den Node im Builder und bestätige, dass die referenzierte Ressource in diesem Workspace existiert.
variable("u/…") wird zu einer Workspace-Umgebungsvariablen-Injektion. Die passende Workspace-Umgebungsvariable (per Schlüssel — dem letzten Pfadsegment) wird zur Laufzeit host-seitig aufgelöst und in den Node injiziert, least-authority: nur die Variablen, die das Skript tatsächlich liest, werden injiziert. Eine als Secret markierte Variable wird host-seitig entschlüsselt und nie in der Workflow-Definition gespeichert. Stelle sicher, dass eine Umgebungsvariable dieses Schlüssels unter Ressourcen → Umgebungsvariablen existiert.

Ein Code-Node, der keine Ressource bindet, bleibt hermetisch (kein Netzwerk, keine Datenbank) — unverändert gegenüber einem schlichten importierten Snippet. Bindungen sind eine First-Party-, workspace-eigene Fähigkeit; im Marketplace veröffentlichte Workflows tragen sie nie.