Speed-up with cache

[enricopesce]

Hi ! Thank you for this action!

I'm looking to speed-up my workflow, how can I cache Minikube setup and reuse the cache without re-downloading Minikube in every iteration?

[medyagh]

that would be a great idea if Github Action would cache minikube images but I asked them they cant fit the all the k8s images in the cache

but if someone interested they could ask again from github environments managers to run
"minikube start --download-only" in every image they build that would save a lot of users time

[medyagh]

@enricopesce I see some other github actions like "kubectl" use this folder " /opt/hostedtoolcache/"

/opt/hostedtoolcache/kubectl/1.23.1/x64/kubectl

do u think it would be helpful if minikube installs itself in that folder as well ?

[ddl-ssenecal]

I'm wondering if the cache could be used to accomplish this. It would be nice, since the k8s images are quite large, so it wastes a lot of bandwidth and time to download them over and over again.

I suspect in order to use the cache though, we would need to expose a "download only" mode for the action, and then a separate "start" mode, which would then be used to actually start the download image.

[ddl-ssenecal]

For anyone who finds this, I was able to cache the minikube preload by using the cache action:

    - name: Cache minikube images
      uses: actions/cache@v3
      with:
        path: |
          ~/.minikube/cache
        key: minikube
    - name: Start Minikube
      id: minikube
      uses: medyagh/setup-minikube@master

The only problem with this approach is that the kicbase image is not included in the offline cache, so you still end up having to download a relatively large image each time. It seems this PR enables offline caching of the kicbase image, but requires the user to run --download-only=true to trigger it. If anyone knows a way to trigger --download-only=true, I think we can cache all downloaded images and speed things up a little bit. That said, this won't be a silver bullet either, as the downloads don't represent the lions share of the minikube startup time.

[medyagh]

@ddl-ssenecal thank you very much for informing me on this,
I dont know much about this topic, is it possible to have a cache in a more global way ? like all preload images be cached for a larger github action users ? or is it among only jobs of same Repo ?

and do the users have to add the block that you mentioned ?

    - name: Cache minikube images
      uses: actions/cache@v3
      with:
        path: |
          ~/.minikube/cache
        key: minikube

if the users have to do it, maybe I should add that to the readme as a good practice.
does that block cache it for period of time on same repo ? or only caches it for same job if it uses minikube multiple times?

[ddl-ssenecal]

I don't have a lot of details either. However, no, I don't think its possible to have a global cache, and this cache it per repo I believe. Adding that block helps by caching some of the binaries that need to be downloaded, but not all of them, so in the end it didn't make a huge difference in the startup time. If someone were able to figure out how to pass the --download-only=true parameter to minikube to cache the kicbase image as well, then it would likely be valuable to add to the README as it would be useful for more people then.

[spowelljr]

Created a PR to enable caching of ISO, kicbase, and preload. Will also add binary caching in the future.

#46