Downloaded NDK zip and temp extract are left on filesystem

[mikehardy]

Hi there 👋 - thanks for putting this action together

I noticed that when I tried to integrate it into one of my more storage-intensive workflows that I ran out of storage space during the test run

It seems that after tc.downloadTool + tc.extractZip + tc.cacheDir the downloaded Zip (~1GB) and then the temp directory full of the extracted zip (~3GB?) are left setting in the actions runner temp directory, even though all the following work uses the directory from tc.cacheDir (or optionally from local cache copy if people are using that)

Is there any reason not to attempt to clean up that zip and temp unzip dir after the tc.cacheDir call?

Seems like it may be possible they'll fail (for instance, on windows, with antivirus holding file handles open etc) but a best-effort try/catch could be done on a recursive delete there

Would you be open to a PR that implements that?

Cheers

[raftario]

Hey ! I'd definitely be open to a PR for this, I kinda ran with the assumption that the actions toolkit would take care of cleaning up and never checked.