Based on @joshmgross's latest comment in https://github.com/actions/cache/issues/133#issuecomment-629381394, here's my use case, same as @evandrocoan https://github.com/actions/cache/issues/133#issuecomment-602695437...
caching Apt list and package files in Ubuntu
The Apt step here takes about 35 seconds without caching. I'm hoping the cache will improve that. I'm also not 100% sure about the paths because I haven't been able to test it yet.
- name: Use Apt lists cache
uses: actions/cache@v1
with:
path: /var/lib/apt/lists
key: ${{ runner.os }}-apt-lists
- name: Use Apt packages cache
uses: actions/cache@v1
with:
path: /var/cache/apt
key: ${{ runner.os }}-apt-packages
- name: Install Apt dependencies
run: |
sudo apt-get update
sudo apt-get install -y liblua5.1-dev luarocks
Post job cleanup.
/bin/tar -cz -f /home/runner/work/_temp/207e89c2-b0e5-4443-915a-2eafc37bc59b/cache.tgz -C /var/cache/apt .
/bin/tar: ./archives/partial: Cannot open: Permission denied
/bin/tar: ./archives/lock: Cannot open: Permission denied
/bin/tar: Exiting with failure status due to previous errors
[warning]Tar failed with error: The process '/bin/tar' failed with exit code 2
It has nothing to do with the problem itself, but you should think a little more about caching. Downloading and decompressing are also costly. Considering those, is 35 seconds really long? In my opinion, it's not.
And the current setup doesn't guarantee that the contents of /var/lib/apt/lists will not be changed.
Hmm I suppose 35 seconds isn't that long, but I'm not sure what the total Apt time will be if we start installing more packages.
Semaphore (another CI/CD platform) recommends 10 minutes as the maximum time for continuous integration. Any longer, and developers start changing their behaviour to work around the build system.
So depending on what your current times are, I think that saving 30 seconds or 1 minute can help.
In my opinion, there is basically no need to run an update. It's probably faster if you don't do it. Also, the package manager is not a build system; it probably won't be slower than you think. (Unless you specify that explicitly.)
I fixed a similar issue by setting the restore target's permissions with chmod -R a+rwx before the caching step. The restore seems to action correctly with this, but it for sure would be better not to have to do this.
This took a 16min build down to 1min, because a full compile step for a utility binary could be skipped; no need to install the language's runtime, clone the remote repo, then build and install the binary.
Saving time matters for GH Actions. Anything that can be done to reduce the time for them to complete, even if it's only a few seconds, can have a big impact.
I was able to at least successfully _save_ a cache of the downloaded .deb packages with this step:
- name: Cache APT packages
uses: actions/cache@v2
with:
path: |
/var/cache/apt/archives/**.deb
!/var/cache/apt/archives/partial
!/var/cache/apt/archives/lock
key: ${{ runner.os }}-apt
However, when attempting to restore this cache, the attempt to extract these cached files still results in Cannot open: Permission denied errors for each file:
Received 0 of 85361645 (0.0%), 0.0 MBs/sec
Received 71303168 of 85361645 (83.5%), 34.0 MBs/sec
Received 85361645 of 85361645 (100.0%), 35.8 MBs/sec
Cache Size: ~81 MB (85361645 B)
/bin/tar --use-compress-program zstd -d -xf /home/runner/work/_temp/6cb673f4-802b-4627-a69c-fc30b46f495f/cache.tzst -P -C /home/runner/work/haxe/haxe
/bin/tar: ../../../../../var/cache/apt/archives/autopoint_0.19.8.1-6ubuntu0.3_all.deb: Cannot open: Permission denied
/bin/tar: ../../../../../var/cache/apt/archives/bubblewrap_0.2.1-1ubuntu0.1_amd64.deb: Cannot open: Permission denied
â‹®
â‹® (50 more lines omitted)
â‹®
/bin/tar: ../../../../../var/cache/apt/archives/x11proto-randr-dev_2018.4-4_all.deb: Cannot open: Permission denied
/bin/tar: ../../../../../var/cache/apt/archives/x11proto-xinerama-dev_2018.4-4_all.deb: Cannot open: Permission denied
/bin/tar: Exiting with failure status due to previous errors
Warning: Tar failed with error: The process '/bin/tar' failed with exit code 2
If we could just have an option for running the /bin/tar command as sudo, that would make this tool significantly easier to use for caching system packages (like those installed by apt).