cache restore on versions 3 and 4 not working

@v4

The functionality of the cache action seems to be completely broken.

Configurations attempted:

save/restore actions @v4
save/restore actions @V3
base cache action @v4
base cache action @V3

Experimental Workflow and Results

The cache is being accessed on the same branch, in the same workflow (and later, if the first set of jobs pass).

These screenshots pertain to the run of base cache action @V3, they are consistent across all configurations.

Cache version 2 works as expected.

Would definitely prefer to use the most recent versions.

~~Cause of the above issue is a difference in the actions/checkout version. There must be a difference in the way they reference the branch.~~

Im currently getting:

Failed to save: Unable to reserve cache with key db09ccc890352b660ddd94bbcf7ce4b880b254099c5050c6059b00b0b4c5777e, another job may be creating this cache. More details: Cache already exists.

Not sure if its related but even deleting all caches it wont recreate them...

Same issue here. Have been wracking my brain why this doesn't work and then wanted to eventually open an issue and found out there's one already.
Trying v2 now as recommended above.

upd: v2 works as expected

@mark-jordanovic-lewis

@mark-jordanovic-lewis just to ensure, do you have exactly same value in the "path" parameter both in save and restore? I had different and restore failed too.

Correct. Same parameters in each use of the action.

fix(build,ci): downgrade to cache action v2

We are seeing similar issues on v4 where the cache is not found despite clearly existing, only 1/5 runs are picked up correctly, is the cache action not reliable-ish?

I encountered the same issue. Save v4 + restore v2 cannot work as well. Using save v2 + restore v2 can resolve the problem. However, it seems that Node.js 16 is going to be deprecated.

I encountered the same issue. Save v4 + restore v2 cannot work as well. Using save v2 + restore v2 can resolve the problem. However, it seems that Node.js 16 is going to be deprecated.

I just found the reason: in v4, the path for restore and save must be the same. The error message doesn't give such information.

@njzjz

@njzjz I'm encountering this problem too and the paths are the same for me

#1 El dom, 26 de may. de 2024 19:55, Wout Mertens ***@***.***> escribió:

…

@njzjz <https://github.com/njzjz> I'm encountering this problem too and the paths are the same for me — Reply to this email directly, view it on GitHub <#1361 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BGG5ZMWZ5SQ7TVB3OGEP663ZEGINXAVCNFSM6AAAAABE574CB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZSGEYTSMRYGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Facing the same issue, any fix anytime soon?

I encountered the same issue. Save v4 + restore v2 cannot work as well. Using save v2 + restore v2 can resolve the problem. However, it seems that Node.js 16 is going to be deprecated.

restore v2 does not exist. it's only cache v2

I just realized I had a trailing slash in one of the places and not the others. Now I made sure all the path strings are exactly the same and it seems to work without issues.

I confirm that caching works after:

Prefixing each path of the path: value with ./;
Having the exact same path: value for save and restore (I had wildcards in the save action path).

Qual: Fix caching for windows workflow (#30705)

Qual: Fix caching for windows workflow (#30705) (#30728)

Prefix cache path with `./`

Prefix cache paths with `./`

Call `Pkg.resolve()` before hashing Manifest (#519)

Just want to highlight that we're also having problems with v3 and v4.

Our build (at a high level) does this:

(1) Download dependencies (using Composer as it's a PHP app, but I don't think that detail is important) and cache them using actions/cache/save@v4
(2a) Build frontend assets (after restoring Composer dependencies with actions/cache/restore@v4)
(2b) Run static analysis (after restoring Composer dependencies with actions/cache/restore@v4)
(3) Run tests

Steps (2a) and (2b) need step (1) and run concurrently after step (1) is finished. The call to actions/cache/restore@v4 works in step 2b and fails in step 2a.

After reverting to v2 this works as expected.

Our workflow file looks something like the following:

name: Tests

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches:
      - '**'

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:

  composer_install:
    name: Install composer dependencies
    runs-on: ubuntu-latest
    container:
      image: jakzal/phpqa:php8.3-alpine
    steps:
      - uses: actions/checkout@v4
      - name: Cache composer dependencies
        uses: actions/cache/save@v4
        id: cache-composer
        with:
          path: vendor
          key: composer-${{ hashFiles('composer.lock') }}
      - name: Install composer dependencies
        run: composer install --prefer-dist --no-ansi --no-interaction --no-progress

  build_frontend:
    name: Build frontend
    runs-on: ubuntu-latest
    needs: [composer_install]
    container:
      image: node:20.11.0
    steps:
      - uses: actions/checkout@v4
      - name: Cache frontend build
        uses: actions/cache/save@v4
        id: cache-frontend
        with:
          path: public/build
          key: npm-${{ hashFiles('package-lock.json') }}
      - name: Restore composer cache
        uses: actions/cache/restore@v4
        id: restore-composer-cache
        with:
          path: vendor
          key: composer-${{ hashFiles('composer.lock') }}
          fail-on-cache-miss: true
      - name: Install dependencies
        run: npm ci
      - name: Build
        run: npm run build

  static_analysis_check:
    name: Check static analysis
    runs-on: ubuntu-latest
    container:
      image: jakzal/phpqa:php8.3-alpine
    needs: [composer_install]
    steps:
      - uses: actions/checkout@v4
      - name: Restore composer cache
        uses: actions/cache/restore@v4
        id: restore-composer-cache
        with:
          path: vendor
          key: composer-${{ hashFiles('composer.lock') }}
          fail-on-cache-miss: true
      - name: Run PHPStan analysis
        run: php -d memory_limit=-1 vendor/bin/phpstan analyze --error-format=github

  tests:
    name: Run tests
    runs-on: ubuntu-latest
    container:
      image: jakzal/phpqa:php8.3-alpine
    needs: [composer_install, build_frontend]
    steps:
      - uses: actions/checkout@v4
      - name: Restore composer cache
        uses: actions/cache/restore@v4
        id: restore-composer-cache
        with:
          path: vendor
          key: composer-${{ hashFiles('composer.lock') }}
          fail-on-cache-miss: true
      - name: Restore frontend cache
        uses: actions/cache/restore@v4
        id: restore-frontend-cache
        with:
          path: public/build
          key: npm-${{ hashFiles('package-lock.json') }}
          fail-on-cache-miss: true
      # snip... not relevant after this line

Had a similar issue as many in this thread.

Can confirm that it works with an absolute path, inputted identically as path in the restore and save actions (v4).

Would not be an issue IMO if the documentation was clearer on this.

So cache@v2 is going to be deprecated soon which makes this all the more difficult as there will be a required upgrade to v3/v4 now: https://github.com/actions/cache?tab=readme-ov-file#whats-new

The cache backend service has been rewritten from the ground up for improved performance and reliability. actions/cache now integrates with the new cache service (v2) APIs.

The new service will gradually roll out as of February 1st, 2025. The legacy service will also be sunset on the same date. Changes in these release are fully backward compatible.

We are deprecating some versions of this action. We recommend upgrading to version v4 or v3 as soon as possible before February 1st, 2025. (Upgrade instructions below).

If you are using pinned SHAs, please use the SHAs of versions v4.2.0 or v3.4.0

If you do not upgrade, all workflow runs using any of the deprecated actions/cache will fail.

Upgrading to the recommended versions will not break your workflows.

Read more about the change & access the migration guide: #1510.

Is GitHub really going to sit on this and let it break for everyone without trying to clarify it?

Just want to highlight that we're also having problems with v3 and v4.

Our build (at a high level) does this:

(1) Download dependencies (using Composer as it's a PHP app, but I don't think that detail is important) and cache them using actions/cache/save@v4 (2a) Build frontend assets (after restoring Composer dependencies with actions/cache/restore@v4) (2b) Run static analysis (after restoring Composer dependencies with actions/cache/restore@v4) (3) Run tests

Steps (2a) and (2b) need step (1) and run concurrently after step (1) is finished. The call to actions/cache/restore@v4 works in step 2b and fails in step 2a.

After reverting to v2 this works as expected.

Not sure if it helps anyone else, but just wanted to highlight that we were able to fix the issue by:

using relative path values, e.g: path: ./vendor.
using exactly the same base image in all steps. When using different base images the cache is doesn't appear to be shared. This is not ideal for our use-case but is a workable solution 🤷‍♂️

Godspeed and good luck!

The base image (assuming this means the runs-on: name) seems to be newly case sensitive in the new backend. I couldn't find this documented anywhere.

[ci] fix macOS testing

Navigation Menu

Repository navigation

cache restore on versions 3 and 4 not working #1361

Cache version 2 works as expected.

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

cache restore on versions 3 and 4 not working #1361

Description

Cache version 2 works as expected.

Activity

mark-jordanovic-lewis commented on Mar 20, 2024

matthiasPOE commented on Mar 20, 2024

serpro69 commented on Mar 22, 2024

yrtimiD commented on Apr 7, 2024

mark-jordanovic-lewis commented on Apr 7, 2024

SimonSchick commented on May 2, 2024

njzjz commented on May 14, 2024

njzjz commented on May 24, 2024

wmertens commented on May 26, 2024

lsdm83114 commented on May 26, 2024

MostefaKamalLala commented on Jun 5, 2024

10 remaining items

wmertens commented on Jul 18, 2024

mdeweerd commented on Aug 21, 2024

coreymcmahon commented on Nov 17, 2024

JJ-Kamminga commented on Dec 3, 2024

hammzj commented on Jan 22, 2025

coreymcmahon commented on Jan 24, 2025

aryairani commented on Feb 11, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions