Bauen und Warteschlange

Gebaut wird im Tab Build des gewählten Projekts. Alles, was startet, läuft über die Warteschlange: Builds, Uploads, Reparaturen und Aufräumläufe. So kommen sich zwei Vorgänge im selben Ordner nie in die Quere.

Ein Build in vier Schritten

1. Preset wählen. Die Presets des Projekts stehen als Karten nebeneinander. Ein Klick wählt eins aus.
2. Version prüfen. Unter Version (–build-name) und Build-Nr (–build-number) steht der Vorschlag der Station.
3. Befehl ansehen. Unter Auszuführender Befehl steht genau das, was gleich läuft. Mit dem Kopier-Symbol holst du ihn ins Terminal.
4. Build starten. Das Log läuft live unter dem Formular mit.

Ist der Build fertig, liegt das Artefakt im Sammelordner, der Lauf steht im Verlauf, und auf Wunsch meldet macOS das Ende mit einer Mitteilung (Einstellungen › Benachrichtigung bei Build-Ende).

Version und Build-Nummer

Die Version kommt aus der pubspec.yaml. Die Build-Nummer schlägt die Station so vor, dass sie über der höchsten Nummer liegt, die sie für diesen Store kennt. Ist im Preset Build-Nummer automatisch hochzählen an, zählt sie zusätzlich gegenüber dem letzten erfolgreichen Build dieses Presets hoch.

Unter dem Versionsfeld steht, was zuletzt im Store gelandet ist, etwa „Zuletzt in Google Play: 1.4.2+87”. Der Zusatz „(laut Store)” heißt: Die Zahl kommt direkt von der Store-API. Das Pfeilsymbol daneben fragt den Store erneut. Ist für das Projekt der automatische Upload an, steht dort zusätzlich Auto-Upload.

In pubspec.yaml zurückschreiben schreibt die Version in die pubspec.yaml. Geändert wird nur die version:-Zeile, und es wird nie automatisch committet.

Build-Nummer schon vergeben

Liegt die eingetragene Build-Nummer schon in einem Store, fragt die Station vor dem Start nach. Der Store nimmt dieselbe Nummer kein zweites Mal an. Du kannst direkt auf die nächste Build-Nummer oder die nächste Version umstellen, optional mit Neue Version in pubspec.yaml schreiben, oder mit Trotzdem bauen weitermachen.

Was vor dem Start geprüft wird

• Preset vollständig? Fehlt etwas Wesentliches, startet der Build nicht und die Station nennt den Grund.
• Analyse: Meldet flutter analyze Fehler, fragt die Station mit den ersten Fehlern im Klartext nach. Mehr dazu unter Versionen und Updates.
• Working Tree: Gibt es uncommittete Änderungen, erscheint ein gelber Hinweis, dass der Build nicht reproduzierbar ist. Das ist kein Blocker.
• Git-Branch: Ist das Projekt an einen Branch gekoppelt, steht da, dass vorher gewechselt wird. Bei uncommitteten Änderungen scheitert dieser Wechsel, siehe Projekte anlegen.

Konfiguration nur für diesen Lauf

Der aufklappbare Abschnitt Konfiguration für diesen Lauf zeigt Dart-Defines, Env, Pre-Steps und Extra-Args des Presets. Was du hier änderst, gilt nur für diesen einen Build. Das Preset bleibt unverändert.

Praktisch ist das für einmalige Abweichungen, etwa einen anderen API-Host zum Testen oder ein zusätzliches pod install.

Clean Build

Clean Build ergänzt einmalig flutter clean vor allen anderen Pre-Steps, ohne das Preset zu ändern. Das kostet ein paar Minuten, hilft aber oft bei rätselhaften Fehlern nach einem Flutter- oder Plugin-Update.

Die Warteschlange

Zur Warteschlange reiht einen Build ein, ohne auf den laufenden zu warten. Das geht beliebig oft und auch über Projekte hinweg. So lassen sich etwa Android- und iOS-Preset nacheinander abarbeiten, während du etwas anderes tust. Läuft für das Projekt schon etwas, wird aus Build starten automatisch Zur Warteschlange.

Die Warteschlange selbst öffnest du über den Eintrag Warteschlange in der Seitenleiste. Dort steht:

• oben der laufende Build mit Live-Log und Abbrechen
• darunter unter Wartend alle eingereihten Aufträge in Ausführungsreihenfolge
• je Eintrag die Pfeile Nach oben und Nach unten und das Entfernen aus der Warteschlange
• in der Kopfzeile Wartende verwerfen und Alles abbrechen

Parallele Builds

Pro Projekt läuft immer nur ein Build, denn zwei Builds im selben Ordner würden sich gegenseitig build/ zerschießen. Teilen sich zwei Projekte einen Ordner, gilt die Regel für den Ordner.

Verschiedene Projekte dürfen parallel bauen. Wie viele gleichzeitig, stellst du unter Einstellungen › Parallele Builds ein (1 bis 4, Vorgabe 1).

Alle Kundenvarianten auf einmal

Sollen alle Kunden denselben Stand bekommen, nimmt dir Alle in die Warteschlange … die Klickerei ab. Den Knopf findest du in der Übersicht und in der Warteschlange. Steht dort schon etwas, heißt er Alle einreihen ….

1. Wähle oben eine Plattform, etwa Android oder iOS. Die Station wählt dann in jedem Projekt das erste Preset dieser Plattform. Erstes Preset nimmt stattdessen das jeweils erste Preset.
2. Pro Projekt kannst du das Preset ändern oder nicht bauen wählen.
3. Nach erfolgreichem Build hochladen lädt jeden fertigen Build in den eingerichteten Store. Das gilt nur für Projekte mit Upload-Weg, und eine schon hochgeladene Build-Nummer wird übersprungen.
4. Clean Build (flutter clean vorher) ergänzt bei allen ein flutter clean.
5. … Builds einreihen startet.

Version und Build-Nummer kommen dabei wie im Tab Build ohne Anpassungen: Version aus der pubspec.yaml, Build-Nummer über der höchsten im Store. Was nicht eingereiht werden konnte, steht anschließend mit Grund im Dialog.

Das Log

Das Log läuft während des Builds live mit. Oben darüber:

• Filtern … blendet alle Zeilen aus, die den Suchbegriff nicht enthalten.
• Nur Fehler zeigt nur Fehlerzeilen.
• Am Ende festhalten scrollt automatisch mit.
• Log kopieren und Log in Console öffnen.

Sehr lange Logs kürzt die Ansicht im Fenster. Vollständig liegt jedes Log trotzdem auf der Platte und im Sammelordner als build.log.

Scheitert ein Build, erscheint über dem Log ein Streifen mit Ursache und Ausweg. Das beschreibt Wenn ein Build scheitert.

Wiederholen und Abbrechen

Kürzel	Wirkung
⌘ R	letzten Build mit gleicher Konfiguration wiederholen
⌘ .	laufenden Build abbrechen

Dasselbe geht im Verlauf mit Erneut bauen (⌘R) an jedem Lauf, im Tab Build mit Abbrechen (⌘.) und in der Statuszeile.

Gradle- und Dart-Daemons überleben manchmal einen Abbruch. Hängt danach etwas, hilft Einstellungen › Wartung › Gradle-Daemons stoppen.