Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GH Actions: bust the cache semi-regularly #129

Merged
merged 1 commit into from
Dec 11, 2022

Conversation

jrfnl
Copy link
Collaborator

@jrfnl jrfnl commented Nov 4, 2022

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:

ramsey/composer-install will auto-generate a cache key which is composed of
the following elements:

  • The OS image name, like ubuntu-latest.
  • The exact PHP version, like 8.1.11.
  • The options passed via composer-options.
  • The dependency version setting as per dependency-versions.
  • The working directory as per working-directory.
  • A hash of the composer.json and/or composer.lock files.

This means that aside from other factors, the cache will always be busted when changes are made to the (committed) composer.json or the composer.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:

@jrfnl jrfnl added this to the 2.0.0 milestone Nov 4, 2022
@jrfnl jrfnl requested a review from grogy November 4, 2022 18:53
@jrfnl jrfnl force-pushed the feature/ghactions-cache-busting branch 2 times, most recently from 47b92b2 to 1911d91 Compare December 9, 2022 01:23
Copy link
Member

@grogy grogy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the PR. Described problem is interesting and I agree with reset cache every month. 👍

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:

> `ramsey/composer-install` will auto-generate a cache key which is composed of
the following elements:
> * The OS image name, like `ubuntu-latest`.
> * The exact PHP version, like `8.1.11`.
> * The options passed via `composer-options`.
> * The dependency version setting as per `dependency-versions`.
> * The working directory as per `working-directory`.
> * A hash of the `composer.json` and/or `composer.lock` files.

This means that aside from other factors, the cache will always be busted when changes are made to the (committed) `composer.json` or the `composer.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:
* https://github.com/ramsey/composer-install/#custom-cache-suffix
* https://github.com/ramsey/composer-install/releases/tag/2.2.0
@jrfnl jrfnl force-pushed the feature/ghactions-cache-busting branch from 1911d91 to 48af24f Compare December 11, 2022 03:31
@jrfnl
Copy link
Collaborator Author

jrfnl commented Dec 11, 2022

I hadn't noticed the build failure before. Rebased now and the build passes (failure was unrelated to this PR, but due to Composer running into rate limiting).

@grogy grogy merged commit 76e04c7 into develop Dec 11, 2022
@grogy grogy deleted the feature/ghactions-cache-busting branch December 11, 2022 06:21
@jrfnl jrfnl modified the milestones: 2.0.0, 1.3.x Next Mar 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

2 participants