With config like this:
- name: Ubuntu cache
uses: actions/cache@preview
if: startsWith(matrix.os, 'ubuntu')
with:
path: ~/.cache/pip
key: ${{ github.workflow }}-${{ github.ref }}-${{ matrix.os }}-${{ matrix.python-version }}
- name: macOS cache
uses: actions/cache@preview
if: startsWith(matrix.os, 'macOS')
with:
path: ~/Library/Caches/pip
key: ${{ github.workflow }}-${{ github.ref }}-${{ matrix.os }}-${{ matrix.python-version }}
It creates a key like "Test-refs/heads/gha-cache-ubuntu-18.04-3.5".
The upload step fails with a 404:
Post Ubuntu cache1s
##[warning]Cache service responded with 404
Post job cleanup.
/bin/tar -cz -f /home/runner/work/_temp/802beeb6-cc68-45cb-a68d-488cc4008df5/cache.tgz -C /home/runner/.cache/pip .
##[warning]Cache service responded with 404
eg. https://github.com/hugovk/Pillow/runs/286812478#step:22:1
That's because github.ref includes slashes (eg. refs/heads/gha-cache):
The branch or tag ref that triggered the workflow. For example,
refs/heads/feature-branch-1. If neither a branch or tag is available for the event type, the variable will not exist.
Should I escape or replace illegal characters (and how?) or should the Action take care of them?
Or is there another way to include the branch name in the key?
@hugovk The storage model for our cache already takes branch into account for the abiliy to read and write caches based on the branch that workflow is being run out of. With this model we don't think the branch should be used as part of the key in the majority of cases so we don't have an easy way to do that right now.
Could you give me a bit of information about why the branch is necessary in your key?
The full documentation will go up today that has the details about the caching featuer should go up today.
Thanks, sounds like I don't need this after all!
I was concerned that a cache for a branch may be used on another, and possibly putting stuff in the other branch's cache that wasn't needed.
@chrispat nice!
The storage model for our cache already takes branch into account for the abiliy to read and write caches based on the branch that workflow is being run out of.
Does that include “inheriting” the caches from the base branch of a pull request? ie when building a pull request targeting master the first time, will that pick up the cache from master?
Also, should that be added to the documentation?
Does that include “inheriting” the caches from the base branch of a pull request? ie when building a pull request targeting master the first time, will that pick up the cache from master?
Yep, PRs are able to read from the cache of master (or default branch) but will write to the cache of the PR branch. We're working on more comprehensive documentation.
Most helpful comment
Yep, PRs are able to read from the cache of master (or default branch) but will write to the cache of the PR branch. We're working on more comprehensive documentation.