-
-
Notifications
You must be signed in to change notification settings - Fork 483
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add PHPStan to QA checks #2355
Merged
Merged
Add PHPStan to QA checks #2355
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jrfnl
force-pushed
the
feature/ghactions-add-phpstan
branch
from
August 17, 2023 17:49
c205f0d
to
e3efdef
Compare
GaryJones
approved these changes
Aug 17, 2023
dingo-d
approved these changes
Aug 18, 2023
jrfnl
force-pushed
the
feature/ghactions-add-phpstan
branch
from
August 18, 2023 11:33
e3efdef
to
ada7b68
Compare
Rebased now the prerequisite PRs have been merged. Build should pass now ;-) |
PHPStan is a good addition to our QA toolkit and with improvements PHPStan has made over the years is now a viable tool for us to use (previously it would give way too many false positives). This commit: * Adds a separate job to the `basic-qa` workflow in GH Actions. Notes: - I've chosen **not** to add PHPStan to the Compose dependencies for two reasons: 1. It doesn't allow for installation on PHP < 7.2, which would break/block the `composer install` for our test runs. 2. It would add dependencies which could conflict/cause problems for our test runs due to those defining token constants too. - We could potentially use [Phive](https://phar.io/) to still have a setup which can be used locally, but just running locally from a PHPStan PHAR file should work just fine. - For CI, PHPStan will be installed as a PHAR file by `setup-php` now. This does carry a risk _if_ PHPStan would make breaking changes or if a new release adds rules for the levels being scanned as, in that case, builds could unexpectedly start failing. We could fix the version `setup-php` action installs to the current release `1.10.29`, but that adds an additional maintenance burden of having to keep updating the version as PHPStan releases pretty often. So, for now, I've elected to run the risk of random failures. If and when those start happening, we can re-evaluate. - The PHP version for the CI run is set to PHP 7.4 to prevent PHPStan throwing some errors/notices related to the outdated PHPUnit version being used. * Adds a configuration file for PHPStan. Notes: - PHPStan needs to know about our dependencies (PHPCS et al), so I'm (re-)using the bootstrap file we have for our tests to load the PHPCS autoloader and register the standard with the PHPCS autoloader as we can't add an `autoload` directive to our `composer.json` file as it would cause problems with the PHPCS autoloader. - PHPStan flags type checks on properties with a documented type, while - especially for the `public` properties - we cannot always be sure the properties set will be of the correct type. For that reason, I've set `treatPhpDocTypesAsCertain` to `false` (which silences those notices). - I've very selectively silenced a number of errors. - Level 0: this is about the use of `return $this->method()` when the return type of the `process_token()` method is `int|void`. For consistency, I believe keeping those returns makes for less confusing code (they will still be `void`). - Level 4: I believe those are false positives. - Level 5: This error is not relevant as we don't use `strict_types`. * Adds the configuration file to `.gitattributes` and the typical overload file for the configuration file to `.gitignore`. Refs: * https://phpstan.org/ * https://phpstan.org/config-reference
jrfnl
force-pushed
the
feature/ghactions-add-phpstan
branch
from
August 18, 2023 11:36
ada7b68
to
d6e47ab
Compare
Hmm.. build did not pass, but not due to issues found, but PHPStan not handling the config correctly. I've made some tweaks to the config now, let's see if it works this time. (Locally it was already working) |
Looks like it's passing now. I'll merge it 🙂 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PHPStan is a good addition to our QA toolkit and with improvements PHPStan has made over the years is now a viable tool for us to use (previously it would give way too many false positives).
This commit:
basic-qa
workflow in GH Actions.Notes:
composer install
for our test runs.setup-php
now.This does carry a risk if PHPStan would make breaking changes or if a new release adds rules for the levels being scanned as, in that case, builds could unexpectedly start failing.
We could fix the version
setup-php
action installs to the current release1.10.29
, but that adds an additional maintenance burden of having to keep updating the version as PHPStan releases pretty often.So, for now, I've elected to run the risk of random failures. If and when those start happening, we can re-evaluate.
Notes:
autoload
directive to ourcomposer.json
file as it would cause problems with the PHPCS autoloader.public
properties - we cannot always be sure the properties set will be of the correct type. For that reason, I've settreatPhpDocTypesAsCertain
tofalse
(which silences those notices).return $this->method()
when the return type of theprocess_token()
method isint|void
. For consistency, I believe keeping those returns makes for less confusing code (they will still bevoid
).strict_types
..gitattributes
and the typical overload file for the configuration file to.gitignore
.Refs: