PHP 8.4 removes the IMAP extension (moved to PECL).
With this in mind, I've reviewed how the tests are being run versus the extension requirements and recommendations.
As things are, the tests are currently run in the "ideal" environment, i.e. with all required and optional extensions available.
However, the codebase also contains fall-backs for when certain extensions are **_not_** available and for at least some of those fallbacks, there are dedicated tests available, but in an ideal environment those tests will not run and the fall-backs are not tested, which is the case with the current CI setup.
To improve this situation, I'm proposing to keep running the tests against all PHP versions with the "ideal" extension set, but to also have additional test runs with a far more limited set of PHP extensions.
To determine which extensions should be in each set, I've looked at the following:
* `@requires` tags found in the test suite and the conditions for calls to `markTestSkipped()`.
This brought to light that the `openssl` extension was currently not listed in the "ideal" extension set. This has now been fixed.
* The required extensions of PHPUnit - `dom, json, libxml, mbstring, tokenizer, xml, xmlwriter`.
* The required extensions of PHPMailer itself - `ctype, filter, hash`.
* Not strictly required, but more for convenience/workflow speed: `curl` for Composer.
* And `xdebug` will still be enabled/disabled based on the `coverage` setting.
Note: while some tests would benefit from being run _without_ the `mbstring` extension, that's unfortunately not an option as `mbstring` is a requirement of PHPUnit 🤷
Also note, the tests with the "minimal" extension setup needs to run `composer install` with an `--ignore-platform-req` flag to prevent running into the following issue:
```
Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems.
```
As this extension "requirement" is for a dependency which is not used in the test run, the extension requirement can be safely ignored.
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
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.
Most predefined action runners offer a long-running branch or a tag which gets moved every release to allow staying on the "latest" version of a certain major of their action, without having to update the workflow scripts on every release of the action runner.
This works well for action runners which follow semver.
I've reviewed the existing workflows and tweaked the versions used whenever possible to make optimal use of this.
* For the `ossf/scorecard-action` action runner, I have not been able to find a workable tag/branch to fix this on.
Note: I have remove the "# v1.1.1" comment though as it doesn't get updated by Dependabot and was sorely out of date (you are currently on version `2.0.4`).
With the changes in this PR, Dependabot should become less noisy and will only send in PRs to update the action runner versions when a new major release has been tagged. (save for the one exceptions mentioned above)
I would recommend watching the following repos for new releases:
* https://github.com/actions/checkout
* https://github.com/actions/upload-artifact
* https://github.com/shivammathur/setup-php
* https://github.com/ramsey/composer-install
* https://github.com/nick-fields/retry
* https://github.com/codecov/codecov-action
* https://github.com/JamesIves/github-pages-deploy-action
* https://github.com/ossf/scorecard-action
* https://github.com/github/codeql-action
This will ensure you will get an email with the changelogs for those action runners on all releases, so you can still monitor for changes in the action runners you need to be aware of.
Marcus Bointon
jrfnl
dependabot[bot]
Alex