Can't store using hashFiles if files don't exist yet

For example, in a Rust project, the target directory is almost never committed as it includes build artifacts. I’d like to cache it between builds, but using

name: Cache target dir
uses: actions/cache@v1
with:
  path: target
  key: ${{ runner.os }}-cargo-target-${{ hashFiles('target') }} # also tried variants of `target/**`...

triggers a failure that prevents the build from continuing:

##[error]The template is not valid. hashFiles('/home/runner/work/.../.../target') failed. Search pattern '/home/runner/work/.../.../target' doesn't match any file under '/home/runner/work/.../...'

which does make sense! After checking out, there is not yet a target directory. In fact, that’s what I aim to create (maybe) when I restore from the cache. So storing would work with this template, but restoring would not, since the key can’t be computed.

If I supply restore-keys, though, I still get the same error. It seems to me like something (maybe not in this codebase) is just dying early because the template isn’t fully computable, instead of trying to fall back on the restore-keys first.

[chrispat]

@rye perhaps we could update hashFiles with an additional parameter that you could set that would have it not fail if it didn’t find any files. I suppose the other option is to simply warn rather than fail, however, that would mean in your case that you would perpetually have a warning on your jobs that you could likely never get rid of.

[rye]

I do agree that the current error form makes things stricter, but I don’t think the strictness is helpful—a hashFiles error (due to files not existing) seems to be causing a parsing error, i.e. restore_keys is not even used at all; the cache restore just completely fails. My use case would be satisfied if restore_keys was used in such cases.

Of course, I could leave off the hashFiles in my key, but then I would basically have a persistent cache that never got updated if things changed.