The action doesn't work when we cache the `/home/runner/.asdf` folder with Github Cache action

[andyduong1920]

Hi all, thank you for creating this action.

Problem

We are starting to use this action on our CI workflow; it's working well. The only issue is we can't cache the asdf directory to reduce the installation time.

The installation step takes more than 3 minutes.

We tried to cache that with the Github cache feature by caching the /home/runner/.asdf folder. It ends up with the following error.

Expectation

The action should work with the Github cache. If the asdf or plugins exist in /home/runner/.asdf. Install them directly.

[andyduong1920]

Just an update we just figure out 1 work around way following #235 (comment)

[andyduong1920]

Just an update, we could also remove the if: steps.asdf-cache.outputs.cache-hit != 'true' there, the asdf-vm/actions/install@v1 could determine which plugin has been installed

[andyduong1920]

Our final solution so far

- name: Setup asdf
  uses: asdf-vm/actions/setup@v1

- name: Cache asdf
  uses: actions/cache@v2
  with:
    path: |
      /home/runner/.asdf
    key: ${{ runner.os }}-asdf-${{ hashFiles('**/.tool-versions') }}
    restore-keys: |
      ${{ runner.os }}-asdf-

- name: Install dependencies in .tool-versions
  uses: asdf-vm/actions/install@v1

[TPXP]

This should have been fixed with 4907cdf, released in v2.2.0

[vorburger]

This should have been fixed with 4907cdf, released in v2.2.0

I'm still seeing this with asdf-vm/actions/install@v3 (e.g. here for this after introducing it here)... 😢

Run asdf-vm/actions/install@v3
Updating asdf in ASDF_DIR "/home/runner/.asdf" on branch "v0.14.0"
/usr/bin/git remote set-branches origin v0.14.0
/usr/bin/git fetch --depth 1 origin v0.14.0
From https://github.com/asdf-vm/asdf
 * tag               v0.14.0    -> FETCH_HEAD
/usr/bin/git checkout -B v0.14.0 origin
fatal: 'origin' is not a commit and a branch 'v0.14.0' cannot be created from it
Error: Action failed with error Error: The process '/usr/bin/git' failed with exit code 12[8](https://github.com/enola-dev/enola/actions/runs/7934143903/job/21664454692?pr=483#step:11:9)

[pieterbreed]

Is there perhaps an update on this issue?