* Improve readability of reports by using headers.
* Improve readability of the versions list by using a table.
* Explicitly say that screenshots of code are not acceptable as a code sample.
* Added an "Install type" entry to the versions list
* Added an extra checklist for bug reporters in an attempt to reduce the number of issues which should never have been opened in the first place.
This is a quite straight-forward workflow to just remove some labels which should only be on open issues/open PRs and which should be removed once an issue or PR has been closed/merged.
Just attempting to reduce yet some more manual labour.
This pull requests template has been set up to attempt to gather all information needed by the maintainers to evaluate the PR.
It also is intended to act as a reminder for contributors to make sure the PR is complete and ready for review.
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
The PHP native `php_strip_whitespace()` function used in the PHAR build script is PHP version sensitive.
The function strips comments and whitespace out of the code, but in PHP 7.4, attributes are seen as comments due to the `#[]` syntax, which means that if the PHAR files were being generated on PHP 7.4, the PHP 8.1 #[ReturnTypeWillChange]` attributes as put in via PR 3400 would be stripped out.
In other words: for the PHAR files to be cross-version compatible, they *MUST* be generated on PHP 8.0 or higher.
This fixes this for the CI part of things.
Ref: https://www.php.net/manual/en/function.php-strip-whitespace.php
As things were in the CI script, the `phpcs` and `phpcbf` Phars would be build against each supported PHP version and the tests run with the `phpcs` Phar would use the Phar as build on the same PHP version as the test was being run on.
This test was not representative of the reality as with each release, only one `phpcs` and one `phpcbf` phar is released.
The changes in this commit:
* Split the building of the Phar off from the main test script.
* This new `build` job:
- Tests building the Phar against all supported PHP versions as an early detection system for problems in the Phar extension/Phar building script.
- Uploads both phars as build against PHP 7.4.
The uploaded Phars match the Phars as would be included on a release as they are build against the same PHP version as used for releases.
These Phars will now also be available for PRs and merges to `master` to allow for easier testing of change proposals by issue reporters who may not have a git clone of the repo.
The uploaded Phars will be available for 28 days (default 90).
- Does a cursory test with both the `phpcs.phar` as well as the `phpcbf.phar` to test that the build phar files are functional.
* In the `test` job, which now depends on the `build` job, the Phar will now no longer be build, but the Phar as uploaded in the `build` job - i.e. the Phar build against the same PHP version as used when releasing Phars - is downloaded and used to run the Phar test.
The uploaded Phar files can be found on the "Summary" page of the `test` workflow after the build has finished for each build run.
PHP 8.1 has been released, so build against it should no longer be allowed to fail.
Also adding PHP 8.2 as the new "nightly" build (which is allowed to fail).
Turns out the default setting for `error_reporting` used by the SetupPHP action is `error_reporting=E_ALL & ~E_DEPRECATED & ~E_STRICT` and `display_errors` is set to `Off`.
For the purposes of CI, I'd recommend running with `E_ALL` and `display_errors=On` to ensure **all** PHP notices are shown.
Includes minor fix to the documentation of that part of the script.
Triggering a workflow for a branch manually is not supported by default in GH Actions, but has to be explicitly allowed.
This is useful if, for instance, an external action script or composer dependency has broken.
Once a fix is available, failing builds for open PRs can be retriggered manually instead of having to be re-pushed to retrigger the workflow.
Ref: https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/
The cs2pr tool will allow to display the results from an action run in checkstyle format in-line in the PR code view, which should improve usability of the workflow results.
As the CS run is run in every test run in the matrix, passing the results on to CS2PR would result in violations being displayed multiple times, so using conditions to only pass the CS violations on to the PR for one of the runs.
Ref: https://github.com/staabm/annotate-pull-request-from-checkstyle
There is no need to remove the config file and have all settings on the command-line as PHPUnit offers a `--no-configuration` option to ignore the config file.
Enabling that simplifies the action steps a little and isolates the customization for PHP 8.1 to PHP 8.1.
Running PHPUnit 7 under PHP 8.1 causes an error when reading config files due to the assignment of by reference. By removing the config file and specifying the settings on the command line, this bit of code is skipped. The additional config options in the config file have also been removed as they didn't seem to be necessary, but this needs to be validated in the pipeline first.
This commit:
* Adds a GH Actions workflow for the CI checks which were previously run on Travis as the default test script.
Includes only running the base tests for the builds using custom ini setting.
* Removes the, now redundant, `.travis.yml` configuration.
* Remove the custom PHP ini configurations.
Setting these is now handled in the script itself.
* Updates the `.gitattributes` file.
* Updates the "Build Status" badge in the Readme to use the results from the GH `Test` Actions runs.
The PEAR native package validation script used to be run on every PHP build, but the results should be no different on any particular PHP version.
To that end, move the running of the script from the "test" cycles, to the one-time only run PEAR specific job.
This commit:
* Adds a GH Actions workflow for the build which validated the XML file against schema and checked their code style consistency, as well as validate the PEAR package file, as was previously run on Travis.
* Removes that part of the `.travis.yml` configuration.
Notes:
Builds will run on all pushes and on pull requests, with the exception of those just modifying files which are irrelevant to this workflow.
This commit:
* Adds a GH Actions workflow for the PHPStan check which was previously run on Travis.
* Removes that part of the `.travis.yml` configuration.
Notes:
Builds will run on all pushes and on pull requests, with the exception of those just modifying files which are irrelevant to this workflow.
