Use the runner's NDK and Gradle's build cache in Android CI - #34
Closed
janicduplessis wants to merge 2 commits into
Closed
janicduplessis wants to merge 2 commits into
janicduplessis wants to merge 2 commits into
Conversation
Contributor
Author
|
Closing: neither change gave a measurable gain in CI. The measurements are in the description. |
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
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.
Closed without merging: neither change measurably sped up Android CI. This PR tried the two Android CI savings noted in #29. The numbers are kept here for reference.
Baseline: PRs that don't change Gradle files restore
main's setup-java Gradle cache. The Gradle step then spends roughly 25–35 s from Gradle start to the RN Gradle plugin jar, 13–43 s installing NDK 27.1.12297006 (not on the runner image), and 15–30 s in CMake.1. Use the runner's NDK (27.3.13750724) instead of 27.1 (
ndkVersioninexample/android/build.gradle). ubuntu-24.04 image 20260920.314 ships NDKs 27.3.13750724 (the default), 28.2.13676358 and 29.0.14206865. The install step went away, but CMake got slower every time. My guess is cold reads of the preinstalled NDK from the image disk, but I haven't confirmed that:androide2eWith both changes, the warm
androidGradle step took 1m17s and 1m23s, against a 1m18s–2m22s baseline. The 13–25 s saved on the install went into CMake.2. Gradle build cache (
org.gradle.caching=true, with the setup-java key extended toexample/android/gradle.propertiesso a new cache gets saved). setup-java'scache: gradlesaves all of~/.gradle/cachesand~/.gradle/wrapper, sobuild-cache-1is included, but it only saves on a primary-key miss. The build cache worked (46 of 98androidtasks and 22 of 149e2etasks came from cache, including the plugin'scompileKotlin), but the time didn't move:androidGradle stepandroidGradle start → plugin jare2eGradle buildThe plugin's
compileKotlintasks take only about 4 s each on a warm run. Most of the ~25 s before:appconfigures is spent configuring the included build, which the build cache doesn't cover. The build cache added only about 17 MB to the 1.44 GB Gradle cache.Not tried: caching the NDK directory with
actions/cachewould add roughly 0.7 GB (estimated) to the repository's 10 GB cache quota to save at most the 13–25 s install, and a restore of that size takes about as long.gradle/actions/setup-gradlewas left out because it defaults to a proprietary cache provider.Runs: android + e2e with both changes / e2e, build cache only / e2e, baseline android (#33) / e2e on main. Attempt 1 of each PR run is cold; attempts 2–3 are warm reruns.