Skip to content
Build Station

When a build fails

Known error patterns with cause and fix, one-click repairs, automatic change suggestions as a diff and the optional AI repair with Claude.

When a build fails, the cause is usually somewhere in the log, but rarely in a place you’ll spot right away. The Build Station reads the log along with you. If it recognizes a known error pattern, a strip with the cause, the way out and, where possible, a button appears right above the log.

Warning: CocoaPods is installed but broken. Skipping pod install.
CocoaPods not installed or not in valid state.

turns into: „CocoaPods ist installiert, aber nicht lauffähig” (CocoaPods is installed but not working), with the command brew install cocoapods and the Beheben (fix) button below.

Known error patterns

Error pattern Way out
CocoaPods broken or missing brew install cocoapods
Podfile.lock doesn’t match the installed state pod install, rebuild the pods if necessary
outdated CocoaPods index pod repo update && pod install
pinned Flutter version missing in fvm fvm install
fvm can’t be found brew install fvm or a note about the PATH
Gradle daemon crashed ./gradlew --stop
disk full opens the cleanup dialog
Xcode can’t sign opens Runner.xcworkspace in Xcode
dependencies can’t be resolved pub upgrade
build number already exists in the store explanation: increase the number
Android keystore missing explanation
store rejects the credentials opens the upload setup
JDK doesn’t match Gradle (Unsupported class file major version …) opens the version check
Gradle too old for the Android Gradle Plugin opens the version check
old fvm_config.json contradicts .fvmrc opens the version check

Depending on the error pattern, the buttons are called Beheben (fix), Terminal öffnen (open Terminal), Zwischenergebnisse leeren … (clear intermediate results), Upload-Einrichtung prüfen … (check upload setup) or Versionen prüfen … (check versions). If there are several ways out, the others are listed under Andere Wege (other ways). After a repair, Erneut bauen (build again) takes you straight to the next attempt.

Three things are deliberate:

  • The triggering log line is shown alongside. A diagnosis without evidence would just be a claim.
  • The Station never runs sudo. A password prompt can’t be handled sensibly from inside an app. Such fixes are shown, not started, with a button that opens a terminal in the project.
  • Repairs run through the queue. A pod install in the middle of a running build would be as harmful as an rm -rf build. Before running anything, the Station asks and shows the commands.

The catalog is deliberately cautious: better no suggestion than a wrong one.

Automatic repair

Some errors can only be fixed by a change in the project, for example to a Gradle file or to pubspec.yaml. For these, the strip shows a ready-made suggestion as a diff, i.e. line by line what would change.

Error pattern Suggestion
Language version 1.6 is no longer supported (e.g. with sentry_flutter 8.x) raise the plugin to the first major version that fixes the problem. Fallback: force the language version in android/build.gradle
:plugin is currently compiled against android-31 raise the plugin. Fallback: raise compileSdk for all plugins
macOS or iOS deployment target below the minimum Podfile and project.pbxproj to the minimum, then pod install
Kotlin version below Flutter’s minimum raise the kotlin version in settings.gradle
app applies the Kotlin Gradle Plugin itself, plugins bring their own remove the line, or raise the plugins to versions without their own KGP
discontinued package, e.g. flutter_markdown replace it with its successor, imports included

The Station doesn’t go by the version number to check whether a newer plugin version really fixes the error. It reads the candidates’ android/build.gradle straight from the archive on pub.dev. If the new version depends on a different major version of a direct dependency, such as sentry for sentry_flutter, that one is raised too.

Nothing is written until you press a button:

  • Anwenden und neu bauen (apply and rebuild) changes the files and queues a new build right away.
  • Nur anwenden (apply only) changes the files and waits.

Until then, every file stays untouched. Each application creates a backup. Zurücknehmen (revert) restores the files as long as you haven’t edited them further since. Nothing is ever committed.

If the same error shows up in the log again after a repair, the strip says so and offers Zurücknehmen.

Under Vorwarnungen (early warnings), collapsed, are things the build doesn’t fail on yet, but soon will.

AI repair with Claude

If no rule fits, Claude can investigate the error. The result is a suggestion just like with the rules, with a diff. Nothing is written automatically.

Setup

  1. Create an API key in the Claude Console at console.anthropic.com.
  2. In the Station, enter it under Einstellungen › KI-Reparatur (Settings › AI repair) in the Neuer API-Schlüssel (sk-ant-…) (new API key) field and click Im Schlüsselbund speichern (save to keychain).
  3. Verbindung testen (test connection) checks the key.

The key is stored in the macOS keychain, never in a configuration file. If the environment variable ANTHROPIC_API_KEY is set, it takes precedence.

In the same section you set:

Setting Default
Modell (model) Claude Opus (most thorough analysis), alternatively Sonnet (half the price) or Haiku (cheapest)
Tageslimit (US-$) (daily limit) $5
KI-Runden pro Fehler (AI rounds per error) 3

How an analysis works

Below the strip of a failed build there’s Mit Claude analysieren (analyze with Claude). The AI never starts on its own, only via this button and after a confirmation that shows what has already been spent today.

After as many AI rounds on the same project as set under KI-Runden pro Fehler without a successful build, it stops. From there you continue by hand.

If an AI repair leads to a successful build, the Station offers to save it as a rule. The next time the same error occurs, the rule kicks in, with no AI and no cost.

What is sent and what never is

Sent to Anthropic:

  • an excerpt from the build log
  • the project’s build files, such as Gradle files, Podfile and pubspec.yaml
  • if the AI asks for them, individual files from the project and the package cache

Never sent are files containing credentials, including key.properties, local.properties, .env files, keystores, .p8, .p12, certificates and provisioning profiles, google-services.json, GoogleService-Info.plist and service account files. Lines with passwords and tokens are redacted before sending.

Cost

The AI repair uses your own API key; the cost is billed to your Anthropic account. Depending on the error, an analysis usually costs a few cents. After each analysis, the Station shows what it cost. Once the daily limit is reached, no further analysis starts.

The same key can suggest release notes from the commit subject lines when uploading. Only those lines go to Anthropic, no code. See Artifacts and upload.

Checking packages in advance

Many of these errors announce themselves. In the Versionen (Versions) dialog in the Build tab, Pakete prüfen (flutter pub outdated) (check packages) shows discontinued packages, plugins with their own Kotlin Gradle Plugin and new major versions of direct dependencies, with the same suggestions, before a build fails on them. More in Versions and updates.

If none of this helps

  • Check under Einstellungen › Toolchain (Settings › Toolchain) whether all tools are found.
  • Stop hanging Gradle daemons under Einstellungen › Wartung (Settings › Maintenance).
  • Try a Clean Build.
  • Copy the command from the Build tab and run it in the terminal. Whatever fails there isn’t failing because of the Station.

More cases are covered in Troubleshooting.