Use macOS runners for Android instrumentation #632
Merged
Conversation
This file contains 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
After some time with GitHub Actions I do not see significant difference between GHA and CircleCI when running Android instrumentation tests on Linux hosts. Both are a complete pile of ██████-█████ ████, sadly. You can read more about sorrows of Android instrumentation here [1]. Linux runners are able to run ARM emulator with API 24 which is so slow that it occasinally fails to boot. Hardware accelerated x86 are not available because KVM is not available on VMs offered by GitHub and CircleCI. In fact, x86 emulator on Linux *requires* KVM. API 24 is the last level which provides ARM emulator, it's all x86/AMD-64 after that. So using ARM & API 24 is a ticking time bomb, waiting for Google to deprecate and remove API 24 from SDK installers. On the other hand, macOS runners offered by GitHub support HAXM acceretion and are able to run x86 Android emulators. Thankfully, the author of the rant [1] has also written an Action which installs Android SDK and related stuff [2] which also supports macOS. Let's run out integration tests on macOS runners. They cost x10 compared to Linux ones, but thanks to Microsoft's generocity open-source projects can use them for free. I'll gratefully take up the offer. Also, remove caching of Gradle stuff and Android SDK. While then *do* download lots of crap from the Internet (~2 GB each), it appears that packing, uploading, downloading, and unpacking caches takes comparable amount of time so caching does not reduce build times. GitHub Actions bill by build time, not traffic. And Google's mirrors are usually available so there is no real reason to use caches in this situation. *fingers crossed* Let's see how this works. If it consistently shows better build times and stability, I'm going to remove Android integration from CircleCI and rely solely on GitHub Actions, because I'm tired of that job *constantly* failing due to this ███████ emulator not booting. [1]: https://dev.to/ychescale9/running-android-emulators-on-ci-from-bitrise-io-to-github-actions-3j76 [2]: https://github.com/reactivecircus/android-emulator-runner
ilammy
added
O-Android 🤖
Lagovas
approved these changes
Apr 30, 2020
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.
After some time with GitHub Actions I do not see significant difference between GHA and CircleCI when running Android instrumentation tests on Linux hosts. Both are a complete pile of ██████-█████ ████, sadly. You can read more about sorrows of Android instrumentation here.
Linux runners are able to run ARM emulator with API 24 which is so slow that it occasionally fails to boot. Hardware accelerated x86 are not available because KVM is not available on VMs offered by GitHub and CircleCI. In fact, x86 emulator on Linux requires KVM. API 24 is the last level which provides ARM emulator, it's all x86/AMD64 after that. So using ARM & API 24 is a ticking time bomb, waiting for Google to deprecate and remove API 24 from SDK installers.
On the other hand, macOS runners offered by GitHub support HAXM acceleration and are able to run x86 Android emulators. Thankfully, the author of the rant above has also written an Action which installs Android SDK and related stuff which also supports macOS.
Let's run out integration tests on macOS runners. They cost x10 compared to Linux ones, but thanks to Microsoft's generosity open-source projects can use them for free. I'll gratefully take up the offer.
Also, remove caching of Gradle stuff and Android SDK. While then do download lots of crap from the Internet (~2 GB each), it appears that packing, uploading, downloading, and unpacking caches takes comparable amount of time so caching does not reduce build times. GitHub Actions bill by build time, not traffic. And Google's mirrors are usually available so there is no real reason to use caches in this situation.
🤞
Let's see how this works. If it consistently shows better build times and stability, I'm going to remove Android integration from CircleCI and rely solely on GitHub Actions, because I'm tired of that job constantly failing due to this ███████ emulator not booting.
Checklist
Changelog is updated(no real need)