Skip to content

Use timestamped cache keys (#778) - #779

Open
rvesse wants to merge 1 commit into
anchore:mainfrom
rvesse:cache-fix
Open

rvesse wants to merge 1 commit into
anchore:mainfrom
rvesse:cache-fix

Conversation

@rvesse

@rvesse rvesse commented Oct 6, 2026 •

Copy link
Copy Markdown

Previously the action always used a fixed cache key based on the Grype version. This meant that once the cache was created in a repository it could never be updated because GitHub Actions Cache keys are immutable. This meant that the action was frequently downloading a DB update because the cached DB would quickly become stale. The only time the cache would actually update was if the Grype version was changed.

The action now creates cache keys using the DB build timestamp so when a new DB update is obtained we update the cache with it using a new key. Thus repositories cache up to date versions of the DB and old stale DB caches will naturally be expired and removed by GitHub Actions.

The cache restoration uses restore keys with partial timestamps (day, month, and year) to ensure the most recent cache is always restored, falling back to the legacy cache key used prior to this commit as a restore key.

This fixes #778

Validating

  • Validating this fix against our Grype based workflows where we initially observed the broken caching behaviour
  • Ran action tests locally

@rvesse
rvesse force-pushed the cache-fix branch 6 times, most recently from 90ae4de to 4f7cb50 Compare October 7, 2026 09:48
Previously the action always used a fixed cache key based on the Grype
version.  This meant that once the cache was created in a repository it
could never be updated because GitHub Actions Cache keys are immutable.
This meant that the action was frequently downloading a DB update
because the cached DB would quickly become stale.  The only time the
cache would actually update was if the Grype version was changed.

The action now creates cache keys using the DB build timestamp so when a
new DB update is obtained we update the cache with it using a new key.
Thus repositories cache up to date versions of the DB and old
stale DB caches will naturally be expired and removed by GitHub
Actions.

The cache restoration uses restore keys with partial timestamps (day,
month, and year) to ensure the most recent cache is always restored,
falling back to the legacy cache key used prior to this commit as
a restore key.

Signed-off-by: Rob Vesse <rob.vesse@telicent.io>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Attempting to reuse fixed cache key means database cache is never updated unless Grype version changes

1 participant