Skip to content

Release version 1.1.0 #44

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

Merged
merged 32 commits into from
Nov 16, 2022
Merged

Release version 1.1.0 #44

merged 32 commits into from
Nov 16, 2022

Conversation

jrfnl
Copy link
Collaborator

@jrfnl jrfnl commented Nov 16, 2022

No description provided.

jrfnl and others added 30 commits September 27, 2021 12:06
The build against PHP 8.1 has been passing for a while and it should stay that way.
... but allow for the builds to fail.
GH Actions: adjust matrix - add PHP 8.2, PHP 8.1 not allowed to fail
* BrainMonkey has released version 2.6.1.
    Ref: https://github.com/Brain-WP/BrainMonkey/releases/tag/2.6.1
* PHPUnit Polyfills has released version 1.0.3
    Ref: https://github.com/Yoast/PHPUnit-Polyfills/releases
…straints

Composer: update version constraints
The `dealerdirect/phpcodesniffer-composer-installer` Composer plugin is used to register external PHPCS standards with PHPCS.

As of Composer 2.2.0, Composer plugins need to be explicitly allowed to run. This adds the necessary configuration for that.

Refs:
* https://blog.packagist.com/composer-2-2/#more-secure-plugin-execution
The action used to install Composer packages and handle the caching has released a new major (and some follow-up patch releases), which means, the action reference needs to be updated to benefit from it.

Refs:
* https://github.com/ramsey/composer-install/releases/tag/2.0.0
* https://github.com/ramsey/composer-install/releases/tag/2.0.1
* https://github.com/ramsey/composer-install/releases/tag/2.0.2
…ction

GH Actions: version update for `ramsey/composer-install`
* Update the YoastCS dependency.
    Ref: https://github.com/Yoast/yoastcs/releases/tag/2.2.1
* Adjust the PHP linting scripts to include deprecations (in as far as those are available during linting).
A number of predefined actions have had major release, which warrant an update the workflow(s).

These updates don't actually contain any changed functionality, they are mostly just a change of the Node version used by the action itself (from Node 14 to Node 16).

Refs:
* https://github.com/actions/checkout/releases
…tions

GH Actions: version update for various predefined actions
This automatically enables Dependabot to:
* Submit pull requests for security updates and version updates for Composer dependencies.
* Submit pull requests for security updates and version updates for GH Action runner dependencies.

For Composer dependencies, a preference is given to only increase the version restrictions when needed.
This is a deliberate choice as this package is a library, not an application and there is no committed `lock` file.

The configuration has been set up to:
* Run once a week.
* Submit a maximum of 5 pull requests at a time.
    If additional pull requests are needed, these will subsequently be submitted the next time Dependabot runs after one or more of the open pull requests have been merged.
* The commit messages for PRs submitted by Dependabot will be prefixed according the unofficial conventions used in this repo up to now.
* The PRs will automatically be labelled with an appropriate label as already in use in this repo.

Refs:
* https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file
* https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#versioning-strategy
Since Composer 2.4.0, Composer will prompt users if they are sure they want to install something as `require` instead of `require-dev` if the package contains certain "dev" related keyword, like `testing`.

This adds the keyword to this package to help users add the package in the most appropriate place.

Refs:
* https://getcomposer.org/doc/04-schema.md#keywords
* composer/composer#10960
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.
Includes:
* Removing the `composer install` toggle for PHP 8.2.
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 we are 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
GH Actions: bust the cache semi-regularly
... which is no longer needed as the upstream PR (squizlabs/PHP_CodeSniffer 3184) has been merged.
…` functions

These methods allow for on the fly creation of test doubles which allow for dynamic properties, which allows for bypassing the PHP 8.2 dynamic property deprecation notice when the _real_ class has these properties declared, but a mock is used in the tests.

See the README docs + mockery/mockery 1197 for additional information.

Includes:
* Tests to cover the new functionality.
* Documentation in the README file.
BrainMonkey/TestCase: add new `makeDouble[s]ForUnavailableClass[es]()` functions
Includes updating the reference in the Readme.
Composer: update minimum support version of PHPUnit Polyfills
jrfnl and others added 2 commits November 17, 2022 00:17
Includes two minor tweaks to the readme.
@jrfnl jrfnl added this to the 1.1.0 milestone Nov 16, 2022
@jrfnl jrfnl merged commit f319edb into main Nov 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant