Wenn ein App Builder-Build fehlschlägt: Protokoll lesen, Ursache ermitteln, erneut erstellen

Eine App in App Builder baut Programme nacheinander aus Rezepten. Eines davon kann fehlschlagen. Diese Anleitung zeigt einen tatsächlichen Fehler auf einem Test-NAS: TurboShell mit 70 Rezepten stoppte beim siebten Rezept, der Korn-Shell ksh93.

Wodas Rezept, das fehlgeschlagen ist
Protokolldie letzten Zeilen
Ursachewas die Fehlermeldung nennt
Änderungkorrigiertes Rezept oder App
Neuer Buildverwendet erfolgreiche Rezepte wieder

Die Bilder stammen von Bucket & Code Server IDE 1.0.0-49, vor und nach dem Fix.

01Wo es fehlgeschlagen ist

Ein fehlgeschlagener Build lässt die App, wie sie war. Wenn ein früherer Build erfolgreich war, verwenden Aktivieren, Herunterladen und Als QPKG exportieren weiterhin dessen Ergebnis. Die Seitenleiste markiert den letzten Build als fehlgeschlagen; auf der App-Seite steht der Fehler in der Pipeline.

Die Pipeline: Build, Fehlgeschlagen; ein früherer Build wird beibehalten

Die Karte Build-Reihenfolge nennt das Rezept, das fehlgeschlagen ist, und die Phase, in der es fehlschlug. In diesem Beispiel zeigen alle Rezepte davor bestanden. Die Rezepte danach zeigen nicht erreicht und behalten das Protokoll eines früheren Builds.

Die Karte Build-Reihenfolge: Build fehlgeschlagen, die Meldung builder: FAILED ksh93 in build (exit 1), Rezepte 1 bis 6 bestanden, ksh93 beim Kompilieren fehlgeschlagen, fish nicht erreicht, daneben Früheres Protokoll

02Lesen Sie das Protokoll des Rezepts

Protokoll in der Zeile des Rezepts öffnet, was der Builder dafür geschrieben hat: seine Phasen, die Ausgabe des Compilers, das Audit und die Prüfung. Die Ursache liegt kurz vor dem Ende.

Das Protokoll von ksh93: misc/magic.c von libast: Fehler: unbekannter Typname Magic_t; Meinten Sie magic_t, dann mamake mit Exit-Code 1 beim Erstellen von magic.o, und Paket: make ist fehlgeschlagen

Das eigene Protokoll des Build-Jobs unter Jobs im unteren Bereich (Ctrl+J) endet mit denselben Zeilen: Der Builder kopiert die letzten 40 Zeilen des Protokolls des Rezepts hinein.
Der Build-Baum des fehlgeschlagenen Rezepts bleibt bis zum nächsten Build der App im Build-Ordner der App: apps/<app>/build/work/<recipe> im Datenordner. Öffnen Sie ihn im Terminal des Editors, um sich die Quellen und die generierten Dateien anzusehen.

03Finden Sie die Ursache

Der Compiler verlangt Magic_t, den eigenen Typ von ksh, und schlägt magic_t vor, den Typ von libmagic, der Bibliothek des Befehls file. Also fand #include <magic.h> in den ksh-Quellen den Header von libmagic, nicht den von ksh.

TurboShell baut auch das Rezept file, das magic.h von libmagic im Präfix der App installiert. Jedes Rezept baut mit dem include-Ordner dieses Präfixes im Suchpfad; so finden seine Programme die Bibliotheken, die vor ihnen gebaut wurden. Der erste Build von TurboShell baute ksh93 vor file und war erfolgreich. Ein späterer Build arbeitet in einer Kopie des letzten guten Builds. Dessen Präfix enthielt bereits den Header von libmagic, und ksh93 hat ihn verwendet.

Nennt ein Fehler etwas, wie dieser hier, verfolgen Sie diesen Namen zurück durch die Quellen, die früheren Rezepte und die Build-Umgebung. Das Protokoll zeigt, wo dieser Build angehalten hat; welche Änderung den Fehler behebt, sagt es nicht.

04Was Sie ändern können

Ein korrigiertes Rezept. Zwischen zwei Versionen des Pakets kommen Rezepte als signierter Katalog auf das NAS. Die Karte Rezeptbibliothek auf der Seite Apps zeigt die verwendete Katalogversion und die letzte Prüfung an; Nach Rezept-Updates suchen prüft sofort. Das korrigierte Rezept ksh93 kam mit Katalog 2026.10.08-1 und hält ksh93 von den Headern im Präfix getrennt.
Die App. Mit Ändern auf der App-Seite fügen Sie Rezepte hinzu oder entfernen sie und wählen Umgebung und Link-Modus. Ein Programm, das mit einem anderen Rezept kollidiert, kann in einer eigenen App gebaut werden.
Die Umgebung. Braucht ein Rezept einen neueren Compiler oder ein Build-Werkzeug, das der Umgebung fehlt, wählen Sie mit Ändern eine andere Umgebung.

05Die Quelle eines Rezepts selbst ändern

Wenn noch kein korrigiertes Rezept da ist oder ein Programm eine neuere Version hat, als das Rezept der Bibliothek baut, kann eine Kopie des Rezepts die neue Quelle angeben. Die Kopie kommt in den Ordner recipes/ eines beliebigen Ihrer Projekte, und eine App, die die Rezepte dieses Projekts verwendet, baut die Kopie anstelle des Rezepts der Bibliothek. Die Bibliothek und die anderen Apps bleiben, wie sie sind. In der Bibliothek von Bucket & Code Server IDE 1.0.0-55 baut das Rezept tmux die Version 3.7c; die Kopie hier baut 3.8.

Das Log des Build-Jobs nennt die verwendete Bibliothek in seiner Zeile recipe library:. Die eigene Bibliothek des Pakets liegt in /usr/bin/bucketvs/share/bucketvs/recipes/, die eines Katalogs in recipes/current/library/ im Datenordner. Kopieren Sie im Terminal des Editors, im Ordner des Projekts, den Ordner des Rezepts von dort und ermitteln Sie die sha256 des neuen Archivs:

mkdir -p recipes
cp -r /usr/bin/bucketvs/share/bucketvs/recipes/tmux recipes/
curl -fsSL https://github.com/tmux/tmux/releases/download/3.8/tmux-3.8.tar.gz | sha256sum
e79c699c7e949dccd0a4a125e17b8d1261e311b16979dbc8eb34542f3966d82e  -

In recipes/tmux/recipe.json ändern sich drei Werte: die Version, die Adresse und die sha256.

"version": "3.8",
"source": {
  "url": "https://github.com/tmux/tmux/releases/download/3.8/tmux-3.8.tar.gz",
  "sha256": "e79c699c7e949dccd0a4a125e17b8d1261e311b16979dbc8eb34542f3966d82e"
},

Beim Speichern der Datei werden die Rezepte des Projekts geprüft, und die Befunde erscheinen in der Ansicht Probleme des Editors; bvs recipe lint . führt dieselbe Prüfung im Terminal aus. Die Karte Rezepte der Projektansicht markiert die Kopie mit ersetzt die Version 3.7c der Bibliothek. Eine Kopie mit einem Problem wird ausgelassen, und das Rezept der Bibliothek springt nicht für sie ein: Ein Build, der tmux braucht, hält vor dem Start an und nennt den Grund.
Auf der Seite der App zeigt Ändern das Feld Rezepte aus einem Projekt, sobald ein Projekt ein Rezept enthält. Wählen Sie das Projekt, dann Änderung speichern und Neu bauen. Das Log des Build-Jobs listet die Rezepte, die er aus dem Projekt gelesen hat, und meldet tmux replaces the library's tmux 3.7c in this app.
Eine Version, die sich genauso baut, braucht nur diese drei Werte. Braucht sie andere configure-Optionen oder einen Patch, ändern Sie auch build.sh; Ihr erstes eigenes Rezept erklärt diese Datei.
Die Kopie ersetzt das Rezept der Bibliothek über den Namen, unabhängig von den Versionen. Überholt das Rezept der Bibliothek die Kopie, baut die App weiterhin die Kopie: Stellen Sie Rezepte aus einem Projekt zurück auf Keines: nur die Bibliothek oder löschen Sie die Kopie.

06Neu erstellen

Neu bauen auf der App-Seite startet einen neuen Build-Job. Sind die Dateien der App seit dem fehlgeschlagenen Build unverändert, macht er dort weiter, wo dieser Build angehalten hat: Die Rezepte, die der fehlgeschlagene Build schon fertig hatte, werden wiederverwendet, und das fehlgeschlagene Rezept wird neu gebaut, hier ksh93 mit dem korrigierten Rezept aus dem Katalog.

Die Pipeline nach dem neuen Build: Build, Gebaut

Die Karte Build-Reihenfolge nach dem neuen Build: ksh93 und fish bestanden

07Wenn der Build erfolgreich ist, aber ein Programm nicht startet

Jeder Build überprüft sein Ergebnis, bevor er die App ersetzt: die eigene Prüfung jedes Rezepts und eine Analyse, die jedes Programm und jede Bibliothek liest, ohne sie auszuführen. Der Reiter Abhängigkeiten der App listet auf, was diese Analyse gefunden hat: eine fehlende Bibliothek, eine Version, die eine Bibliothek nicht definiert, ein RUNPATH, der aus der App hinaus zeigt, oder ein Programm, das eine neuere glibc braucht als die, für die die App gebaut ist. Für unterstützte Befunde schlägt das Panel eine Aktion vor, oft als Schaltfläche: … hinzufügen und bauen, Auf … umstellen und bauen, RUNPATH patchen, Andere Umgebung wählen oder Nur für dieses NAS bauen. Auf dem NAS gibt bvs deps <app> dieselbe Liste aus.