[wp-trac] [WordPress Trac] #53841: CI: investigate switching to the Composer cache action

[WordPress Trac]

#53841: CI: investigate switching to the Composer cache action
------------------------------+---------------------
 Reporter:  jrf               |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  6.2
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+---------------------

Comment (by jrf):

 > I don't think that's a blocker as cache entries are likely evicted from
 time to time. But the methodology used under the hood in GHA is not clear.
 This is the only guidance specified:

 The biggest problem we have with the caches not being updated is PHPUnit.
 Everything else is basically set to a fixed version in the `composer.json`
 file and goes through managed updates (so will never be stale as the cache
 is discarded on an update of the `composer.json` file).

 PHPUnit and its dependencies, however, regularly release new versions and
 for all PHP versions using the PHPUnit 8.x and 9.x range (PHP 7.2 - 8.2),
 this means the cache will quickly go stale if we don't use a date based
 refresh.

 AFAIK, caches which aren't used are evicted after a while, but caches
 which ''are'' used are not and as WP is a very active codebase, the caches
 created for the Composer downloads are used dozens of times a day, so will
 never be regarded as ''unused'', even though they may have gone stale
 (which is why we added the "one week" bit to the cache-key in
 [https://github.com/WordPress/wordpress-
 develop/pull/1511#discussion_r674317556 a previous iteration] to ensure
 the cache would get refreshed).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/53841#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform