cache icon indicating copy to clipboard operation
cache copied to clipboard

Excluded sub directory not working

Open mustaphazorgati opened this issue 4 years ago • 7 comments

Hey there! The README.md provides an example where an excluded sub-path is provided. Unfortunately that sub-path still ends up in the cache. Here is a modified example using the local maven repository.

- name: Cache multiple paths
  uses: actions/cache@v2
  with:
    path: |
      ~/.m2
      !~/.m2/pro/taskana
    key: ${{ runner.os }}-${{ hashFiles('**/lockfiles') }}

Reading out on the next (cached) build the files in ~/.m2/pro/taskana are contained in the cache. The following adjustment didn't work either:

- name: Cache multiple paths
  uses: actions/cache@v2
  with:
    path: |
      ~/.m2
      !~/.m2/pro/taskana/**
    key: ${{ runner.os }}-${{ hashFiles('**/lockfiles') }}

Is this a bug or am I having the wrong expectations? Our current workaround is to delete that subfolder in a dedicated step. It works, but is kinda annoying.

mustaphazorgati avatar Dec 25 '20 05:12 mustaphazorgati

@dhadka I've seen you answering a lof of issues recently. Sorry for asking you directly, but can you have a look at this?

mustaphazorgati avatar Feb 08 '21 09:02 mustaphazorgati

@mustaphazorgati Thanks for reporting this (and sorry I didn't see this earlier). I was able to reproduce this issue. I filed a bug over in the actions/toolkit repo that hosts the underlying logic for search patterns.

dhadka avatar Feb 08 '21 15:02 dhadka

Thank you @dhadka for your quick response! Just an FYI for other readers: The provided reproduction of the issue is found here. @dhadka link shows a workflow where the Post cache test step is not executed ;)

mustaphazorgati avatar Feb 08 '21 22:02 mustaphazorgati

Any update on this issue? (This is making the cache difficult to use in complex workflows)

Adnn avatar Sep 20 '21 18:09 Adnn

@dhadka Since it doesn't appear that this issue will be resolved any time soon, I suggest that you update the example in the README. The current example is misleading since it won't work as expected.

Changing ~/cache to ~/cache/* should be a functional example. ~/cache/* matches all subdirectories, and then !~/cache/exclude will exclude that particular subdirectory.

- name: Cache multiple paths
  uses: actions/cache@v2
  with:
    path: |
      ~/cache/*
      !~/cache/exclude
    key: ${{ runner.os }}-${{ hashFiles('**/lockfiles') }}

bigdaz avatar Oct 21 '21 16:10 bigdaz

FYI guys I added some code pointers to the underlying https://github.com/actions/toolkit/issues/713#issuecomment-1030692990 - for me it seems passing an extra option to avoid matching directiories in the globber would solve this.

robinp avatar Feb 05 '22 20:02 robinp

This issue still exists?

Phantsure avatar Apr 08 '22 10:04 Phantsure

While the issue still exists, the readme file has changed since then and this example is not part of it anymore. Closing this issue in favour of the issue created in the toolkit repo here to fix the problem.

aparna-ravindra avatar Oct 07 '22 09:10 aparna-ravindra

Hey there! The README.md provides an example where an excluded sub-path is provided. Unfortunately that sub-path still ends up in the cache. Here is a modified example using the local maven repository.

- name: Cache multiple paths
  uses: actions/cache@v2
  with:
    path: |
      ~/.m2
      !~/.m2/pro/taskana
    key: ${{ runner.os }}-${{ hashFiles('**/lockfiles') }}

Reading out on the next (cached) build the files in ~/.m2/pro/taskana are contained in the cache. The following adjustment didn't work either:

- name: Cache multiple paths
  uses: actions/cache@v2
  with:
    path: |
      ~/.m2
      !~/.m2/pro/taskana/**
    key: ${{ runner.os }}-${{ hashFiles('**/lockfiles') }}

Is this a bug or am I having the wrong expectations? Our current workaround is to delete that subfolder in a dedicated step. It works, but is kinda annoying.

Jimimaku avatar Nov 21 '22 17:11 Jimimaku