Release version 1.2.0 #67
Merged
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
... of the bash `date` command in the earlier pulled cache busting.
All the repos in the Yoast organisation contain a `<arg name="cache" value="./.cache/phpcs.cache"/>` directive in the PHPCS ruleset. This directive makes running PHPCS faster by caching the run results in a file and only scanning changed files when running PHPCS again. However, when there is no cache available, running with the `cache` option enabled will make PHPCS _slower_ as the cache needs to be created and the file read/write actions slow PHPCS down. In GH Actions, we are not caching the PHPCS `cache` file, which means that there is cache file available and running with `cache` will be slower. By adding the `--no-cache` option, the `cache` directive in the ruleset is ignored, which should result in a slightly faster runtime for the CS workflow. Note: the alternative would be to _cache_ the cache file in GH Actions, but aside from the two very frequently changing repos, there's not much point doing that.
While early days for PHP 8.3, as this is a test related package, it needs to be ready early, so better to start running the lint and test workflows against PHP 8.3 already.
GH Actions: various tweaks
* YoastCS 2.3.0 has been released. Previous version used was `2.2.1`.
Ref: https://github.com/Yoast/yoastcs/releases/tag/2.3.0
* Version 1.0.0 of the Composer PHPCS plugin has been released. Previous version used was `0.7.2`.
Ref: https://github.com/Dealerdirect/phpcodesniffer-composer-installer/releases
Composer: update YoastCS and dependencies
This commit make the necessary changes to start recording and uploading code coverage data to Coveralls.
Includes:
* Updating the GH Actions `test` worflow to run the high/low PHP version builds with code coverage and upload the results.
* Updating the PHPUnit config to show an inline code coverage summary and improve the `filter` configuration.
* Adding a code coverage badge to the README.
Not included as already in place:
* Ignoring the potentially generated code coverage files in the `build/*` directory to prevent it being committed.
* Adding a script to the `composer.json` file to run code coverage.
Notes:
* Coverage will be recorded using `Xdebug` as the code coverage driver.
* The `php-coveralls/php-coveralls` package is used to convert the coverage information from a format as generated by PHPUnit to a format as can be consumed by Coveralls.
- As this package is only needed for the upload to Coveralls, the package has **not** been added it to the `composer.json` file, but will be (global) installed in the GH Actions workflow only.
- The `php-coveralls/php-coveralls` package is not 100% compatible with PHP 8.x (yet), so for uploading the coverage generated using PHP 8.x, we switch to PHP 7.4 for uploading the code coverage reports.
* Coveralls requires a token to identify the repo and prevent unauthorized uploads.
This token has been added to the repository secrets.
People with admin access to the GH repo automatically also have access to the admin settings in Coveralls.
If ever needed, the Coveralls token can be found (and regenerated) in the Coveralls admin for a repo.
After regeneration, the token as stored in the GH repo Settings -> Secrets and Variables -> Actions -> Repository secrets should be updated.
* As the workflow sends multiple code coverage reports to Coveralls, we need to tell it to process those reports in parallel and give each report a unique name.
That's what the `COVERALLS_PARALLEL` and COVERALLS_FLAG_NAME` settings are about.
* The `coveralls-finish` job will signal to Coveralls that all reports have been uploaded.
This basically gives the "okay" to Coveralls to report on the changes in code coverage via a comment on a GitHub PR as well as via a status check.
The pertinent Coveralls settings used for this repo are:
* "Only send aggregate Coverage updates to SCM": enabled
* "Leave comments": enabled
* "(Comment) Format": compact
* "Use Status API": enabled
* "Coverage threshold for failure": 95%
* "Coverage decrease threshold for failure": 1.0%
CI/QA: start recording code coverage
The Dependabot PRs can have a tendency to stay open for a long time, while for the GH Actions and Composer dependency related ones I keep an eye on all used action runner releases anyway. However, I don't "watch" all Yoast repos, so adding this configuration will ensure that I get notified about Dependabot PRs for this repo (and can merge it if appropriate or close it otherwise).
* PHPUnit Polyfills 1.0.5 has been released.
Ref: https://github.com/Yoast/PHPUnit-Polyfills/releases/tag/1.0.5
* YoastCS 2.3.1 has been released.
Ref: https://github.com/Yoast/yoastcs/releases/tag/2.3.1
... as WP Core has renamed the parameter as part of the efforts to become compatible with PHP 8.0. Ref: WordPress/wordpress-develop@51fae8b
... to be in line with the parameter name as used by WP Core for optimal compatibility with PHP 8.0. Ref: https://developer.wordpress.org/reference/functions/wp_parse_args/
Dependabot: add reviewer config
Composer: update dependencies
…-functions BrainMonkey/YoastTestCase: rename parameters for mocked functions
... and not on ordinary `push` events.
…and-merge GH Actions: only run tests for PRs and merges
Bumps [actions/checkout](https://github.com/actions/checkout) from 3 to 4. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v3...v4) --- updated-dependencies: - dependency-name: actions/checkout dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Follow up on PR 52. YoastCS 2.3.1 updated the default `testVersion` to PHP `7.2-`, while this package still supports PHP 5.6.
Composer/PHPCS: update for YoastCS 2.3.1
Well, mostly (scripts are not alphabetized, but still grouped by task). Note: this is done as a one-time only action. The normalize script will **_not_** be run in CI to enforce normalization. Style has been standardized to `--indent-style=tab --indent-size=1`. Ref: https://github.com/ergebnis/composer-normalize
These descriptions will be used when a list of the available scripts is requested on the command-line using the `composer list` or `composer run -l` commands. These descriptions also help document the different scripts for the maintainers of the `composer.json` file. Ref: https://getcomposer.org/doc/articles/scripts.md#custom-descriptions-
Composer: normalize the file and add script descriptions
* Alignment for readability.
.gitattributes: minor clean up
As of PHPUnit 10, data providers are (again) expected to be `static` methods. This updates the test suite to respect that.
Docs: various improvements
CS/QA: all test classes should be either abstract or final
Tests: make dataproviders `static`
PHPUnit 10.1.0 introduced two new assertions - `assertObjectHasProperty()` and `assertObjectNotHasProperty()` - to replace the `assertObjectHasAttribute() and `assertObjectNotHasAttribute()` methods, which were deprecated in PHPUnit 9.6.0 and removed in PHPUnit 10.0.0.
These two new assertions have since been backported to PHPUnit 9.x in PHPUnit 9.6.11 to allow for getting rid of the deprecation notice and making preparing for PHPUnit 10 more smooth.
The PHPUnit Polyfills have followed suit and the 1.1.0 release contains polyfills for the backported `assertObjectHasProperty()` and `assertObjectNotHasProperty()` methods.
For the WP Test Utils package, this caused an interesting conundrum:
* WP 6.4 - which enforces the use of PHPUnit Polyfills 1.1.0+ - will have the new polyfills available.
* WP 5.9 - 6.3 will have the new polyfills available _if the test dependencies are updated and PHPUnit Polyfills 1.1.0+ is used_.
* WP 5.2 - 5.9 versions, which include the backports, will **not** have the new polyfills available.
* WP 5.2 - 5.9 versions, which **don't** include the backports, will **not** have the new polyfills available.
* WP < 5.2 will **not** have the new polyfills available.
Previously the WP Test Utils would have two test cases available for integration tests:
* One for use with WP 5.9+ and with WP versions < 5.9 which included the backports.
* One for use with WP < 5.2 and with WP versions < 5.9 which do not include the backports.
To solve the conundrum, this commit:
* Updates the minimum version of the PHPUnit Polyfills to 1.1.0.
* Add the new polyfill to the test case which is used for WP < 5..2 and for WP versions < 5.9 which do not include the backports.
* Introduces a third test case for integration tests against WP 5.2 - 5.8 versions, which _do_ include the backports, but not the new polyfill.
While this third polyfill might technically not be needed, I've seen too many issues with traits colliding on older PHP versions to be willing to take that risk.
* Updates the autoloader to load the correct test case.
This should ensure that the new polyfill is available in all cases.
* Sorted the list - folders first, then files, alphabetic order.
.gitattributes: minor clean up
Backport support for the `AssertObjectProperty` polyfill
…heckout-4 GH Actions: Bump actions/checkout from 3 to 4
Includes adding note about Mockery 1.6.0 to the README.
Changelog for release 1.2.0
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.
No description provided.