Allow caching the SDK

[TurpIF]

Hello,

After few runs, I saw that setup of the Android SDK may takes time. I already saw taking a sdkmanager command taking up to 10 minutes.

In order to improve this timing, one can use an actions/cache:

- name: Store Android SDK
   uses: actions/cache@v2
   with:
     path: {{ env.ANDROID_HOME }}
     key: ${{ runner.os }}-android-${{ hashFiles('**/*.gradle*') }}
     restore-keys: ${{ runner.os }}-android-

But this action always remove every traces of a previously setup SDK (why btw ?)

Would it be possible to add an option to check for an existing SDK that was setup by your action and to keep it instead of erasing it and redownloading everything ?
Also, to ease the caching, and ANDROID_HOME env variable could be published by the action.

[Malinskiy]

This has been brought up before in #4
It seems that the size of the cache is now up to 5Gb which should allow us to store the sdk and emulator image also. Let me check this

[Malinskiy]

I've just checked the current runs and the install-sdk is roughly 5-10 seconds. Restoring the cache takes about the same time.

For the emulator package, it's about 40 seconds downloading from the internet. Problem is if you're gonna start testing on multiple emulators (e.g. API 21, 22, 25,26, etc) I think you're going to hit the limit pretty soon, especially if you're also adding the created AVD files.

On top of this, I don't see an easy way to clean the cache ATM. You're gonna have to spawn a fake github workflow to mount the cache, delete the files and then save it back. And the scenario where you share the SDK is going to require cleanup at some point (although the 7 days retention of cache might mitigate this).

With all of the above, I truly believe that caching of android SDK is something that should be outside of the action itself.

Current action design is to remove everything that has android traces in the system (because the default environment has a weird android-sdk without the ability to install packages). This is why the action removes any traces of previous sdk, it considers the cache as an untrusted installation of SDK and moves it to a backup folder.

The envvars are published btw, but you can access them only after the action is executed. And you want to use the cache before the installation so you have a chicken and an egg problem here.

How long are your builds? Are 50 seconds a significant improvement for you?

[TurpIF]

Ok thank you for this detailed explanation.

Our builds last around 25 minutes. So I guess that 50s more or less is not a big deal.
I was just afraid because I saw some sdkmanager call taking lot of time. Finally this don't bother us too much as we changed from a commit based review&CI system to a branch based one.