Building and the queue

You build in the Build tab of the selected project. Everything that starts runs through the Warteschlange (queue): builds, uploads, repairs and cleanup runs. That way, two operations in the same folder never get in each other’s way.

A build in four steps

1. Pick a preset. The project’s presets are shown as cards side by side. One click selects one.
2. Check the version. Under Version (–build-name) and Build-Nr (–build-number) you’ll find the Station’s suggestion.
3. Look at the command. Under Auszuführender Befehl (command to run) is exactly what’s about to run. The copy icon gets it into your terminal.
4. Build starten (start build). The log streams live below the form.

When the build is done, the artifact sits in the collection folder, the run is listed under Verlauf (History), and if you like, macOS announces the end with a notification (Einstellungen › Benachrichtigung bei Build-Ende (Settings › notification when build finishes)).

Version and build number

The version comes from pubspec.yaml. The Station suggests a build number that’s above the highest number it knows for this store. If Build-Nummer automatisch hochzählen (auto-increment build number) is on in the preset, it also counts up from the last successful build of this preset.

Below the version field you’ll see what last landed in the store, for example “Zuletzt in Google Play: 1.4.2+87” (last in Google Play). The suffix “(laut Store)” (according to the store) means the number comes straight from the store API. The arrow icon next to it asks the store again. If automatic upload is on for the project, it also says Auto-Upload.

In pubspec.yaml zurückschreiben (write back to pubspec.yaml) writes the version into pubspec.yaml. Only the version: line is changed, and nothing is ever committed automatically.

Build number already taken

If the build number you entered is already in a store, the Station asks before starting. The store won’t accept the same number a second time. You can switch straight to the next build number or the next version, optionally with Neue Version in pubspec.yaml schreiben (write new version to pubspec.yaml), or carry on with Trotzdem bauen (build anyway).

What’s checked before starting

• Is the preset complete? If something essential is missing, the build doesn’t start and the Station tells you why.
• Analysis: If flutter analyze reports errors, the Station asks first and shows the first errors in plain language. More in Versions and updates.
• Working tree: If there are uncommitted changes, a yellow notice says the build isn’t reproducible. This isn’t a blocker.
• Git branch: If the project is linked to a branch, it tells you the branch will be switched first. With uncommitted changes, that switch fails, see Adding projects.

Configuration for this run only

The collapsible section Konfiguration für diesen Lauf (configuration for this run) shows the preset’s Dart defines, env, pre-steps and extra args. Whatever you change here only applies to this one build. The preset stays unchanged.

That’s handy for one-off deviations, such as a different API host for testing or an extra pod install.

Clean build

Clean Build adds a one-time flutter clean before all other pre-steps, without changing the preset. It costs a few minutes but often helps with puzzling errors after a Flutter or plugin update.

The queue

Zur Warteschlange (add to queue) queues a build without waiting for the running one. You can do that as often as you like, across projects too. That way you can, say, have the Android and iOS presets run one after the other while you do something else. If something is already running for the project, Build starten automatically becomes Zur Warteschlange.

You open the queue itself via the Warteschlange entry in the sidebar. There you’ll find:

• at the top, the running build with live log and Abbrechen (Cancel)
• below it, under Wartend (waiting), all queued jobs in execution order
• for each entry, the Nach oben (move up) and Nach unten (move down) arrows and removal from the queue
• in the header, Wartende verwerfen (discard waiting) and Alles abbrechen (cancel all)

Parallel builds

Only one build ever runs per project, because two builds in the same folder would wreck each other’s build/. If two projects share a folder, the rule applies to the folder.

Different projects can build in parallel. You set how many at once under Einstellungen › Parallele Builds (Settings › parallel builds) (1 to 4, default 1).

All customer variants at once

If all customers should get the same version, Alle in die Warteschlange … (add all to queue) saves you the clicking. You’ll find the button in the Übersicht (Overview) and in the Warteschlange. If something is already queued there, it’s called Alle einreihen … (queue all).

1. Choose a platform at the top, such as Android or iOS. The Station then picks the first preset for that platform in each project. Erstes Preset (first preset) picks each project’s first preset instead.
2. For each project you can change the preset or choose nicht bauen (don’t build).
3. Nach erfolgreichem Build hochladen (upload after successful build) uploads each finished build to the configured store. This only applies to projects with an upload route, and a build number that’s already been uploaded is skipped.
4. Clean Build (flutter clean vorher) (clean build, flutter clean first) adds a flutter clean to all of them.
5. … Builds einreihen (queue … builds) starts.

Version and build number are taken as in the Build tab, without adjustments: the version from pubspec.yaml, the build number above the highest one in the store. Anything that couldn’t be queued is then listed in the dialog with the reason.

The log

The log streams live during the build. Above it:

• Filtern … (filter) hides all lines that don’t contain the search term.
• Nur Fehler (errors only) shows only error lines.
• Am Ende festhalten (stick to end) scrolls along automatically.
• Log kopieren (copy log) and Log in Console öffnen (open log in Console).

The view in the window truncates very long logs. Every log is still stored in full on disk and in the collection folder as build.log.

If a build fails, a strip with the cause and a way out appears above the log. That’s described in When a build fails.

Repeating and cancelling

Shortcut	Action
⌘ R	repeat the last build with the same configuration
⌘ .	cancel the running build

You can do the same in the Verlauf with Erneut bauen (⌘R) (build again) on any run, in the Build tab with Abbrechen (⌘.), and in the status bar.

Gradle and Dart daemons sometimes survive a cancel. If something hangs afterwards, Einstellungen › Wartung › Gradle-Daemons stoppen (Settings › Maintenance › stop Gradle daemons) helps.