search

actions / cache

Cache dependencies and build outputs in GitHub Actions
MIT License
4.36k stars 1.16k forks source link

Incomplete key restores arbitrary cache object #1385

Open socketbox opened 2 months ago

socketbox commented 2 months ago

In a workflow job, I mistakenly use an empty/null variable reference as part of a cache key:

      - name: Restore webpack from cache
        id: staging-cache-webpack-restore
        uses: actions/cache/restore@v4
        with:
          path: core/static/
          key: frontend-${{ a.bad.reference}}

There are many objects in the repository cache:

[2024-04-24 18:39:08]» gh cache list

Showing 12 of 12 caches in the/repo:

ID      KEY                                                                       
619986  frontend-c0fb152656158325adbadbac9f3f7f1015e191da461bf0236c0b27193c38dd02 
619989  frontend-f84bc9c3703dbce2545dc518502d0621273c904721c1e2e8870fa7b9e496192c 
619985  frontend-f84bc9c3703dbce2545dc518502d0621273c904721c1e2e8870fa7b9e496192c 
619988  frontend-0ba8a9892199a366b7a161e86b40c282b7e03f105204ddedf7e2dc6b55e51e5f 
619984  frontend-39f77b9e35125bd3ab008ef19553e82fa69091eae3e18693ff6ed2659e1812e3 
619983  frontend-46162d1a09f0e494f0b378e2803ba36d26c83e2c78fded5d4c5ce21a316dd913 
619982  frontend-41e9d15342fc13460938c6d89743e897fb899935ad41807c5e0073fc25c6c0be 
619981  frontend-a407e089948b9400e31003517e9c70a4d4dc0fe058a5d5c1cffb82c3d7b34528 
619980  frontend-9c393aabd606f80cb230883cd9e0bfcba678d42174a61c05051e87b8bef8b31c 
619979  frontend-9c393aabd606f80cb230883cd9e0bfcba678d42174a61c05051e87b8bef8b31c 
619978  frontend-b2ae2178894bcf777b4238f05cb819cb55c45c173a0eb3378d6b4efb93de1a23 
619977  frontend-4c434d2a5d9da90fd058bf1fb99c9999b13dc9c097029f5514c1f6f53a05db1b

Logs (and site behavior) show that a cache object was retrieved:

2024-04-24T21:24:04.9906224Z ##[group]Run actions/cache/restore@v4
2024-04-24T21:24:04.9906900Z with:
2024-04-24T21:24:04.9907330Z   path: core/static/
2024-04-24T21:24:04.9907835Z   key: frontend-
2024-04-24T21:24:04.9908366Z   enableCrossOsArchive: false
2024-04-24T21:24:04.9908919Z   fail-on-cache-miss: false
2024-04-24T21:24:04.9909279Z   lookup-only: false
2024-04-24T21:24:04.9909585Z env:
2024-04-24T21:24:04.9909848Z   AWS_RETRY_MODE: adaptive
2024-04-24T21:24:04.9910182Z   AWS_MAX_ATTEMPTS: 7
2024-04-24T21:24:04.9910530Z   VCS_REF: RWEB-8083-no-more-memcached
2024-04-24T21:24:04.9922686Z ##[endgroup]
2024-04-24T21:24:06.5318607Z Cache Size: ~34 MB (35752506 B)
2024-04-24T21:24:06.5358359Z [command]/usr/bin/tar -xf /home/runner/work/_temp/a086ad5f-06da-4dbc-944f-46b2e166a0eb/cache.tzst -P -C /home/runner/work/pbsorg/pbsorg --use-
ácompress-program unzstd
2024-04-24T21:24:06.5445467Z Received 35752506 of 35752506 (100.0%), 34.1 MBs/sec
2024-04-24T21:24:06.6974200Z Cache restored successfully
2024-04-24T21:24:06.7248496Z Cache restored from key: frontend-f84bc9c3703dbce2545dc518502d0621273c904721c1e2e8870fa7b9e496192c

As can be seen in the first part of the log, the cache key is frontend-. It's missing a hash because I passed in a reference that could not be resolved. And yet, actions/cache/restore picks a cache object and uses it, silently.

Correct me if I'm wrong, but setting fail-on-cache-miss to True would not have helped to prevent this behavior.

EDIT: In reading more of the docs, this section regarding restore-keys seems to describe the behavior I'm seeing. It's as if there's a default value for restore-keys (I'm definitely not passing one in).