Better cache busting when using dependency-versions: 'highest'

[desrosj]

Better cache busting when using highest dependency versions

Using dependency-versions: 'highest' is the equivalent to running composer update, ensuring the latest versions of these dependencies are always used.

When it comes to cache keys, the key is unaware of when updates are available since the composer.(json|lock) files (hashed and used as part of the cache key) are not always updated to reflect these changes (the benefit of using highest is you don't have to).

Background/problem

If a project goes a long time without updating their composer.(json|lock) files, it's possible that the cache restored could become really outdated This reduces the benefit of the cache since update will need to pull new versions every workflow run.

Proposal/solution

One way to fix this could be to include a date in the cache key when using highest. In WordPress/wordpress-develop, we chose to use the date for the previous Monday to ensure the cache was refreshed at least once a week.

[jrfnl]

May I suggest a slightly more flexible solution ?

You can currently already set a custom cache key, but that is cumbersome as the basic cache key used in the ramsey/composer-install action is pretty good to begin with.

What about having an option to set a custom-cache-extra parameter which would be added to the cache key currently in use ?

That way each project could decide for themselves what would be a reasonable additional parameter to use. WordPress can use the date of a week ago, but another project may want to set this to a month ago or even to something completely unrelated to dates, like the current branch name for long-running branches.

How does that sound ?

[desrosj]

What about having an option to set a custom-cache-extra parameter which would be added to the cache key currently in use ?

That sounds great!

[jrfnl]

FYI: I've got a PR for this ready, but CI needs to be fixed first as otherwise the build will fail no matter what, see #236 and #237.