Wanneer een App Builder-build mislukt: lees het logboek, zoek de oorzaak en bouw opnieuw

Een App Builder-app bouwt programma's op basis van recepten, de een na de ander, en een ervan kan mislukken. Deze gids volgt een build die echt mislukte op een test-NAS: TurboShell, een app met 70 recepten, stopte bij het zevende recept, de Korn-shell ksh93.

Waarhet recept dat mislukte
Logde laatste regels
Oorzaakwat de foutmelding noemt
Wijziginggecorrigeerd recept of app
Opnieuwgeslaagde recepten worden hergebruikt

De afbeeldingen komen uit Bucket & Code Server IDE 1.0.0-49, van vóór en na de oplossing.

01Waar het mislukt

Een mislukte build laat de app zoals hij was. Als een eerdere build is geslaagd, gebruiken Activeren, Downloaden en Exporteren als QPKG die build nog steeds. In de zijbalk staat bij de nieuwste build mislukt, en de pagina van de app toont de fout in de pipeline.

De pipeline: Bouwen, Mislukt; een eerdere build blijft bewaard

De kaart Bouwvolgorde noemt het recept en de fase waarin het misging. In dit voorbeeld staat bij elk recept ervoor geslaagd. Bij de recepten erna staat niet bereikt, en die houden het logboek van een eerdere build.

De kaart Bouwvolgorde: laatste build mislukt, het bericht builder: FAILED ksh93 in build (exit 1), recepten 1 tot 6 geslaagd, ksh93 mislukt tijdens het compileren, fish niet bereikt met de knop Eerder logboek

02Lees het logboek van het recept

Logboek in de rij van het recept opent wat de bouwer ervoor heeft geschreven: de fasen, de uitvoer van de compiler, de audit en de controle. De oorzaak staat vlak voor het einde.

Het logboek van ksh93: misc/magic.c van libast: fout: onbekende typenaam Magic_t; bedoelde je magic_t, daarna mamake exit code 1 bij het maken van magic.o, en package: make failed

Het eigen logboek van de bouwtaak, onder Taken in het onderste paneel (Ctrl+J), eindigt met dezelfde regels: de bouwer kopieert de laatste 40 regels van het logboek van het recept daarin.
De buildboom van het mislukte recept blijft in de buildmap van de app tot de volgende build van de app: apps/<app>/build/work/<recipe> in de datamap. Open die map in de terminal van de editor om de bronnen en de gegenereerde bestanden te bekijken.

03Zoek de oorzaak

De compiler vraagt om Magic_t, het eigen type van ksh, en stelt magic_t voor, het type van libmagic, de bibliotheek van het commando file. De regel #include <magic.h> in de bronnen van ksh vond dus de header van libmagic, niet die van ksh.

TurboShell bouwt ook het recept file, dat magic.h van libmagic in de prefix van de app installeert. Elk recept wordt gebouwd met de map include van die prefix in het zoekpad, zodat de programma's de bibliotheken vinden die eerder zijn gebouwd. De eerste build van TurboShell bouwde ksh93 vóór file en slaagde. Een latere build werkt in een kopie van de laatste goede build, waarvan de prefix al de header van libmagic bevatte, en ksh93 pikte die header op.

Noemt een fout iets bij naam, zoals deze, volg die naam dan terug via de bronnen, de eerdere recepten en de bouwomgeving. Het logboek laat zien waar deze build is gestopt; het zegt niet welke wijziging het probleem oplost.

04Wat je kunt veranderen

Een gecorrigeerd recept. Tussen twee releases door komen recepten als ondertekende catalogus op de NAS. De kaart Receptenbibliotheek op de pagina Apps toont de gebruikte versie en de laatste controle; Zoek naar receptupdates controleert meteen. Het gecorrigeerde recept ksh93 kwam met catalogus 2026.10.08-1 en schermt ksh93 af van headers in de prefix.
De app. Met Wijzigen op de pagina van de app haal je recepten weg of voeg je ze toe, en kies je de omgeving en de linkwijze. Een programma dat botst met een ander recept, kan in een eigen app.
De omgeving. Heeft een recept een nieuwere compiler nodig, of een bouwprogramma dat de omgeving niet heeft, kies dan met Wijzigen een andere omgeving.

05Wijzig zelf de bron van een recept

Zolang er nog geen verbeterd recept is, of als een programma een nieuwere release heeft dan het recept uit de bibliotheek bouwt, kan een kopie van het recept de nieuwe bron noemen. De kopie komt in de map recipes/ van een van je projecten, en een app die de recepten van dat project gebruikt, bouwt de kopie in plaats van het recept uit de bibliotheek. De bibliotheek en de andere apps blijven zoals ze zijn. In de bibliotheek van Bucket & Code Server IDE 1.0.0-55 bouwt het recept tmux versie 3.7c; de kopie hier bouwt 3.8.

Het logboek van de buildtaak noemt de gebruikte bibliotheek op de regel recipe library:. De eigen bibliotheek van het pakket is /usr/bin/bucketvs/share/bucketvs/recipes/; die van een catalogus is recipes/current/library/ in de datamap. Ga in de terminal van de editor naar de map van het project, kopieer daar de map van het recept uit die bibliotheek en bereken de sha256 van het nieuwe archief:

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 veranderen drie waarden: de versie, het adres en de sha256.

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

Bij het opslaan worden de recepten van het project gecontroleerd en verschijnen de bevindingen in de weergave Problems van de editor; bvs recipe lint . doet dezelfde controle in de terminal. De kaart Recepten van de projectweergave markeert de kopie met vervangt versie 3.7c uit de bibliotheek. Een kopie met een probleem wordt weggelaten, en het recept uit de bibliotheek neemt haar plaats niet in: een build die tmux nodig heeft, stopt voordat hij begint, met de reden.
Op de pagina van de app toont Wijzigen het veld Recepten uit een project zodra een project een recept bevat. Kies het project, druk op De wijziging opslaan en daarna op Opnieuw bouwen. Het logboek van de buildtaak somt de recepten op die hij uit het project las en meldt tmux replaces the library's tmux 3.7c in this app.
Een release die op dezelfde manier bouwt, heeft alleen deze drie waarden nodig. Heeft een release andere configure-opties of een patch nodig, pas dan ook build.sh aan; Je eerste eigen recept legt dat bestand uit.
De kopie vervangt het recept uit de bibliotheek op naam, ongeacht de versies. Gaat het recept uit de bibliotheek voorbij de kopie, dan bouwt de app nog steeds de kopie: zet Recepten uit een project terug op Geen: alleen de bibliotheek, of verwijder de kopie.

06Opnieuw bouwen

Opnieuw bouwen op de pagina van de app start een nieuwe buildtaak. Zijn de bestanden van de app sinds de mislukte build niet gewijzigd, dan gaat de nieuwe build verder waar die build stopte: de recepten die al klaar waren, worden hergebruikt, en het mislukte recept wordt opnieuw gebouwd, hier ksh93 met het gecorrigeerde recept uit de catalogus.

De pipeline na het opnieuw bouwen: Bouwen, Gebouwd

De kaart Bouwvolgorde na het opnieuw bouwen: ksh93 en fish geslaagd

07Wanneer de build slaagt maar een programma niet start

Elke build controleert het resultaat voordat hij de app vervangt: de eigen controle van elk recept en een analyse die elk programma en elke bibliotheek leest zonder ze uit te voeren. Op het tabblad Afhankelijkheden van de app wordt vermeld wat de analyse heeft gevonden: een ontbrekende bibliotheek, een versie die een bibliotheek niet definieert, een RUNPATH die buiten de app verwijst, of een programma dat een nieuwere glibc nodig heeft dan waarvoor de app is bedoeld. Voor bevindingen die het paneel kent, stelt het een oplossing voor, vaak als knop: … toevoegen en bouwen, Overschakelen op … en bouwen, RUNPATH patchen, Andere omgeving kiezen of Alleen voor deze NAS bouwen. Op de NAS drukt bvs deps <app> dezelfde lijst af.