This updates all 3rd party GitHub actions to their latest versions.
- `actions/cache` from `2.1.6` to `3.0.1`.
- `actions/github-script` from `5.0.0` to `6.0.0`.
- `actions/setup-node` from `2.4.1` to `3.1.0`.
- `codecov/codecov-action` from `2.1.0` to `3.0.0`.
- `ramsey/composer-install` from `1.3.0` to `2.1.0`.
- `shivammathur/setup-php` from `2.15.0` to `2.18.0`.
Additionally, this updates all instances of the `actions/setup-node` action to replace the `node-version` option with the new `node-version-file`. This simplifies the process of changing the version of NodeJS used in workflows by only requiring the version to be changed once in the `.nvmrc` file.
See #54725.
git-svn-id: https://develop.svn.wordpress.org/trunk@53112 602fd350-edb4-49c9-b593-d223f7449a82
When using a workflow as a callable workflow, the job status check functions do not take the called workflow into account. This has caused some failures to be incorrectly reported as successful.
This adds an input to the Slack notifications workflow for when the `workflow_call` event is used.
See #53363.
git-svn-id: https://develop.svn.wordpress.org/trunk@52002 602fd350-edb4-49c9-b593-d223f7449a82
When a workflow is triggered through a `workflow_run` event, the context is not the original workflow. The details about the original workflow are passed through the `github.event` context.
This also moves the conditional check controlling whether the Slack workflow is run into the calling workflows to prevent them from running for pull requests.
Follow up to [51921-51922,51924-51925,51934].
See #53363.
git-svn-id: https://develop.svn.wordpress.org/trunk@51937 602fd350-edb4-49c9-b593-d223f7449a82
Secrets are not available within callable workflows by default. They must be defined within the callable workflow, and passed from the calling workflow.
Follow up to [51921-51922].
See #53363.
git-svn-id: https://develop.svn.wordpress.org/trunk@51924 602fd350-edb4-49c9-b593-d223f7449a82
The ability to reuse workflow files within GitHub Action workflows was recently added and allows for less code duplication.
In the context of WordPress Core, this also eliminates the need for an additional “Slack Notifications” workflow to run for every completed workflow.
See #53363.
git-svn-id: https://develop.svn.wordpress.org/trunk@51921 602fd350-edb4-49c9-b593-d223f7449a82
This unpins the version of PHP 5.6.20 used when testing the 5.6 branch of PHP.
Using 5.6.20 was an intentional decision in [49162], as that patch version is the oldest version of PHP 5.6 still supported by WordPress. However, as of September 30, 2021, the `5.6.20` image contains a version of OpenSSL with an expired certificate, sometimes resulting in an expired trust chain.
Props Clorith, hellofromTonya, SergeyBiryukov, desrosj.
Merges [51889] to `trunk`.
Fixes#54223.
git-svn-id: https://develop.svn.wordpress.org/trunk@51890 602fd350-edb4-49c9-b593-d223f7449a82
This commit:
* Removes the PHPUnit `wordpressdevelop/phpunit` container as a service to the Docker environment.
* Updates `test:php` (the default way to run tests) to run the Composer PHPUnit package default.
* Removes the `test:php-composer` script.
There is no longer a need for core to keep the `wordpressdevelop/phpunit` container as a service in `docker-compose.yml`. Removing it will reduce the overhead and bandwidth needed to set up WordPress locally and remove confusion about its use.
Follow-up to [45783-45784], [49099], [49362], [51545], [51736], [51685].
Props johnbillion, hellofromTonya.
Fixes#54112.
git-svn-id: https://develop.svn.wordpress.org/trunk@51868 602fd350-edb4-49c9-b593-d223f7449a82
This fixes the CI for PHP 8.1 while retaining the needed improvements for local testing when running `npm run test:php-composer` by:
* Replacing the npm script with the full node command
* Removing the `composer update` command from the `env:install` process
Props BinaryKitten, hellofromTonya
See #53945
git-svn-id: https://develop.svn.wordpress.org/trunk@51736 602fd350-edb4-49c9-b593-d223f7449a82
This removes the previously duplicated set of test runs specifically for PHP 8.1 in favor of combining `if` conditions for individual test runs with the `continue-on-error` option.
Follow-up to [51588].
Props desrosj, swissspidy, jrf.
Fixes#53891.
git-svn-id: https://develop.svn.wordpress.org/trunk@51604 602fd350-edb4-49c9-b593-d223f7449a82
PHP 8.1 is expected to be released at the end of November 2021.
Enabling the tests to run in CI on PHP 8.1 allows us to get WordPress ready in time.
As an interim measure, while working through the PHP 8.1 issues, separate conditional steps are added to run the tests on PHP 8.1 with the `continue-on-error` option. That allows the test builds to show as "successful" if all non-PHP 8.1 test runs pass.
Follow-up to [51517], [51543], [51545], [51574], [51582], [51586].
Props jrf.
Fixes#53891. See #53635.
git-svn-id: https://develop.svn.wordpress.org/trunk@51588 602fd350-edb4-49c9-b593-d223f7449a82
Previously the tests were run via a PHPUnit Phar file for PHP 5.6–7.4, with PHP 8.0 using a Composer-installed version of PHPUnit.
Running the tests via a Phar without the need for a `composer install` is (marginally) faster in overall build time, however, this commit is part of a larger chain of changes which will make the test suite PHPUnit cross-version compatible.
With an eye on those upcoming changes, which will allow us to run the tests on the most appropriate PHPUnit version for each supported PHP version, it is opportune to switch to using a Composer-installed version of PHPUnit for all PHP versions supported by WordPress. Previously this was not possible without additional conditional `update` commands being run, due to the `composer.lock` file being in place and being locked at PHPUnit 7.5.20.
Switching over to using the Composer-installed PHPUnit version, with that PHPUnit version adjusting based on the PHP version, allows for some minor simplifications in the GitHub Actions script.
This means we need additional measures to make sure that the Composer cache file does not go too far out of date as that would significantly slow down the builds.
By adding a "Last Monday" date to the cache key, in combination with the pre-existing OS, PHP version and the hash of the `composer.json` file, we can guarantee that:
1. There will be a cache created for each OS/PHP combination.
2. These caches will be replaced whenever a change is made to the `composer.json` file.
3. These caches will be replaced every Monday of each week ensuring that the cache file does not go too far out of date.
Note: The NPM script `test:php` is now no longer needed during the builds. However, to prevent breaking the workflow of contributors who may be used to having the command available, the command remains available.
In a future iteration we may be able to replace the caching of the Composer dependencies with the Composer cache action as offered on the GitHub marketplace, which would further simplify the script.
Follow-up to [42960], [46290], [47881], [48957], [49037], [51543], [51544].
Props jrf, desrosj.
Fixes#47381.
git-svn-id: https://develop.svn.wordpress.org/trunk@51545 602fd350-edb4-49c9-b593-d223f7449a82
This expands Slack notifications to include success, cancelled, and “fixed” GitHub Action workflow run outcomes in addition to failures.
A “fixed” outcome occurs when the previous run for a workflow failed and the current one succeeds. This matches the behavior that was native to TravisCI by setting `on_success` for notifications to `change`.
The message details and where each outcome is posted is controlled by Slack workflows.
The Slack notification logic has also been pulled into a separate workflow to prevent repeating code in every workflow.
See #52644.
git-svn-id: https://develop.svn.wordpress.org/trunk@51535 602fd350-edb4-49c9-b593-d223f7449a82
This adds an additional step to each GitHub Action workflow file that posts a message to #core in Slack every time a workflow run fails.
A minor test and spacing change is included in this commit in order to that messages are posted correctly and will be reverted after testing.
See #52644.
git-svn-id: https://develop.svn.wordpress.org/trunk@51511 602fd350-edb4-49c9-b593-d223f7449a82
Some tests and some commands that run during the build steps modify files that are under version control. This adds assertions to ensure that these files don't remain in a modified state after the test runs on CI.
This also fixes the `grunt clean` command which erroneously deletes `script-loader-packages.php`. This file is re-populated during the build, but deleting it during the clean is undesirable.
Fixes#53606
git-svn-id: https://develop.svn.wordpress.org/trunk@51355 602fd350-edb4-49c9-b593-d223f7449a82
This updates the `actions/setup-node` action to version 2.2.2 and takes advantage of the cache feature now built in. This removes the need for an additional step using `actions/cache` to cache NPM dependencies.
The cache key used will be `${{ runner.os }}-npm-${{ hashFiles('') }}`, which matches the recommendation in the `actions/cache` documentation and the key currently in use in the WordPress workflows.
Props gziolo.
Fixes#53584.
git-svn-id: https://develop.svn.wordpress.org/trunk@51341 602fd350-edb4-49c9-b593-d223f7449a82
The new `concurrency` setting can be used to ensure only a single workflow run or job is in progress. When used in combination with the `cancel-in-progress` setting, incomplete workflow runs can be cancelled automatically to prevent running workflows unnecessarily.
The workflows that take longer to run previously had this built into a step and utilized a 3rd-party action. Now that this is natively supported by GitHub Actions, using that is preferred.
This option is currently in beta, but is stable enough to use in our workflows for the time being.
Props ocean90.
Fixes#53080.
git-svn-id: https://develop.svn.wordpress.org/trunk@50930 602fd350-edb4-49c9-b593-d223f7449a82
The reorganization of the PHPUnit workflow in [50441] unintentionally caused the tests to be run for every `push` event, even for forks and private mirrors.
Previously, the second job required the first one to pass, and the conditional check on the first prevented both from running. Because the first job is no longer required for the second, both jobs must have the appropriate conditional check.
Fixes#52983.
git-svn-id: https://develop.svn.wordpress.org/trunk@50670 602fd350-edb4-49c9-b593-d223f7449a82
On TravisCI, old branches still receiving security updates were tested on a regular basis. This ensured tests continued to pass as time passed even if updates were not made to these branches.
On GitHub Actions, there is no interface to configure this (TravisCI had a UI), but there is a `schedule` event that can trigger workflow runs on cron that can be used to accomplish the same thing.
This introduces a workflow file that runs twice a month (on the 1st and 15th) to verify the tests within older branches.
Because the `schedule` event only runs within the primary branch, the appropriate workflows in each old branch will be triggered manually through the `workflow_dispatch` trigger using the GitHub REST API. `workflow_dispatch` will need to be added to all workflows in all old branches in order for the event to dispatch successfully.
Fixes#52653.
git-svn-id: https://develop.svn.wordpress.org/trunk@50590 602fd350-edb4-49c9-b593-d223f7449a82
This also adds inline comments to the end of each action installed using a SHA value to make it easier to determine which version of an action is currently being used.
Follow up to [50474,50476].
Props johnbillion.
See #52625.
git-svn-id: https://develop.svn.wordpress.org/trunk@50486 602fd350-edb4-49c9-b593-d223f7449a82
Additionally, the `access_token` input now defaults to `github.token`, so specifying it is unnecessary.
Follow up to [50474].
Props johnbillion.
See #52625.
git-svn-id: https://develop.svn.wordpress.org/trunk@50476 602fd350-edb4-49c9-b593-d223f7449a82
Using `npm ci` makes better use of the npm cache that's in use, speeding up the test runs by around 30 seconds.
See #52660
git-svn-id: https://develop.svn.wordpress.org/trunk@50446 602fd350-edb4-49c9-b593-d223f7449a82
The `external-http`, `media`, and `restapi` groups combined take roughly the same time as all the other tests combined. Splitting the test run in two speeds up the PHP 5.6 test runs which are the slowest by quite a margin. The net reduction in duration is only seen on PHP versions older than 7.0 where the reduction is greater than the time taken for the job to be set up.
Props peterwilsoncc, desrosj, johnbillion
Special shout out to manzoorwanijk whose article about running steps in parallel started me down this path.
Fixes#52645
git-svn-id: https://develop.svn.wordpress.org/trunk@50444 602fd350-edb4-49c9-b593-d223f7449a82
Some PHPUnit tests were concerned with the state of files in the `build` directory. In order to allow the tests to run without requiring a build to be run first, these have been moved into assertions that run after the build step (and therefore cause it to fail if they do not pass), or into QUnit tests as necessary.
Various other PHPUnit tests implictly depend on built JavaScript files being present. These files are now touched during the test setup to avoid PHP warnings if the `build` files are not present.
The `wp-tests-config-sample.php` file and the GitHub Actions configuration have also been changed so `ABSPATH` uses `src` instead of `build`, therefore allowing the PHPUnit tests to be run without a build having to be run first. This means all new local installations of WordPress will use `src` for PHPUnit testing. If you would like to switch your existing installation over then change the location of `ABSPATH` in `wp-tests-config.php` to point to `src` instead of `build`.
Props peterwilsoncc, iandunn, gziolo, desroj, johnbillion
Fixes#51734
See #45863
git-svn-id: https://develop.svn.wordpress.org/trunk@50441 602fd350-edb4-49c9-b593-d223f7449a82
The `actions/cache` GitHub action uses a `key` input to find the desired cache in storage. Currently, this is defined as a combination of the operating system being used, the software being cached (NPM or Composer), PHP version (Composer only), and a hash of the relevant lock file.
The `cache` action also supports a `restore-keys` input, which is an ordered list of keys to use for restoring a cache if no cache hit occurred for the specified key.
However, this means that every time a lock file is updated, the cache is being recreated by first restoring a previous one (when available), and then installing new versions of dependencies on top of that. This results in old, unused versions of dependencies never being removed from the cache.
In this change, the `restore-keys` are removed. This will force a new, fresh cache to be generated when the desired `key` is not matched. In testing, this results in a ~40% reduction in cache size when compared to the latest successful workflow runs. Since there is no way to manually flush the cache in GHA, the benefits of this change will not be seen until the `package-lock.json` and `composer.lock` files are updated, or the cache at the desired key is evicted.
Props johbillion.
See #52660.
git-svn-id: https://develop.svn.wordpress.org/trunk@50436 602fd350-edb4-49c9-b593-d223f7449a82
In GitHub Actions, there is a `fail-fast` option that will cancel all incomplete jobs within a workflow as soon as one failure is encountered. This defaults to `true`.
This is great for alerting you of a failure faster, but does not give you the full picture of what is failing. For example, it’s possible that there is a failing test on 2 versions of PHP, but not others. If `fail-fast` is enabled, it’s impossible to know this.
Even with `fail-fast` disabled, the workflow will still report a failure if one or more jobs produce a failing result.
Props johbillion, jorbin.
Fixes#52612.
git-svn-id: https://develop.svn.wordpress.org/trunk@50435 602fd350-edb4-49c9-b593-d223f7449a82
Different branches have support for different types of testing based on the tooling that was in place at the time each version was branched. The workflows currently in place have patterns configured to match the relevant `branches` and `tags` for each workflow, but only for `push` events.
This copies the patterns for matching supported `branches` over to the `pull_request` event to prevent workflows from running for a pull request to a branch that does not support that workflow.
Fixes#52643.
git-svn-id: https://develop.svn.wordpress.org/trunk@50432 602fd350-edb4-49c9-b593-d223f7449a82
This group is not specified in the list of excluded groups within the test configuration file, so they already run as part of the main test suite.
Props johnbillion.
Fixes#52608.
git-svn-id: https://develop.svn.wordpress.org/trunk@50413 602fd350-edb4-49c9-b593-d223f7449a82
This updates two published GitHub actions to their latest versions:
- `actions/setup-node` from `v1` to `v2`.
- `styfle/cancel-workflow-action` from `0.5.0` to `0.8.0`.
See #50401.
git-svn-id: https://develop.svn.wordpress.org/trunk@50387 602fd350-edb4-49c9-b593-d223f7449a82
The PHP 8 Docker container for the local WordPress environment now contains xDebug 3.x (the version required for running on PHP 8), so the `xdebug` test group can now be run.
See #50401, #51802.
git-svn-id: https://develop.svn.wordpress.org/trunk@50299 602fd350-edb4-49c9-b593-d223f7449a82
This expands the list of events that triggers automated testing to include tags.
It also refines the matched version ranges for several workflows.
See #50401.
git-svn-id: https://develop.svn.wordpress.org/trunk@50298 602fd350-edb4-49c9-b593-d223f7449a82
The WordPress Importer plugin is now downloaded to the `tests/phpunit/data/plugins` directory when running `npm run env:install`.
This ensures that the PHPUnit test suite will not fail when the plugin is missing.
This also introduces a new `WP_IMPORTER_REVISION` variable to the `.env` file, to control the SVN revision that is checked out.
Props johnbillion.
Fixes#49720.
git-svn-id: https://develop.svn.wordpress.org/trunk@50285 602fd350-edb4-49c9-b593-d223f7449a82
This simplifies the caching of Composer dependencies in the coding standards and PHP compatibility workflows by using a published action. This combines 3 steps into 1 within these workflows.
Because the Composer implementation within the PHPUnit test workflow is a bit specialized (`composer install` is run within the Docker container), caching has been left as is in that workflow. However, the cache key has been changed to include the version of PHP being tested. This will prevent incorrect versions of dependencies being present when they are required on jobs other than PHP 8.
Props jrf.
See #50401.
git-svn-id: https://develop.svn.wordpress.org/trunk@49938 602fd350-edb4-49c9-b593-d223f7449a82
This will help catch issues with Ajax related functionality on multisite.
A few tests have also been marked as `skipWithMultisite()` as they require network admin level capabilities when performing the same operations on a multisite install.
Props garrett-eclipse, netweb.
Fixes#46567.
git-svn-id: https://develop.svn.wordpress.org/trunk@49835 602fd350-edb4-49c9-b593-d223f7449a82
The test reporter uses the hidden `.svn` or `.git` directories to determine which changeset to send to WordPress.org along with the test report.
Because the GitHub Action workflow builds and prepares WordPress in a preceding job to share with each test job, the `.git` directory is missing (it is purposefully not included to limit artifact size).
This re-establishes the directory as a checkout of the `wordpress-develop` repository so that test results can be reported correctly.
See #50401.
git-svn-id: https://develop.svn.wordpress.org/trunk@49786 602fd350-edb4-49c9-b593-d223f7449a82
In the current state, the workflows run regardless of the repository context. This results many needless workflow runs that waste resources.
Workflow runs for private repositories are not free (accounts have a finite allotment of minutes for private repositories). This becomes problematic in private repositories that also mirror the WordPress develop repository, as any workflow runs will draw from a user’s or organization’s allotted action minutes.
Without blanket disabling the workflow manually for all event triggers, or modifying the workflow files in the forked/mirrored repository, there is no way to tune when the workflows run.
This change introduces a conditional statement into all GitHub Action workflows that prevents them from running on forked/mirrored repositories that are not `wordpress-develop`, except when a pull request is being submitted to that repository.
The exception to this is the Welcome workflow that posts a helpful message to first time contributors to `wordpress-develop`. This message is specific to this repository, so should only run when a PR is submitted to that repository.
See #50401.
git-svn-id: https://develop.svn.wordpress.org/trunk@49781 602fd350-edb4-49c9-b593-d223f7449a82
The `install-changed` package records a hash of the `package.json` file locally in a text file and only runs `npm install` when there are changes to account for.
This builds on [47497], which only hashes the `package.json` file after a Grunt task is called. By using `npx install-changed` within the workflow files, the package is hashed before the first Grunt task is run.
Props ocean90.
See #50401, #49594.
git-svn-id: https://develop.svn.wordpress.org/trunk@49369 602fd350-edb4-49c9-b593-d223f7449a82
Because workflow results are reported for each commit, it’s important to let all runs against main and version branches to complete so that the checks are reported accurately.
When considering and reviewing pull requests, the only workflow run that matters is the most recent.
Props ocean90, helen.
See #50401.
git-svn-id: https://develop.svn.wordpress.org/trunk@49244 602fd350-edb4-49c9-b593-d223f7449a82
This change makes better use of the job strategy matrix for workflows. By using `include`, the memcached and test reporting job can be configured more clearly.
Props ocean90.
See #50401.
git-svn-id: https://develop.svn.wordpress.org/trunk@49204 602fd350-edb4-49c9-b593-d223f7449a82
