Please create a patch version for the latest hotfix

[m-lautenbach]

@pdotl Hi, Our workflow broke with the latest version even though you created a hotfix that probably fixes our issue. But because there was no new patch version, we didn't get the fix (and reverted to the previous patch version for now). A new patch version would be appreciated 🙏

[lvpx]

Hi @m-lautenbach , we released the hotfix in version 3.2.6. You could use it by either pinning the version to v3.2.6 or the recommended way is to always use actions/cache@v3 tag so you automatically get the patches without changing your workflows. This particular issue is such that it will break your workflows created with the previous version if it was created between Friday and today. I would suggest deleting old caches and creating new ones with the latest version and these should work fine.

[m-lautenbach]

We did the latter one, only major version and it broke. As far as I understand because the fix doesn't have a new version, therefore GitHub takes the buggy version from the cache

[lvpx]

That makes sense, the caches created between today and friday will not be restorable. You will have to create fresh caches from the latest version or simply rerun workflows so the caches get updated. It would also help if you could provide a run so I could investigate further.

[m-lautenbach]

The caches were fine, but we had to pin to actions/cache@v3.2.5 for them to be used again (but we didn't have to recreate them). Unfortunately, it's a commercial project :/

[bishal-pdMSFT]

@m-lautenbach The caches which were created between last Friday till yesterday were using gzip as compression tool and hence can't be restored now using latest version (3.2.6) which uses zstd compression tool. You should preferably use the latest version only so that it will recreate the caches with zstd.

[m-lautenbach]

We'll try that, thank you

[AhmedHulo]

@m-lautenbach The caches which were created between last Friday till yesterday were using gzip as compression tool and hence can't be restored now using latest version (3.2.6) which uses zstd compression tool. You should preferably use the latest version only so that it will recreate the caches with zstd.

I have the same problem, tried to pin the latest version and it's still not working. Will have to pin the earlier version for now. Unfortunately I can't provide a run because it's a private commercial project.

[m-lautenbach]

Sounds like there really is an issue. There was a fix merged after the release was published.

[AhmedHulo]

@m-lautenbach I managed to get it to work. The job was configured to save the cache in a hidden file, and I changed it to save in a non-hidden file.

Code before:

- uses: actions/cache@v3
        id: venv-cache
        with:
          path: ./.venv
          key: ${{ runner.os }}-venv-${{ hashFiles('**/requirements*.txt') }}

Code after:

- uses: actions/cache@v3
        id: venv-cache
        with:
          path: ./venv
          key: ${{ runner.os }}-venv-${{ hashFiles('**/requirements*.txt') }}

Observe the dot before venv, e.g../.venv vs ./venv. I don't know if this is the case for you too, hope this helps.

[lvpx]

@m-lautenbach the release mentioned above is the zstd release and not actions/cache release which broke zstd being used on actions/cache. A patch has been merged and released in actions/cache at v3.2.6 that fixes it. As mentioned above, you need to recreate your caches with the latest release.