cache: macos: gtar: permission denied

Merged and updated tags. @v2 is now on @v2.1.5.

For the moment I’ve moved the v2 tag back to v2.1.3 since this does seem like a pretty big error. This doesn’t follow our normal flow of having a rolling v2 tag that points to the latest tag but we’re making an exception for this. Pinning this issue for visibility

Validated the proposed fix with the mongocli repo:

• Populate cache (@v2.1.3) - https://github.com/dhadka/mongocli/actions/runs/734188204
• Reproduce error (@v2.1.4) - https://github.com/dhadka/mongocli/actions/runs/734198611
• Validate fix (@dhadka/update-1.0.7) - https://github.com/dhadka/mongocli/actions/runs/734211647

and rclone:

• Populate cache (@v2.1.3) - https://github.com/dhadka/rclone/actions/runs/734189339
• Reproduce error (@v2.1.4) - https://github.com/dhadka/rclone/actions/runs/734243868
• Validate fix (@dhadka/update-1.0.7) - https://github.com/dhadka/rclone/actions/runs/734308718

If anyone else wants to test the fix before we publish actions/cache@v2.1.5, change the uses line in your workflow to uses: actions/cache@dhadka/update-1.0.7.

What I meant by “Push out 2.1.4”, was to just move v2 back to the commit that 2.1.4 is pointing to (instead of 2.1.3 like it is right now). There would be no release and new commits would be needed, just a tag update.

We’ve never bumped up the versionSalt before so this would be new and it’s somewhat unknown just how disruptive or harmless this would be. Given the amount of actions/cache users, I’m steering more towards being cautious as breaking workflows or at least significantly slowing them down for a bit is never fun.

@konradpabjan how about just bumping versionSalt? That would have the same effect as @twpayne suggests: avoiding the use of .tar files that were created previously (read: that were created not by gtar)…

I agree it’s possible to detect which version of tar to use to restore the cache. That said, cache invalidation is a famously hard problem, and for correctness it’s generally better to invalidate a little too eagerly rather than risk re-using a stale value. Realistically, the version number of actions/cache changes rarely, so invalidating the cache when the version number changes is unlikely to be very costly.

tl;dr: this affects Go projects. You need to do the following:

1. Set the GOFLAGS=-modcacherw environment variable in your builds on GitHub Actions.
2. Avoid re-using any existing cached data by changing your cache key from ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }} to ${{ runner.os }}-go1.16-${{ hashFiles('**/go.sum') }} (note the change from -go- to -go1.16-) for example (any change in the cache key is fine).

Background:

I’m also hitting this, also trying to cache Go modules.

This is really a conundrum. I suspect that there is something funky going on with permissions, maybe the directory already exists and is write-protected? Or maybe the original permissions are something like 0400 instead of 0555?

Your suspicions are spot-on. By default pkg/mod exists and is write protected, see https://github.com/golang/go/issues/27161 for background info.

You can override this by setting GOFLAGS=-modcacherw as described in the go mod docs:

The -modcacherw flag instructs the go command to create new directories in the module cache with read-write permissions instead of making them read-only. When this flag is used consistently (typically by setting GOFLAGS=-modcacherw in the environment or by running go env -w GOFLAGS=-modcacherw), the module cache may be deleted with commands like rm -r without changing permissions first. The go clean -modcache command may be used to delete the module cache, whether or not -modcacherw was used.

That said, in my own experiments, setting GOFLAGS=-modcacherw in my workflow config with

jobs:
  test:
    env:
      GOFLAGS: -modcacherw

was not sufficient – I still got the same error.

I think this is because actions/cache is downloading an existing tar file that was created when pkg/mod had read-only permissions.

I could not find a way to clear the actions/cache cache, so I changed the cache key from ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }} to ${{ runner.os }}-go1.16-${{ hashFiles('**/go.sum') }} (note the change from -go- to -go1.16-), and, with that change, both building from an empty and a populated cache succeeded.

Refs https://github.com/twpayne/chezmoi/pull/1049