GH Actions: bust the cache semi-regularly

[jrfnl]

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

[anomiex]

I don't think ramsey/composer-install is doing quite the right thing here. Specifically, looking at https://github.com/antecedent/patchwork/actions/runs/3396613076/jobs/5647869135#step:4:57, I see

Run actions/cache@v3
  with:
    path: /home/runner/.cache/composer
    key: Linux-php-8.0.25-composer-locked-2022-11-01-cfe682d5acef5514e670ead3388d112fe87eb1b9ff5a562705d91f4a88c72c46
    restore-keys: Linux-php-8.0.25-composer-locked-2022-11-01-

Based on that, everything will be re-downloaded daily even if not needed. What I'd want to see is something like this instead:

    restore-keys: |
      Linux-php-8.0.25-composer-locked-2022-11-01-
      Linux-php-8.0.25-composer-locked-

so it'll try to re-use what it can from the most recent key starting with "Linux-php-8.0.25-composer-locked-" (e.g. yesterday's) if today's key hasn't been created yet.

[jrfnl]

I don't think ramsey/composer-install is doing quite the right thing here. Specifically, looking at https://github.com/antecedent/patchwork/actions/runs/3396613076/jobs/5647869135#step:4:57, I see

Run actions/cache@v3
  with:
    path: /home/runner/.cache/composer
    key: Linux-php-8.0.25-composer-locked-2022-11-01-cfe682d5acef5514e670ead3388d112fe87eb1b9ff5a562705d91f4a88c72c46
    restore-keys: Linux-php-8.0.25-composer-locked-2022-11-01-

Based on that, everything will be re-downloaded daily even if not needed. What I'd want to see is something like this instead:

The date I'm settting is the first of the month, so everything will only be re-downloaded once a month (if nothing else changed), not daily.

    restore-keys: |
      Linux-php-8.0.25-composer-locked-2022-11-01-
      Linux-php-8.0.25-composer-locked-

so it'll try to re-use what it can from the most recent key starting with "Linux-php-8.0.25-composer-locked-" (e.g. yesterday's) if today's key hasn't been created yet.

As it's set to once a month, there's no need.

You may find this discussion about this interesting: composer/composer#11191

[jrfnl]

The date I'm settting is the first of the month, so everything will only be re-downloaded once a month (if nothing else changed), not daily.

At least that's the idea, if I'm not doing that correctly, do let me know. My bash is abysmal.

[anomiex]

Oh, yeah, I didn't look closely enough at the date command there. Redownloading once a month seems less of a problem.

P.S. You could do date -u "+%Y-%m-01" instead of using -d there. Or even date -u "+%Y-%m" to leave off the day part entirely.

[jrfnl]

P.S. You could do date -u "+%Y-%m-01" instead of using -d there. Or even date -u "+%Y-%m" to leave off the day part entirely.

Happy to update the PR to whichever you prefer. The current snippet is the result of Google-fu and trial and error and I was just glad I got it working in the first place 😀

[anomiex]

I'll leave it up to you whether you take the suggestion or not. 🙂 Personally I think it's better to do the simpler thing, but what you have should work too.

[jrfnl]

I'll leave it up to you whether you take the suggestion or not. 🙂 Personally I think it's better to do the simpler thing, but what you have should work too.

Done (and I agree, simpler is better, I just didn't know how before this)