Conversation
... as the old URLs are no longer valid.
* Builds against PHP 8.3 are no longer allowed to fail. * Update PHP version on which code coverage is run (high should now be 8.3). * Add _allowed to fail_ build against PHP 8.4.
GH Actions: update a few links in inline comments
…ased GH Actions/test: PHP 8.3 has been released
This is a new feature available since Composer 2.6.0, which was released a few weeks ago. When this key is added, it will also show a link to the security policy on Packagist. Refs: * https://github.com/composer/composer/releases/tag/2.6.0 * composer/composer#11271 * composer/packagist#1353
Simplify the code coverage workflow by removing the dependency on the `php-coveralls/php-coveralls` package and switching to the `coverallsapp/github-action` action runner, which, as of the release of the [0.6.5 version of the Coverage Reporter](https://github.com/coverallsapp/coverage-reporter/releases/tag/v0.6.5) now natively supports the Clover format. The `COVERALLS_TOKEN` can now be removed from Settings -> Secrets.
Composer.json: add link to security policy
…eporter GH Actions: switch to Coveralls action runner to upload reports
CS: minor tweaks to comply with WordPressCS 3.0
YoastCS 3.0.0 has been released and is based on WordPressCS 3.0.0.
This commit makes the necessary updates for that:
* Composer: update the requirements.
* PHPCS ruleset:
- Exclude new (and more) WP specific rules which don't apply to this package.
- Exclude code modernization sniffs which can't be applied to this package yet.
- Enforce strict PSR-4 for both src and tests.
- Update a few property names for new names in WordPressCS 3.0.
- Remove a few exclusions which are no longer needed.
- Add a few selective exclusions for specific situations.
* GHA CS workflow: run the CS check on the latest PHP version.
No need to run on PHP 7.4 any more as the deprecations previously encountered were all fixed.
While YoastCS 3.0.0 contains lots of goodies, it also has a downside: a minimum PHP requirement of PHP 7.2, which conflicts with the minimum supported PHP version of this package.
This causes two issues:
1. A plain `composer install` will no longer work on PHP < 7.2.
This means the YoastCS package will need to be removed for the CI test workfows.
2. As the (Parallel) linting packages are "inherited" from YoastCS, removing YoastCS would break the linting command in CI, so we need to `require-dev` the Parallel Lint packages in PHPUnit Polyfills itself to allow the workflow to continue to work.
With those two work-arounds in place, everything should work again.
Refs:
* https://github.com/Yoast/yoastcs/releases/tag/3.0.0
* https://github.com/WordPress/WordPress-Coding-Standards/releases/tag/3.0.0
…-3.0.0 Composer/PHPCS: update to YoastCS 3.0.0
Bumps [ramsey/composer-install](https://github.com/ramsey/composer-install) from 2 to 3. - [Release notes](https://github.com/ramsey/composer-install/releases) - [Commits](ramsey/composer-install@v2...v3) --- updated-dependencies: - dependency-name: ramsey/composer-install dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
…mposer-install-3 GH Actions: Bump ramsey/composer-install from 2 to 3
Nearly all dev dependencies have had new releases. This commit updates the plugin to use the new versions. For linting, the upgrade will get us preliminary PHP 8.4 support. For CS, the upgrades will get us improved syntax support for PHP 8.3, improved information related to the WP 6.5 release, more documentation and a range of bug fixes.
This upgrade will get us continued support for running the tests via a PHAR file after the latest PHPUnit releases, as well as preliminary PHP 8.4 support.
…ncies Composer: update dependencies
Set the minimum supported BrainMonkey version to the release which adds compatibility with PHP 8.4. Refs: * https://github.com/Brain-WP/BrainMonkey/releases/tag/2.6.2
Composer: update BrainMonkey to `^2.6.2`
* Builds against PHP 8.4 are no longer allowed to fail. * Update PHP version on which code coverage is run (high should now be 8.4). * Add _allowed to fail_ build against PHP 8.5.
GH Actions/test: anticipate PHP 8.4 release
Composer 1.10.0 introduced a `lock` config option, which, when set to `false` will prevent a `composer.lock` file from being created and will ignore it when one exists. This is a useful option for libraries such as this where the `lock` file has no meaning. It also makes life easier for contributors as they don't have to remember that for this repo they should use `composer update` instead of `composer install`. Both will now work the same. Refs: https://getcomposer.org/doc/06-config.md#lock
Composer: prevent a lock file from being created
CS: minor tweaks
This job checks the GH Actions workflows against syntax errors and other problems.
This commit adds a new workflow which runs on pushes (merges) to any of the long-running branches and whenever the contents of a pull requests changes. It will check whether any open PRs are in a "conflict state" (after the push) and if so, will add a "merge conflict" label and leave a comment on the PR asking the OP to solve the conflict. The workflow will automatically remove the label again when the conflict is resolved. This workflow uses a reusable action stored in the `.github` repository which takes care of the default settings, though a number of settings can still be overruled for an individual repo. For now, it has not been deemed necessary to overrule these though.
GH Actions: add actionlint job
GH Actions: add merge-conflict check
Hmm... this is an awkward one and may need fixing in PHPCS 4.0, but in the mean time, let's fix it here. The base `Yoast` ruleset includes select sniffs from the `WordPressVIPMinimum` ruleset. These sniff do not apply to the WP TestUtils package. Now, when an `<exclude name="..."/>` rule references a ruleset name to _exclude_ those sniffs, that whole standard is read and included, after which the individual sniffs from the ruleset are excluded again. This also means that if such a ruleset _also_ includes sniffs from other standards and/or customizations (changes in severity/excludes/messaging/properties etc) to sniffs from other standards, those sniffs from other standards will still be included and the customizations still be applied. This will often silently lead to unexpected side-effects, like in the case of the exclusion of the `WordPressVIPMinimum` ruleset, which meant that certain rules we _do_ want applied, like "no superfluous whitespace at the end of a line", got unintentionally excluded. Fixed now by excluding the individual sniffs from the `WordPressVIPMinimum` standard which were included by the `Yoast` ruleset, instead of excluding the whole `WordPressVIPMinimum` standard.
…heckout-6 GH Actions: Bump actions/checkout from 5 to 6
The `poser.pugx.org` site isn't working half the time and broken badges do not look good.
README: fix a few badges
…name GH Actions/test: ensure all jobs have a name
Recently there has been more and more focus on securing GH Actions workflows - in part due to some incidents.
The problem with "unpinned" action runners is as follows:
* Tags are mutable, which means that a tag could point to a safe commit today, but to a malicious commit tomorrow.
Note that GitHub is currently beta-testing a new "immutable releases" feature (= tags and release artifacts can not be changed anymore once the release is published), but whether that has much effect depends on the ecosystem of the packages using the feature.
Aside from that, it will likely take years before all projects adopt _immutable releases_.
* Action runners often don't even point to a tag, but to a branch, making the used action runner a moving target.
_Note: this type of "floating major" for action runners used to be promoted as good practice when the ecosystem was "young". Insights have since changed._
While it is convenient to use "floating majors" of action runners, as this means you only need to update the workflows on a new major release of the action runner, the price is higher risk of malicious code being executed in workflows.
Dependabot, by now, can automatically submit PRs to update pinned action runners too, as long as the commit-hash pinned runner is followed by a comment listing the released version the commit is pointing to.
So, what with Dependabot being capable of updating workflows with pinned action runners, I believe it is time to update the workflows to the _current_ best practice of using commit-hash pinned action runners.
The downside of this change is that there will be more frequent Dependabot PRs.
If this would become a burden/irritating, the following mitigations can be implemented:
1. Updating the Dependabot config to group updates instead of sending individual PRs per action runner.
2. A workflow to automatically merge Dependabot PRs as long as CI passes.
Ref: https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions
👉 Important: this is for **version** updates only, not for security updates, which are handled separately and don't depend on this configuration.
---
This commit makes the following changes to the Dependabot config to reduce the number of Dependabot PRs, while still keeping the workflows up to date with a reasonable frequency:
* It introduces a "group".
By default Dependabot raises individual PRs for each update. Now, it will group updates to new minor or patch release for all action runners into a single PR.
Updates to new major releases of action runners will still be raised as individual PRs.
* It changes the schedule from `weekly` (on Monday, at whatever time this repo reaches the front of the HUGE queue which it will always have on Monday) to twice a month at a specific time which is not midnight.
Aside from making the PRs less frequent, it should also make the arrival time more predictable as the queue created at 22:10 (in whatever timezone Dependabot runs in) will be next to nothing as it would need more repos to use this exact configuration.
Refs:
* https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/optimizing-pr-creation-version-updates
* https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference
GH Actions: "pin" all action runners
> By default, using `actions/checkout` causes a credential to be persisted in the checked-out repo's `.git/config`, so that subsequent `git` operations can be authenticated. > > Subsequent steps may accidentally publicly persist `.git/config`, e.g. by including it in a publicly accessible artifact via `actions/upload-artifact`. > > However, even without this, persisting the credential in the `.git/config` is non-ideal unless actually needed. > > **Remediation** > > Unless needed for `git` operations, `actions/checkout` should be used with `persist-credentials: false`. > > If the persisted credential is needed, it should be made explicit with `persist-credentials: true`. This has now been addressed in all workflows. Refs: * https://unit42.paloaltonetworks.com/github-repo-artifacts-leak-tokens/ * https://docs.zizmor.sh/audits/#artipacked
…tials GH Actions: do not persist credentials
Add `display_startup_errors=On` and `assert.exception=1` as per the current recommendation from PHPUnit. Ref: * sebastianbergmann/phpunit-documentation-english@b3b159c * https://docs.phpunit.de/en/12.5/installation.html#configuring-php-for-development
Setup-PHP will normally "gracefully" show a warning and not the build when an extension or tool failed to install. This is not particularly useful as that means that either there will be a failure later on in the build due to the extension or tool missing, or the build will not be representative of what is supposed to be tested. This commit changes this behaviour to fail the build at the `setup-php` step, which also makes debugging these type of build failures much more straight-forward. Ref: https://github.com/shivammathur/setup-php?tab=readme-ov-file#fail-fast-optional
GH Actions: update PHP ini configuration
GH Actions: fail "setup-php" if requested tooling could not be installed
…led [2] Follow up on 98, which missed one instance of `setup-php`. --- Setup-PHP will normally "gracefully" show a warning and not the build when an extension or tool failed to install. This is not particularly useful as that means that either there will be a failure later on in the build due to the extension or tool missing, or the build will not be representative of what is supposed to be tested. This commit changes this behaviour to fail the build at the `setup-php` step, which also makes debugging these type of build failures much more straight-forward. Ref: https://github.com/shivammathur/setup-php?tab=readme-ov-file#fail-fast-optional
GH Actions: fail "setup-php" if requested tooling could not be installed [2]
Includes excluding some newly added sniffs as they can't be applied yet due to this package adhering to a different minimum PHP version than most other Yoast packages. Refs: * https://github.com/Yoast/yoastcs/releases/tag/3.3.0 * https://github.com/PHPCSStandards/PHP_CodeSniffer/releases * https://github.com/PHPCSStandards/phpcsutils/releases * https://github.com/PHPCompatibility/PHPCompatibilityWP/releases * https://github.com/automattic/VIP-Coding-Standards/releases * https://github.com/sirbrillig/phpcs-variable-analysis/releases
Composer: update to YoastCS 3.3.0
This upgrade will get us improved compatibility with PHP 8.5.
Composer: update PHPUnit Polyfills
BrainMonkey 2.7.0 has just been released and adds improved compatibility with WP 6.9 for select functions, as well as confirms compatibility with PHP 8.4 and 8.5. Ref: https://github.com/Brain-WP/BrainMonkey/releases/tag/2.7.0
Composer: update the version constraint for BrainMonkey to `^2.7.0`
... as a straight-forward reminder of the steps to release.
Add release checklist
Changelog for release 1.2.1
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.