Open daxpedda opened 1 year ago
This issue is stale because it has been open for 200 days with no activity. Leave a comment to avoid closing this issue in 5 days.
This is still relevant.
I'm also seeing this issue with v4.
I encountered this today as well in my Github Action workflow.
Caching step:
- name: Get cached deps
id: caching
uses: actions/cache@v4
with:
path: |
deps
_build
vendor/**/_build
key: app-ci-cache-${{ runner.os }}-${{ vars.ELIXIR_VERSION }}-${{ vars.ERLANG_OTP_VERSION }}-${{ hashFiles('**/mix.lock') }}-${{ env.MIX_ENV }}
restore-keys: |
app-ci-cache-${{ runner.os }}-${{ vars.ELIXIR_VERSION }}-${{ vars.ERLANG_OTP_VERSION }}-${{ hashFiles('**/mix.lock') }}-${{ env.MIX_ENV }}
app-ci-cache-${{ runner.os }}-${{ vars.ELIXIR_VERSION }}-${{ vars.ERLANG_OTP_VERSION }}-${{ hashFiles('**/mix.lock') }}
app-ci-cache-${{ runner.os }}-${{ vars.ELIXIR_VERSION }}-${{ vars.ERLANG_OTP_VERSION }}
Logs for the caching step. Looks like it picked up a cache from a key match.
Run actions/cache@v4
Received 50331648 of 261905428 (19.2%), 48.0 MBs/sec
Received 184549376 of 261905428 (70.5%), 87.9 MBs/sec
Cache Size: ~250 MB (261905428 B)
/usr/bin/tar -xf /home/runner/work/_temp/112d0137-56de-423b-ab50-e509306e7d1c/cache.tzst -P -C /home/runner/work/app/app --use-compress-program unzstd
Received 261905428 of 261905428 (100.0%), 83.1 MBs/sec
Cache restored successfully
Cache restored from key: app-ci-cache-Linux-1.14.5-26.2.3-8f6fd92be06bc44[20]
Then in a downstream setup step:
- name: Install Dependencies and Compile
if: steps.caching.outputs.cache-hit != 'true'
run: |
mix setup
Logs for this setup step. It didn't obey the cache-hit
.
Run mix setup
Resolving Hex dependencies...
Resolution completed in 2.769s
Unchanged:
absinthe 1.6.[8]
absinthe_plug 1.5.8
absinthe_relay 1.5.2
acceptor_pool 1.0.0
b64fast 0.2.3
bamboo 2.2.0
bamboo_phoenix 1.0.0
I've been using something as simple as:
But for some reason, if the cache doesn't exist, it actually matches on a different key, in this case I've named another cache
rustfmt
:It seems to me that the documentation is pretty clear that
key
is used for exact matches andrestore-keys
for partial matches. Furthermoresteps.restore.outputs.cache-hit
is actually set totrue
.Is this a bug, or did I misunderstand the documentation?