android-actions/setup-android

Tear Down Action

wSedlacek opened this issue · 5 comments

wSedlacek commented

It would be nice if after the job was complete if the downloaded SDK would be automatically deleted.

wSedlacek commented

Maybe using the RUNNER_TEMP folder rather than os.homedir() would be better?

ViliusSutkus89 commented 
const HOME = os.homedir()
const ANDROID_HOME_DIR = path.join(HOME, '.android')
const ANDROID_HOME_SDK_DIR = path.join(ANDROID_HOME_DIR, 'sdk')
let ANDROID_SDK_ROOT = process.env['ANDROID_SDK_ROOT'] || ANDROID_HOME_SDK_DIR

You can workaround this by setting ANDROID_SDK_ROOT environment variable.

We use $HOME/.android/sdk because AFAIK that is the default location for Android SDK tools.

wSedlacek commented

That sounds like a good work around.
Thank you.

My biggest concern would be around multiple runners on the same system trying to modify the same files for setup.

ViliusSutkus89 commented

My biggest concern would be around multiple runners on the same system trying to modify the same files for setup.

I'll go with a definite maybe here. It depends on what happens with RUNNER_TEMP. Also, if you have multiple runners on the same machine, do you really want to constantly reinstall the tools?

wSedlacek commented

Also, if you have multiple runners on the same machine, do you really want to constantly reinstall the tools?

Unless I explicitly cache the install directory that would be my expectations of a CI environment.
That is to say I would expect the only variance run to run to be that of the cache or uncontrollably external circumstances like server load.
Other similar actions like setting up node behave this way as far as I understand, where they reinstall on each attempt.

For permanently changing the environment I would expect to either change the image I am using for the runners or otherwise manually setup the server with the dependencies.

This isn't to say that having it implicitly leave the sdk installed doesn't work, as clearly it does, it just wasn't what I had expected given how other similar actions work.

I'll go with a definite maybe here. It depends on what happens with RUNNER_TEMP

If your concern is around having multiple runners point at this cache, I believe that default and expected use case is that this be unique per runner given that other similar directories like _work need to be unique to function with even basic task like git checkout.

Across all of my self hosted runners this is unique per each one.