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 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
bash is the default shell for all non-Windows GitHub Action runners, so this is not necessary.
Follow up to [51670].
See #53363.
git-svn-id: https://develop.svn.wordpress.org/trunk@51671 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
When the workflow file is updated, it should always be run to verify changes.
Follow up to [50592].
See #52786.
git-svn-id: https://develop.svn.wordpress.org/trunk@50595 602fd350-edb4-49c9-b593-d223f7449a82
This splits the code coverage workflow into two separate jobs, allowing single site and multisite to run in parallel. This cuts the total workflow run time in half.
Fixes#52923.
git-svn-id: https://develop.svn.wordpress.org/trunk@50594 602fd350-edb4-49c9-b593-d223f7449a82
Since [50285], the WordPress Importer plugin (which is required for the test suite to run successfully) has been installed as part of the `npm run env:install` script.
See #52625.
git-svn-id: https://develop.svn.wordpress.org/trunk@50593 602fd350-edb4-49c9-b593-d223f7449a82
Since [50441-50442] switched the test workflows to run from `src` instead of `build`, code coverage reporting has stopped working. This was caused by the code coverage configuration continuing to reference `build`. This corrects the configuration so coverage reporting can resume.
This change also introduces the `workflow_dispatch` event to the workflow, which will allow committers to manually run the workflow when desired. For example, to confirm changes to the test suite do not break reporting.
This also adds the `phpunit.xml.dist` and `tests/phpunit/multisite.xml` files to the `paths` list. Since these files are responsible for configuring the test suite and code coverage reporting, any changes to them should verify that no problems were introduced.
Props jrf, johnbillion.
Fixes#52786. See #51734.
git-svn-id: https://develop.svn.wordpress.org/trunk@50592 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
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
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
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
Before the coverage reports were submitted to Codecov.io, HTML coverage reports were compressed into ZIP files and uploaded to the workflow run as an artifact. A weekly schedule was chosen to run this workflow because generating a coverage report is more time consuming, and the resulting reports are quite large (~150-200MB each).
This changes the schedule for the code coverage workflow from weekly to daily and eliminates the ZIP artifacts that were previously generated. This will ensure the code coverage data found at https://codecov.io/gh/WordPress/wordpress-develop is relatively accurate on any given day of the week without needlessly consuming artifact storage.
Props jorbin.
See #50401, #52141.
git-svn-id: https://develop.svn.wordpress.org/trunk@49931 602fd350-edb4-49c9-b593-d223f7449a82
This introduces a new GitHub Action workflow to generate a code coverage report when running the PHPUnit test suite as both a single and multisite install.
The workflow will run once per week on Sunday at 00:00 UTC.
For now, the reports are not submitted anywhere, but they will be uploaded to the workflow run as ZIP file artifacts where they will persist for 90 days.
Making code coverage reports more readily available will hopefully better highlight areas of Core with poor coverage, and encourage more contributors to help increase test coverage of those areas.
Props ocean90, johnbillion.
Fixes#52034.
git-svn-id: https://develop.svn.wordpress.org/trunk@49834 602fd350-edb4-49c9-b593-d223f7449a82
