ci(mobile): cache Gradle so the APK build stops re-downloading Maven Central - #32
Merged
Conversation
…Central The Mobile job caches Hermit and pub but not Gradle, so every run re-resolved the entire Android/Kotlin dependency graph over the network. Run 31196146152 got a 429 from repo.maven.apache.org resolving kotlin-gradle-plugins-bom while evaluating mobile/android/settings.gradle.kts, and Flutter's built-in retry waits 100ms — both attempts died inside the same rate-limit window, 6s apart. Caching ~/.gradle/caches and ~/.gradle/wrapper removes the round trip entirely on a warm key rather than retrying it, and shortens the build besides.
The first version cached all of ~/.gradle/caches, which came out at 2429 MB. The repo shares a 10 GB Actions cache budget with the cargo, pnpm and Hermit entries, and LRU eviction would have pushed those out to keep this one. modules-2 holds the downloaded artifacts — the network dependency that got 429'd. Everything else under caches/ is derived (build-cache, transforms, jars): losing it costs CPU to recompute, which is not what was failing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What broke
CI / Mobilefailed onmain(run 31196146152, 4m27s). Not a code failure:It died in
mobile/android/settings.gradle.kts:20resolving thedev.flutter.flutter-plugin-loader:1.0.0plugin — i.e. at Gradle configuration time, before any of our code compiles.Why it was reachable at all
The
mobile:job caches Hermit (~/.cache/hermit/pkg) and pub (~/.pub-cache) but not Gradle. Every single run therefore re-resolved the whole Android/Kotlin dependency graph over the network from Maven Central.Flutter's own retry is no help here: the log reads
Retrying Gradle Build: #1, wait time: 100ms. Both attempts landed inside the same rate-limit window, 6 seconds apart.The fix
Cache
~/.gradle/cachesand~/.gradle/wrapper, keyed on the Android build files plusmobile/pubspec.lock(the plugin set drives the Android dependency graph), using the sameactions/cache/restore+actions/cache/save+continue-on-error: trueidiom the job already uses for Hermit and pub.This removes the round trip rather than retrying it, and takes time off the build as a side effect.
Known ceiling, marked in a comment: a cold cache (first run after a key change) still makes the request and could still be 429'd. That's a much rarer window than every run; if it recurs, the next rung is a retry with real backoff.
Test plan
Mobilepasses on this PR — that run populates the cache (cold key).Cache restored from key: gradle-Linux-…and the APK build performs no Maven Central downloads.yaml.safe_load), job goes 12 → 16 steps.Note on urgency
The immediate red is already superseded —
mainhead6d87a168is green (37 check-runs, 0 failed). This is the durable fix, not an unblock. Frequency was 1 failure in 11 recent Mobile runs.