GH Actions: bust the cache semi-regularly #192
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Caches used in GH Actions do not get updated, they can only be replaced by a different cache with a different cache key.
Now the predefined Composer install action this repo is using already creates a pretty comprehensive cache key:
This means that aside from other factors, the cache will always be busted when changes are made to the (committed)
composer.json
or thecomposer.lock
file (if the latter exists in the repo).For packages running on recent versions of PHP, it also means that the cache will automatically be busted once a month when a new PHP version comes out.
The problem
For runs on older PHP versions which don't receive updates anymore, the cache will not be busted via new PHP version releases, so effectively, the cache will only be busted when a change is made to the
composer.json
/composer.lock
file - which may not happen that frequently on low-traffic repos.But... packages in use on those older PHP versions - especially dependencies of declared dependencies - may still release new versions and those new versions will not exist in the cache and will need to be downloaded each time the action is run and over time the cache gets less and less relevant as more and more packages will need to be downloaded for each run.
The solution
To combat this issue, a new
custom-cache-suffix
option has been added to the Composer install action in version 2.2.0. This new option allows for providing some extra information to add to the cache key, which allows for busting the cache based on your own additional criteria.This commit implements the use of this
custom-cache-suffix
option for all relevant workflows in this repo.Refs:
Proposed Changes
Related Issues