Eigene Scripts und Web-Builds

Nicht jeder Build ist ein einzelnes flutter build. Manche Projekte brauchen vorher einen Codegenerator, packen danach ein ZIP oder rufen ein vorhandenes Script aus dem Repository auf. Dafür gibt es Presets im Modus Eigenes Script.

Script anlegen

Im Preset-Editor wählst du oben Eigenes Script. Dann gibt es zwei Varianten:

• Inline: Das Script steht im Feld Shell-Script direkt im Preset.
• Datei im Repo: Unter Script-Pfad (relativ zum Projekt) trägst du z. B. tools/build_android.sh ein. Das Symbol daneben listet die gefundenen Scripts, Datei … öffnet eine Dateiauswahl.

Das Script läuft im Projektordner, über dieselbe Shell wie alle Builds. Ein Inline-Script legt die Station nach dem Build als build.sh neben das Artefakt in den Sammelordner, damit später klar ist, was gelaufen ist.

Beginne jedes Script mit set -euo pipefail. Ohne diese Zeile überdecken Folgezeilen einen Fehler, und ein gescheiterter Build gilt als erfolgreich. Der Editor weist darauf hin.

Die BS_*-Variablen

Alles, was im Preset und im Build-Dialog eingestellt ist, bekommt das Script als Umgebungsvariable. Im Inline-Script kannst du sie zusätzlich als Platzhalter {{BS_…}} schreiben, die Station ersetzt sie vor dem Start. Unter Verfügbare Variablen im Editor stehen sie zum Anklicken und Einfügen bereit.

Variable	Inhalt
BS_PROJECT_ID	Projekt-ID
BS_PROJECT_NAME	Anzeigename des Projekts
BS_PROJECT_PATH	absoluter Projektpfad
BS_PRESET_ID	Preset-ID
BS_PLATFORM	android, ios, web, macos oder other
BS_BUILD_MODE	release, profile oder debug
BS_FLAVOR	Flavor, gegebenenfalls leer
BS_TARGET	Einstiegspunkt, gegebenenfalls leer
BS_BUILD_NAME	Version aus dem Build-Dialog
BS_BUILD_NUMBER	Build-Nummer aus dem Build-Dialog
BS_RUN_ID	ID dieses Laufs
BS_TMP_DIR	leeres Temp-Verzeichnis nur für diesen Lauf
BS_ARTIFACT_DIR	Zielordner im Sammelordner, existiert bereits
BS_GIT_BRANCH	aktueller Branch
BS_GIT_COMMIT	kurzer Commit-Hash
BS_DART_DEFINE_<KEY>	jeder Dart-Define einzeln, z. B. BS_DART_DEFINE_API_HOST
BS_DART_DEFINE_ARGS	alle Dart-Defines als fertige --dart-define=…-Kette
BS_FLUTTER	fvm flutter bzw. flutter ohne fvm
BS_DART	fvm dart bzw. dart ohne fvm

Ein unbekannter Platzhalter bleibt unverändert stehen, und der Lauf bekommt einen Hinweis.

Artefakte melden

Damit die Station weiß, was das Script gebaut hat, meldet das Script seine Ergebnisse selbst:

echo "BUILDSTATION_ARTIFACT=/absoluter/pfad/zur/datei.zip"

Das ist der zuverlässigste Weg und hat Vorrang vor allen anderen Quellen. Mehrere Ergebnisse meldest du mit mehreren Zeilen. Alternativ trägst du im Preset unter artifactGlobs Muster ein, unter denen die Station sucht, etwa build/**/*.aab.

Fehlt beides, erkennt die Station kein Artefakt, und der Editor warnt vorher. Gemeldete Dateien kopiert sie wie bei jedem anderen Build in den Sammelordner, siehe Artefakte und Upload.

Beispiel: Web-Build als ZIP

set -euo pipefail
$BS_FLUTTER build web --release --wasm \
  $BS_DART_DEFINE_ARGS \
  --base-href=/kunde-a/
cd build/web
zip -qr "$BS_TMP_DIR/web-$BS_BUILD_NAME+$BS_BUILD_NUMBER.zip" .
echo "BUILDSTATION_ARTIFACT=$BS_TMP_DIR/web-$BS_BUILD_NAME+$BS_BUILD_NUMBER.zip"

$BS_FLUTTER sorgt dafür, dass die richtige Flutter-Version aus fvm läuft. $BS_DART_DEFINE_ARGS übernimmt die Dart-Defines aus Projekt, Preset und Build-Dialog. Das ZIP landet im laufspezifischen Temp-Ordner und wird von dort in den Sammelordner kopiert.

build_web.sh im Projektordner

Viele Web-Projekte haben schon ein eigenes build_web.sh. Liegt eine Datei mit genau diesem Namen im Projektordner, führt ein Web-Preset im Modus Flutter-Befehl dieses Script aus statt flutter build web.

• Das Script bekommt dieselben BS_*-Variablen wie ein eigenes Script.
• Dart-Defines, Build-Modus und Extra-Argumente des Presets erreichen es nur über diese Variablen, etwa $BS_DART_DEFINE_ARGS.
• Ist der Dart-Define API_HOST gesetzt, geht sein Wert zusätzlich als erstes Argument mit: build_web.sh <API_HOST>.
• Die Vorschau im Tab Build zeigt dann das Script als Befehl.

Presets im Modus Eigenes Script bleiben bei ihrem eigenen Script.

Web-Build committen

Manche Deployments holen den Web-Stand direkt aus dem Repository. Für diese Projekte gibt es im Projekt-Editor den Schalter Web-Build committen.

Ist er an, committet die Station nach einem erfolgreichen Web-Build den Ordner build/web auf den aktuellen Branch:

• Committet wird nur dieser Ordner, auch entfernte Dateien darin. Andere Änderungen im Working Tree bleiben liegen.
• Die Commit-Nachricht lautet z. B. Web-Build 1.4.2+88 und nennt den Quell-Commit.
• Gepusht wird nicht. Das erledigst du selbst oder mit Commit & Push im Tab Build.

Ist build/web per .gitignore ausgeschlossen, steht das Repository auf einem losgelösten HEAD oder schlägt ein Git-Hook fehl, bleibt der Build trotzdem erfolgreich. Der Grund steht dann als Warnung am Lauf.

Scripts laufen ohne Sandbox

Wichtig: Ein eigenes Script läuft mit den vollen Rechten deines macOS-Benutzers. Es kann alles lesen, schreiben und löschen, was du auch kannst.

Das ist der Zweck der Funktion, hat aber eine Folge: Eine Preset-Konfiguration ist ausführbarer Code. Eine importierte Projekt-JSON, eine buildstation.json aus einem fremden Repository oder ein weitergegebenes Projekt ist genauso vertrauenswürdig wie ein fremdes Shell-Script. Schau vor dem Import hinein.

Mehr dazu unter Einstellungen und Sicherheit.