osFoundry / Platform
Build-Pipeline & CI
Jeder Push löst install → lint → build → deploy aus. Logs gestreamt, Artefakte aufbewahrt.
Was es ist
Build-Pipeline & CI ist die Continuous-Integration-Schicht hinter Apps & Backend von osFoundry. Wenn du den Code einer App pushst, führt osFoundry eine feste, vorhersehbare Abfolge aus: Abhängigkeiten installieren, linten, bauen, dann deployen. Es gibt keinen separaten CI-Dienst zum Anbinden, kein YAML zum Handschreiben und keinen Runner zum Bereitstellen. Die Pipeline ist Teil des Workspace, also ist eine App auszuliefern derselbe Handgriff wie deine Arbeit darin zu speichern.
Innerhalb von osFoundry ist die Pipeline das, was einen Code-Push in eine laufende App verwandelt. Jede Stufe läuft der Reihe nach und stoppt beim ersten Fehler, sodass ein Lint-Fehler oder ein kaputter Build nie bis zum Deploy kommt. Die Logs jeder Stufe erreichen dich, während der Lauf ausgeführt wird, das heißt, du siehst die Install-Ausgabe, Lint-Warnungen und Build-Fehler in Echtzeit, statt auf ein rotes Kreuz zu warten und hinterher einen Dump zu durchwühlen. Ist der Build erfolgreich, werden die entstandenen Artefakte aufbewahrt, sodass jede ausgelieferte Version einen dauerhaften Nachweis hinterlässt, in den du zurückschauen kannst, und keinen Build, der in dem Moment verschwindet, in dem er fertig ist.
Das zählt, weil der langsame Teil des Auslieferns meist die Schleife zwischen einem fehlgeschlagenen Deploy und dem Verständnis des Warum ist. Live-Logs verkürzen diese Schleife: Du siehst genau die Stufe und die Zeile, an der ein Lauf brach, aus demselben Workspace heraus, in dem du Chat, Agenten, Code und Daten schreibst. Da osFoundry bring-your-own-key und local-first ist, passt die Pipeline zu einem Workflow, in dem du die Kontrolle über deine Keys und deine Daten behältst, statt deinen Build-Prozess einem Drittanbieter-CI mit eigenem Preis pro Platz und eigenem Ort für deine Logs zu überlassen.
Wichtige Funktionen
- Jeder Push führt dieselben vier Stufen der Reihe nach aus: Install, Lint, Build, Deploy
- Die Pipeline stoppt bei der ersten fehlgeschlagenen Stufe, sodass kaputte Builds nie deployen
- Die Logs jeder Stufe erreichen dich live während des Laufs, nicht erst nach dessen Ende
- Build-Artefakte werden pro Version aufbewahrt und hinterlassen einen dauerhaften Nachweis
- Kein separater CI-Dienst, Runner oder handgeschriebenes YAML: Teil des Workspace
Anwendungsfälle
- Einzelentwickler: Eine App pushen und Install, Lint und Build live mitlesen, um eine fehlgeschlagene Lint-Stufe zu erwischen, bevor irgendetwas deployt
- Kleines Team mit internen Apps: Auf die feste Abfolge Install-Lint-Build-Deploy setzen, damit kein ungeprüfter oder kaputter Build die Nutzer erreicht
- Entwickler beim Deploy-Debugging: Durch die aufbewahrten Artefakte und Live-Logs eines früheren Laufs scrollen, um die genaue Stufe zu finden, an der eine Version brach
Häufig gestellte Fragen
Was läuft, wenn ich Code zu einer osFoundry-App pushe?
Eine feste Pipeline: Abhängigkeiten installieren, linten, bauen, dann deployen. Die Stufen laufen der Reihe nach und die Pipeline stoppt bei der ersten, die fehlschlägt, sodass ein fehlgeschlagenes Lint oder Build nie bis zur Deploy-Stufe kommt.
Kann ich Build-Logs sehen, während ein Lauf läuft?
Ja. Die Logs jeder Stufe erreichen dich live, während der Lauf ausgeführt wird, sodass du Install-, Lint- und Build-Ausgabe in Echtzeit siehst, statt auf das Ende des Laufs zu warten und danach einen statischen Dump zu lesen.
Werden alte Builds nach dem Deploy aufbewahrt?
Ja. Artefakte erfolgreicher Builds werden aufbewahrt, sodass jede ausgelieferte Version einen dauerhaften Nachweis hinterlässt, zu dem du zurückkehren kannst, statt eines Builds, der verschwindet, sobald er fertig ist.