cache: Windows cache restored to wrong path on Linux

I want to store artifact on windows cache and then restore it on linux It is restored but path is not the one i set in path option

steps:

I store it on windows using recommended way of substituting archiver

      - name: Use GNU tar
        if: ${{ runner.os == 'Windows' }}
        shell: cmd
        run: |
          echo "Adding GNU tar to PATH"
          echo C:\Program Files\Git\usr\bin>>"%GITHUB_PATH%"
      - name: Cache jep-distro
        uses: actions/cache@v3
        with:
          path: ~/.jep-distro-${{ runner.os }}
          key: ${{ runner.os }}-jep-distro
          restore-keys: |
            ${{ runner.os }}-jep-distro

and then restore it on linux
- name: Cache jep-distro uses: actions/cache@v3 with: path: ~/.jep-distro-Windows key: Windows-jep-distro restore-keys: | Windows-jep-distro but seems like it restored with full windows path

/usr/bin/tar --use-compress-program unzstd -tf /home/runner/work/_temp/b0ccef32-351b-4867-aab1-b88256a01a66/cache.tzst -P
C:/Users/runneradmin/jep-distro-Windows/
C:/Users/runneradmin/jep-distro-Windows/jep/
C:/Users/runneradmin/jep-distro-Windows/jep/jep.dll
Cache Size: ~0 MB (58208 B)
/usr/bin/tar --use-compress-program unzstd -xf /home/runner/work/_temp/b0ccef32-351b-4867-aab1-b88256a01a66/cache.tzst -P -C /home/runner/work/jep-distro/jep-distro
Cache restored successfully
Cache restored from key: Windows-jep-distro

folder ~/.jep-distro-Windows is not created, and even then created manually it is removed after cache initialization. but i can find it’s content in /home/runner/work/jep-distro/jep-distro/C:/Users/runneradmin/jep-distro-Windows/

About this issue

Original URL
State: closed
Created a year ago
Comments: 18 (17 by maintainers)

Commits related to this issue

Workaround for actions/cache#1059 — committed to devonfw/cobigen by maybeec a year ago
actions/cache#1059 workaround - trying to locate m2 repo in working directory — committed to devonfw/cobigen by maybeec a year ago
Cache after Clone Workaround https://github.com/actions/cache/issues/1059#issuecomment-1378733827 — committed to devonfw-actions/java-maven-setup by maybeec a year ago
Template set deployables (#1633) * #1452 changed dynamic groupId in master-pom.xml to fixed (#1498) * #1452 changed dynamic groupId in master-pom.xml to fixed separated all templates sets into depl... — committed to devonfw/cobigen by maybeec a year ago

Most upvoted comments

Appreciate your feedback @maybeec! Closing this issue for now. Feel free to create a new issue or reopen this if needed.

lvpx on Jan 12, 2023

ok, anyhow thanks for your help @pdotl !

I think the problem remains in a conceptual manner for your CI/CD if building all artifacts on each OS for testing. At the end you are releasing artifacts built on just one OS, which anyhow need to run on all OS. So conceptually such testing approach is not useless, but not coping with the reality. But possibly I need to find a different solution rather than caching for making this possible then.

maybeec on Jan 12, 2023

I tried to remove ~/ from paths, it indeed works but only with enableCrossOsArchive: true. But i see no reason to archive cache with full path, it’s never needed. You can always archive with relative path, related to root folder set in the path. Otherwise it is counterintuitive.

icemachined on Jan 10, 2023

Ok, I got some more details:

Ubuntu: Workspace: '/home/runner/work/cobigen/cobigen'

Maven Repo:

Creating settings.xml with server-id: github
Writing to /home/runner/.m2/settings.xml

Cache Restore:

/usr/bin/tar -tf /home/runner/work/_temp/cef766f2-ede2-4f01-b9af-4bcd8d5de70e/cache.tzst -P --use-compress-program unzstd
../../../.m2/repository/

Windows: Workspace: 'D:\a\cobigen\cobigen'

Maven Repo:

Creating settings.xml with server-id: github
Writing to C:\Users\runneradmin\.m2\settings.xml

Cache Restore:

"C:\Program Files\Git\usr\bin\tar.exe" -tf D:/a/_temp/def350bf-7a6a-4f8f-8c8d-6e76fc1212b0/cache.tzst -P --force-local --use-compress-program "zstd -d"
../../../.m2/repository/

It seems, that the cache restores relative paths, which could be fine. The problem here seems to be the different locations of the workspace. On Linux, the workspace is within the user directory, while on windows the workspace is mounted on a different drive, which is killing the relative path evaluation while extracting the cache.

maybeec on Jan 9, 2023