[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:                    |     Focuses:
------------------------------+---------------------
Changes (by desrosj):

 * keywords:  has-patch =>
 * milestone:  Awaiting Review => 6.2


Comment:

 I started looking into this related to #56820.

 Some findings and notes:

 The action uses a `CACHE_RESTORE_KEY` environment variable. At first, I
 was concerned this would potentially affect other caching steps within the
 same workflow, but this variable is not used in `actions/cache`, only
 within `ramsey/install-composer`, so it's a non issue.

 The cache key used by the action is comprised of the following:
 - Runner machine operating system
 - PHP version (down to the bug fix number, ie. 7.4.32)
 - The `dependency-versions` value (`highest` in our case since we want to
 emulate `composer update`)
 - Any additional `composer-options` supplied (empty in our case, except
 when using PHP 8.2)
 - The hash of any `composer.json` or `composer.lock` files found.
 - The working directory

 OR, if a custom cache key is provided, then the one provided is used
 without any of the previous items.

 With these findings, I think it's safe and preferred to use this action to
 simplify our workflows. The only caveat is that the same issue as
 discussed in [https://github.com/WordPress/wordpress-
 develop/pull/1511#discussion_r674130418 this PR] related to a cache
 potentially losing it's effectiveness over time exists.

 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:

 > A repository can have up to 10GB of caches. Once the 10GB limit is
 reached, older caches will be evicted based on when the cache was last
 accessed. Caches that are not accessed within the last week will also be
 evicted.

 In my testing of my PR, I've confirmed that cache hits for the keys
 specified in the first attempt occur on successive workflow runs be
 rerunning completed workflows.

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