Artifacts and upload

After a successful build, the Build Station copies every result into a fixed collection folder. From there it goes to the stores: by drag and drop, via a button to the store website, or directly through the store APIs.

The collection folder

The default is ~/Builds/iw-buildstation. You can change it under Einstellungen › Sammelordner (Settings › collection folder) in the Wurzel des Sammelordners (collection folder root) field and with Übernehmen (apply). The folder icon next to it opens it in the Finder.

Every build gets its own folder:

<Sammelordner>/<Projekt-ID>/<Preset-ID>/<Version>_<JJJJMMTT-HHMM>/
   kunde-a_1.4.2+87_android.aab
   build.log
   build.sh      (nur bei Inline-Scripts)
   meta.json

• The file name follows the pattern <Projekt-ID>_<Version>+<Build-Nummer>_<Plattform> (project ID, version, build number, platform) with the original extension.
• build.log is the build’s complete log.
• meta.json contains all data about the run. That keeps the folder understandable even without the app.

The Station copies, it doesn’t move. The original stays in the project’s build/ folder.

What gets filed

flutter build ipa reports two results: first the .xcarchive, then the folder with the finished .ipa. The IPA is what gets filed. Only if the export from the archive didn’t go through is the archive kept, as …_ios.xcarchive.zip with a note on the run.

Folder results, such as a web build or a macOS .app, are packed and keep their extension in the name. In the Verlauf (History), each artifact shows where the Station knows it from: reported by the script, from the Flutter output, via artifactGlobs or via the expected path.

The “Hochladen” section

Below every successful build, in the Build tab and in the Verlauf, there’s the Hochladen (Upload) section, with one entry per artifact:

• Drag handle on the left: drag the file straight from the app into the Transporter window, into the Play Console in your browser, or into the Finder.
• Transporter (only for .ipa): opens Transporter, puts the IPA path on the clipboard and shows the file in the Finder. If Transporter is missing, the button is greyed out and tells you why.
• Play Console (for .aab and .apk): opens the configured track.
• App Store Connect: for processing and TestFlight release.
• Partner Center (for .msix).
• Manuell (manual) (for web builds, macOS apps and other files): shows the file in the Finder, for distributing it your own way.
• Im Finder (in Finder) and Pfad kopieren (copy path).

The links to Play Console and App Store Connect come from the Store-Links in the project editor.

Uploading directly

If an upload route is set up for the project, below that you’ll see Jetzt hochladen · … (upload now) with the name of the route. If something is still missing, the button is disabled and Einrichtung prüfen (check setup) next to it takes you back to the setup. If there’s no route yet, Direkten Upload einrichten … (set up direct upload) offers one.

Platform	Routes
Android	Google Play API with a service account, alternatively fastlane supply or your own lane
iOS	xcrun altool with an App Store Connect team key, alternatively your own fastlane lane
Windows	Partner Center API for a finished .msix
macOS	Mac App Store, GitHub release or HTTPS webhook, see Distributing macOS apps
all	no upload: just drag and drop and store links (default)

The Station talks to the store APIs itself, without fastlane and without Codemagic. The credentials are stored per project in the macOS keychain, never in the configuration. You set this up under Projekt bearbeiten › Upload › Store-Upload einrichten (Edit project › Upload › set up store upload).

Before the upload

The confirmation Hochladen nach …? (upload to …?) shows the exact command or API calls, just like with a build. Beforehand, the Station checks everything that can be checked without running anything: missing IDs, credentials that aren’t in the keychain, artifacts that have disappeared.

Hochladen (Upload) queues the upload. It lands in the history with a full log, just like a build. If something is currently running for the project, the button is called Upload zur Warteschlange (add upload to queue).

An API upload can be cancelled until just before it’s committed. After that, it’s with the store.

Release notes

In the Release Notes (optional) field of the confirmation, enter what’s new, up to 500 characters:

• For Google Play via the API, they go to the track as “What’s new in this version”.
• For TestFlight, they go as “What to Test”. This requires the bundle ID and issuer ID to be entered in the project.
• For macOS direct distribution, they appear in the Sparkle update window.

The language is shown in the note below the field; the default is de-DE. Other upload routes don’t transfer release notes; the field is then disabled.

Aus Commits vorschlagen (KI) (suggest from commits, AI) writes a draft from the commit subject lines since the last upload to the same store. This needs the Claude API key from Einstellungen › KI-Reparatur (Settings › AI repair). Only the subject lines are sent, no code and no files. Review the suggestion before uploading.

Uploading automatically

Under Projekt bearbeiten › Upload there’s the Erfolgreiche Builds automatisch hochladen (automatically upload successful builds) switch. When it’s on, AAB, IPA and macOS app land in the configured stores after every successful build, without asking.

• Exactly one artifact is uploaded per store; for Android, the AAB before the APK.
• A build number that’s already there is skipped.
• If credentials are missing, it’s skipped as well.
• Anything skipped is noted on the build.

In the Build tab, an Auto-Upload chip shows that the switch is on.

Check your settings and results before you let uploads run automatically. You’re responsible for what gets uploaded.

Git tag after the upload

After a successful upload, the Station sets a Git tag on the build’s commit:

<projekt>/<version>+<build>    z. B. kunde-a/1.4.2+87

That way the repository shows which version the customer has. The tag’s message contains project, version, store and, if any, the release notes.

This is controlled under Einstellungen › Nach dem Upload (Settings › after upload):

• Git-Tag setzen (set Git tag) (on by default)
• Tag nach origin pushen (push tag to origin) (on by default)

If a tag with the same name already points to a different commit, it isn’t moved. If tagging or pushing fails, the upload still counts as successful, and the reason is noted on the run.

The per-build checklist

Every build gets a checklist matching its platform. For Android:

1. Build erfolgreich (build successful)
2. Version/Build-Nummer geprüft (version/build number checked)
3. AAB in Play Console hochgeladen (AAB uploaded to Play Console)
4. Release Notes eingetragen (release notes entered)
5. Internal-Testing-Track freigegeben (internal testing track released)
6. Kunde informiert (customer informed)

iOS, web and macOS have their own templates, with items like “Processing in App Store Connect abgeschlossen” (processing in App Store Connect complete) or “Smoke-Test auf der Zielumgebung” (smoke test on the target environment).

The Station ticks off Build erfolgreich itself. After a successful upload via the Station, it also ticks off Version/Build-Nummer geprüft and the upload step, because the store accepted the number. You tick off the rest by hand, in the Verlauf or more conveniently in the Offen (Open) work list, see Overview and work list.

Below the checklist there’s a Notizen (notes) field for ticket numbers, customer contacts or anything special.

Artifacts from Codemagic

Builds from Codemagic also land in the collection folder, under <Projekt-ID>/codemagic/. From there you can upload them directly with In den Store (to the store). See Codemagic.

Old artifacts

Artifacts stay put until you delete them. Under Aufräumen › Artefakte und Logs der Build Station (Clean up › Build Station artifacts and logs) you set how many days and how many builds per preset to keep. See Freeing up space.