GH Actions: harden the workflow against PHPCS ruleset errors
If there is a ruleset error, the cs2pr action doesn't receive an xml report and exits with a 0 error code, even though the PHPCS run failed (though not on CS errors, but on a ruleset error).
This changes the GH Actions workflow to allow for that situation and still fail the build in that case.
GH Actions: bust the cache semi-regularly
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.
Context
Summary
This PR can be summarized in the following changelog entry:
Relevant technical choices:
GH Actions: fix use of deprecated set-output
GitHub has deprecated the use of
set-output(andset-state) in favour of new environment files.This commit updates workflows to use the new methodology.
Refs:
GH Actions: harden the workflow against PHPCS ruleset errors
If there is a ruleset error, the
cs2praction doesn't receive anxmlreport and exits with a0error code, even though the PHPCS run failed (though not on CS errors, but on a ruleset error).This changes the GH Actions workflow to allow for that situation and still fail the build in that case.
GH Actions: bust the cache semi-regularly
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:
This means that aside from other factors, the cache will always be busted when changes are made to the (committed)
composer.jsonor thecomposer.lockfile (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.lockfile - 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-suffixoption 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-suffixoption for all relevant workflows in this repo.Refs:
GH Actions: don't allow linting issues on PHP 8.2
Test instructions
Test instructions for the acceptance test before the PR gets merged
This PR can be acceptance tested by following these steps: