Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* PHPUnit: Rename the config file > If `phpunit.xml` or `phpunit.xml.dist` (in that order) exist in the current working directory and `--configuration` is not used, the configuration will be automatically read from that file. From: https://phpunit.de/manual/6.5/en/organizing-tests.html#organizing-tests.xml-configuration In other words, using a `phpunit.xml.dist` file allows individual developers to overrule it with their own version if so desired. This in turn, allows them to use the `<php ...>` directives to set environment variables, such as `WP_TESTS_DIR`. It also means that the configuration file does not need to be passed to PHPUnit in the Travis scripts. Includes adding `phpunit.xml` to the `.gitignore` file to allow devs to use that file for their own custom configuration. * PHPUnit config: minor tweaks * Add the XML header. * Add the schema. * Add a name for the testsuite. (Required attribute as of PHPUnit 7) * Travis: clean up the existing config * Remove duplicate `language` directive. * Remove sudo. `sudo` is no longer a supported directive in Travis. Ref: https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-migration * Remove duplicate/inconsistent `WP_DEVELOP_DIR` setting. `WP_DEVELOP_DIR` is set to something else only two lines before and not used by the test bootstrap, so this shouldn't be needed. * List the job steps in the order in which they will be run. Ref: https://docs.travis-ci.com/user/job-lifecycle/ * Use consistent 2-space indentation for YAML. * Add some blank lines to improve readability. * Travis: tweak the PHP version matrix Simplify for versions which don't need extra settings and only list those which do in the matrix. * Simplify the list of PHP versions for those versions which don't need extra settings. * Drop testing against PHP < 5.6. * Drop special builds with `env: WP_TRAVISCI=travis:js` and `env: WP_TRAVIS_OBJECT_CACHE=true`. Looks like those variables come from the [Core script](https://github.com/WordPress/wordpress-develop/blob/master/.travis.yml), but weren't being used here. - The `js` testing isn't needed anyway as this repo doesn't contain JS. - The object cache testing could be considered, but would need some extra script bits. As it is, the variable was unused, so no needed. * Replace `nightly` with `7.4snapshot` Nightly has become PHP 8.0 since PHP 7.4 has been branched, so to continue to also test against PHP 7.4, it needs to be added separately. Refs: * https://twitter.com/nikita_ppv/status/1089839541828112384 * https://twitter.com/nikita_ppv/status/1094897743594770433 As PHP 8.x - current `nightly` - is not expected to be released until December 2020, with PHP 7.4 expected in December 2019, I've elected to replace the build against `nightly` with a build against `7.4snapshot`. * Don't require PHPUnit 7 for PHP 7.1 The Travis image for PHP 7.1 already comes with a supported PHPUnit version, so there is no need to replace it. Also see: https://phpunit.de/supported-versions.html For that matter, there is no need for the `PHPUNIT_VERSION` environment variable either as a simple compare can take care of that just as easily. * Travis: disable xdebug Xdebug is only _needed_ when PHPUnit code coverage is tested via Travis. As that is not the case, disabling Xdebug should speed up the build a little. * Travis: cache Composer downloads This should speed up the build a little again. * Travis: be explicit about what is being tested Without a `script` section, you are relying on the Travis default for a PHP environment being, the running of PHPUnit. This may change, however, without notice. So it is always better to be explicit about what tests to run from Travis. * Travis: lint all PHP files against all supported PHP versions * Add a `composer.json` file ... making the exiting (development) dependencies explicit and easier to find for anyone looking for them. Includes validating the `composer.json` file on the Travis builds against the lowest and highest stable PHP versions supported by Composer as well as the plugin. Includes adding the `composer.lock` file to the `.gitignore` list. Until there are non-dev dependencies which need to be locked to specific versions, there is no need to commit the `composer.lock` file. * Add a `.gitattributes` file ... to keep the zip file which can be downloaded from GitHub clean of development specific files. * CS: remove old-style whitelist comment I have not replaced this with a new-style comment (yet) as it looks like some valid observations are made by WPCS, so I would recommend checking this thoroughly. * PHPCS: set it up & add to Travis * Add the various PHPCS requirements to the `composer.json` `require-dev` section. - WPCS for generic code style and best practices. - PHPCompatibilityWP for checking code for cross-version PHP compatibility. - The DealerDirect Composer plugin to automatically install external standards for PHPCS. - Note: PHPCS itself is not a direct dependency, this is a dependency of our dependants, so we don't need to `require` it. * Set up a fully documented PHPCS ruleset using the `WordPress` and `PHPCompatibilityWP` rulesets, with the minimum PHP version to test cross-version compatibility against set to `5.6`. * Add a Travis task to test the code base against the PHPCS ruleset. Includes adding optional developer specific local configuration files to `.gitignore`. * add missing docblock for _manually_load_plugin * test-meta-revisions.php: Improve docblocks * function names should not be prefixed with an underscore to indicate visibility * add missing doc block parameters * ignore the naming suggestion - changing the naming would result in a breaking change & named for core * ignore security data handling reccomendation for these low level handlers * add the mysql service * correct phpcs version usage * try: reverse logic check * CS: Minor documentation fixes * Travis: fix issue with Travis images being unstable The PHPUnit version shipped with Travis natively is currently unusable as someone who wasn't paying attention decided to ship them with incompatible PHPUnit versions. Always using Composer fixes this. * explain why we are using @phpcs:disable WordPress.Security Co-authored-by: Adam Silverstein <[email protected]>
- Loading branch information