The current `timeout-minutes` value of `20` is a bit too short for MacOS jobs in GitHub Actions, which on occasion take a bit longer.
This bumps that limit to `30` to avoid unnecessarily flagging a job as stuck.
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@54293 602fd350-edb4-49c9-b593-d223f7449a82
Allows to revert changes applied in [54277] - temporary workaround for the failing Test NPM CI check on Windows.
Improvements included:
- generate combined asset files for both production and development
- store in the repository only the production version of the combined assets for packages, we use everything else only in development
- to make unit tests work, ensure that they ignore react fast refresh and use the production version of combined assets that are present in the source code
Props bernhard-reiter, jsnajdr, clorith, wildworks.
Fixes#56615.
git-svn-id: https://develop.svn.wordpress.org/trunk@54289 602fd350-edb4-49c9-b593-d223f7449a82
This changes the Test NPM GitHub Action workflow to temporarily allow the job validating build tools on Windows to fail.
When the `build:dev` Grunt task is run on Windows, the resulting hashes calculated by Webpack are different than other platforms. This seems to be related to how the `remove-accents` dependency is read and processed during the build script.
Since a Windows machine is not used to build WordPress on the build server, this will only affect local development installs for Windows contributors. While this is investigated, this workflow job can be allowed to fail.
Props bernhard-reiter, desrosj, Clorith, gziolo.
See #56615.
git-svn-id: https://develop.svn.wordpress.org/trunk@54277 602fd350-edb4-49c9-b593-d223f7449a82
Previously, it was not possible to use the default `GITHUB_TOKEN` token to create new workflow runs in an effort to prevent accidental recursive workflows.
This has changed, and the `workflow_dispatch` is now one of two exceptions to this rule. Using `GITHUB_TOKEN` is preferred whenever possible to avoid the need for a PAT (personal access token), which expires (when created using the recommended security best practices), and is tied to an individual user.
See https://github.blog/changelog/2022-09-08-github-actions-use-github_token-with-workflow_dispatch-and-repository_dispatch/.
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@54108 602fd350-edb4-49c9-b593-d223f7449a82
This affects the following test groups:
* Ajax tests
* ms-files tests
* External HTTP tests
* Xdebug tests
The tests being run in these particular test groups are passing on PHP 8.1, however, the test runs are still allowed to “continue on error”. This creates the risk that new PHP 8.1 incompatibilities will be introduced without anyone noticing.
By no longer allowing these test runs to “continue on error”, that risk is removed.
Follow-up to [51588], [51604], [53922].
Props jrf.
See #55656, #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@54072 602fd350-edb4-49c9-b593-d223f7449a82
The correct variable here is `github.run_attempt`, which represents the unique number for each attempt of a particular workflow run in a repository.
The `github.run_number` currently being used represents the unique number for each run of a particular workflow in a repository.
Follow up to [53947].
Fixes#56407.
git-svn-id: https://develop.svn.wordpress.org/trunk@54039 602fd350-edb4-49c9-b593-d223f7449a82
There are several common reoccurring issues that sometimes cause GitHub Action workflows to fail (connection timeouts to WordPress.org or the Docker container registry, `npm install` failures, Chromium issues, etc.). Except when there are service level outages, most of these issues can be resolved by simply rerunning the workflow.
This introduces a new step within each of Core’s GitHub Action workflows that attempts to rerun the failed jobs within the workflow that encountered a failure if they are running for the first time. Since a workflow is not allowed to restart itself, a new `failed-workflow.yml` callable workflow is being introduced.
Other related adjustments in this changeset:
- The `actions/github-script` 3rd-party action is also now updated to the latest version (v6.2.0).
- A new secret, `GHA_WORKFLOW_DISPATCH`, has been introduced. This will replace the current one in use (`GHA_OLD_BRANCH_DISPATCH`) with a less specific name.
Props jorbin, desrosj.
Fixes#56407.
git-svn-id: https://develop.svn.wordpress.org/trunk@53947 602fd350-edb4-49c9-b593-d223f7449a82
PHP 8.2 is expected to be released at the end of November 2022.
Enabling the tests to run in CI on PHP 8.2 allows WordPress core to start getting ready.
As an interim measure, while working through the PHP 8.1 and 8.2 issues, builds against these PHP versions are allowed to fail, so that they don't block PR merges in the Gutenberg project.
Notes:
* The `composer install` command for PHP 8.1 was still using the `--ignore-platform-reqs` option, while that has not been needed anymore for quite a while, so the condition is now reused for PHP 8.2.
* The `--ignore-platform...` option used for the install is now made more specific:
* Composer 2.0 added a `--ignore-platform-req=...` option to selectively ignore platform requirements.
* Composer 2.2 then added the ability to only ignore the upper bound of platform requirements by adding the `+` sign.
* Xdebug-related tests will not be run on PHP 8.2 at this time as the Docker image for PHP 8.2 does not contain Xdebug yet. Once a stable release of Xdebug 3.2.0 is available, it can be added to the Docker image and the test step can then be enabled for PHP 8.2.
References:
* [https://github.com/WordPress/wpdev-docker-images/pull/87 wpdev-docker-images PR #87: Add PHP 8.2 containers]
* [https://github.com/composer/composer/releases/tag/2.0.0 Composer 2.0 changelog]
* [https://github.com/composer/composer/releases/tag/2.2.0 Composer 2.2 changelog]
* [https://xdebug.org/announcements/2022-07-20 Xdebug 3.2.0alpha1 release notes]
* [https://xdebug.org/announcements/2022-07-25 Xdebug 3.2.0alpha2 release notes]
Follow-up to [49077], [49162], [50299], [51588], [51604].
Props jrf, desrosj.
See #56009.
git-svn-id: https://develop.svn.wordpress.org/trunk@53922 602fd350-edb4-49c9-b593-d223f7449a82
This ensures updates for all 3rd party actions will be flagged when updates exist simultaneously.
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53899 602fd350-edb4-49c9-b593-d223f7449a82
This allows a developer to use the persistent Memcached object cache on their local development environment via the `LOCAL_PHP_MEMCACHED` environment variable.
Enable the memcached config via `LOCAL_PHP_MEMCACHED=true` in the `.env` file and then restart the environment with `npm run env:restart`.
Fixes#55700
git-svn-id: https://develop.svn.wordpress.org/trunk@53895 602fd350-edb4-49c9-b593-d223f7449a82
This improves the tag pattern matching for GitHub Action workflows to be more specific. The `*` wildcard in the current patterns matches any character except slash (`/`). While this correctly matches a version like `X.Y.Z`, it could also match non-numeric characters.
This changes patterns to use the `+` character, which matches one or more of the preceding characters (`[0-9]` in this case).
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53736 602fd350-edb4-49c9-b593-d223f7449a82
When trying to determine the outcome of the previous run for a GitHub Action workflow, the current run is included in the list fetched from the GitHub API.
This adjusts the logic checking for the previous run to account for that and fixes notifications for the first workflow runs of a new branch or tag.
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53735 602fd350-edb4-49c9-b593-d223f7449a82
The `workflow_run` event was added to restore Slack notifications for older branches (5.8 and older) without having to backport any changes while alternate approaches were explored.
The workflow has been tested and refined as a reusable one in `trunk`, and this approach is superior to the `workflow_run` event in several ways.
Primarily, the `workflow_run` event results in a separate workflow run being created for sending Slack notifications after the completion of each workflow triggered by `push`. When called as a reusable workflow, this does not happen and the additional jobs are instead added to the initial workflow. This makes which jobs are sending notifications for the current workflow more clear, and reduces the amount of noise (less workflow runs overall).
The `workflow_run` event also makes some data available in different ways than `push` events. By removing it, much of the logic within the workflow can be simplified.
See #56095.
git-svn-id: https://develop.svn.wordpress.org/trunk@53591 602fd350-edb4-49c9-b593-d223f7449a82
This correctly updates the `actions/cache` action. [53581] updated the inline comment to the latest version but did not update the actual SHA value correctly.
Follow up to [53581].
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53582 602fd350-edb4-49c9-b593-d223f7449a82
This updates the following GitHub Actions to the latest versions:
- `actions/checkout`
- `actions/cache`
- `actions/github-script`
- `actions/setup-node`
- `codecov/codecov-action`
- `shivammathur/setup-php`
- `slackapi/slack-github-action`
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53581 602fd350-edb4-49c9-b593-d223f7449a82
`true` is now passed to the `fail_ci_if_error` input when the `codecov/codecov-action` action is used.
When uploading a code coverage report is unsuccessful, the action will now fail and return an error. This will help avoid situations like #56022 where the report was suddenly failing to upload even though the workflow itself appeared to be successful.
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53554 602fd350-edb4-49c9-b593-d223f7449a82
This adds the `pull_request` event to the Code Coverage Report workflow, allowing changes to be verified in a pull request before being committed.
The `branches` and `paths` filters are used to limit when the workflow runs to pull requests with:
- A base branch of `trunk`.
- Changing specific files that can potentially affect the way a coverage report is generated.
Reports generated on `pull_request` events are for testing purposes only and are not submitted to Codecov.
The `docker-compose.yml` file has also been added to the `paths` filter for both `push` and `pull_request` events. Changes to this file could potentially affect the environment used to generate the report (such as the ones in [53552]).
Props afragen, johnbillion, desrosj.
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53553 602fd350-edb4-49c9-b593-d223f7449a82
One change in the update from Xdebug version 2.x to 3.x was a shift from enabling features to switching into modes.
When the version of Xdebug installed in the PHP 7.4 Docker container was updated from 2.x to 3.x, the code coverage reporting workflow stopped generating reports due to a lack of available coverage drivers.
This change adds the `XDEBUG_MODE` environment variable to the local Docker environment configuration to allow the active modes to be changed. This environment variable takes precedence over the `xdebug.mode` setting, but will not change the value of the `xdebug.mode` setting.
The `LOCAL_PHP_XDEBUG_MODE` environment variable has been added to the `.env` file and can be used to change the modes enabled in the Docker container. The code coverage reporting workflow uses this variable to enable the `coverage` mode, which is required for generating a test coverage report.
By default, `debug` and `debug modes are active, which enables the more commonly used features of Xdebug: development helpers and step debugging.
Props afragen, johnbillion, desrosj.
Fixes#56022.
git-svn-id: https://develop.svn.wordpress.org/trunk@53552 602fd350-edb4-49c9-b593-d223f7449a82
This adjusts the logic used to determine the outcome of the previous workflow run of the current one to account for `schedule` and `workflow_dispatch` events.
In the current state, only workflows triggered by `push` events are examined. This is causing failures when trying to post Slack notifications for the Test Coverage workflow, and inconsistent results for `workflow_dispatch` events when testing older branches on a schedule.
Follow up to [53466] and [53468].
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53534 602fd350-edb4-49c9-b593-d223f7449a82
This fixes the code added in [53466] to look at the correct workflow object when determining the outcome of the previous workflow run.
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53468 602fd350-edb4-49c9-b593-d223f7449a82
When searching for previous workflow runs by branch, GitHub currently includes matches within forks.
If a contributor opens a pull request from their fork with a `head_ref` matching a Core branch that triggers a workflow on `push` event, the outcomes of the workflows associated with that pull request are currently used to determine if the previous workflow run had failed.
The result is a false “fixed” notifications when a commit immediately follows a failed workflow run from the pull request.
This adds a check to skip any workflow runs not triggered by a `push` event to prevent these inaccurate notifications.
Props SergeyBiryukov.
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53466 602fd350-edb4-49c9-b593-d223f7449a82
This adjusts the workflow run URLs included in Slack notifications to link to the specific attempt being reported on making it easier for someone to see the proper context of a specific notification.
Additionally, this eliminates the need for a contributor to share the reason for a failure in Slack before restarting the workflow, as the link will always be to that specificattempt. When a “fixed” notification occurs for a subsequent run attempt, the link will be to the new, successful run attempt.
See #55652.
git-svn-id: https://develop.svn.wordpress.org/trunk@53427 602fd350-edb4-49c9-b593-d223f7449a82
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
This adjusts the logic of the Slack Notifications workflow to make the “fixed” notifications more reliable.
Currently, the workflow looks at the immediately preceding workflow run for the current branch. This fails to indicate that a workflow is fixed when other unrelated commits are made, and when rerunning the workflow after a false failure (timeout, etc.).
The workflow will now use the following logic to determine if something has been fixed:
- When a workflow is rerun, the conclusion for the immediately preceding run attempt will now be used to determine if the current attempt has “fixed” the workflow.
- When on the first run attempt for a workflow run, the workflow conclusion for the immediately preceding commit will be used.
- When on the first run attempt for a workflow run and no preceding commits for the current branch are present (this is a fresh tag or branch), always consider it “fixed”.
Props davidbaumwald.
See #54742.
git-svn-id: https://develop.svn.wordpress.org/trunk@53108 602fd350-edb4-49c9-b593-d223f7449a82
This fixes a JavaScript error in the Slack notifications workflow. This was causing the first workflow run for each workflow in a new branch or tag to be reported as a failure, even if the important parts of the workflow succeed.
When running a workflow for the first time, a default of `failure` is now used for the previous outcome. This will trigger a success notification to be sent to report successful branching/tagging.
Props davidbaumwald.
Fixes#54742.
git-svn-id: https://develop.svn.wordpress.org/trunk@53077 602fd350-edb4-49c9-b593-d223f7449a82
After the 5.9 branch was created, [52449] updated the workflow for testing old branches to include 5.9. However, the E2E tests `-branch` condition was updated to 5.9 instead of adding an additional branch condition for 5.9. This commit re-enables the E2E tests for 5.8.
Props desrosj, hellofromTonya.
Fixes#54749.
git-svn-id: https://develop.svn.wordpress.org/trunk@52546 602fd350-edb4-49c9-b593-d223f7449a82
This eliminates the need to manually check all GitHub Actions used within workflow files for updates.
Fixes#54503.
git-svn-id: https://develop.svn.wordpress.org/trunk@52241 602fd350-edb4-49c9-b593-d223f7449a82
This ensures that the cache is busted properly when the ruleset is adjusted but the `composer.json` file is not.
See #54425.
git-svn-id: https://develop.svn.wordpress.org/trunk@52220 602fd350-edb4-49c9-b593-d223f7449a82
When the `PHP_CodeSniffer` runs, it produces a cache file. When a cache file is present, only changed files are rescanned, making subsequent scans significantly faster.
This adds the needed steps to the corresponding GitHub Actions workflows to cache these files across runs. The cache keys include the date of the previous Monday to ensure that the cache is flushed at least weekly.
Since GitHub Action caches cannot be updated once created, the scans will take slightly longer as the week progresses and more PHP files are updated. The date within the cache key can be updated to purge twice weekly if the scan time starts to approach the current scan times.
This change also introduces a `.cache` directory for all caching files related to build/test tools.
Props johnbillion, jrf.
Fixes#49783.
git-svn-id: https://develop.svn.wordpress.org/trunk@52179 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
This makes the needed adjustments to fix Slack notifications for `scheduled` and `workflow_dispatch` events. The data needed to send notifications for these events are stored in different locations, or need to be accessed through API requests.
Follow up to [51921], [51937].
See #53363.
git-svn-id: https://develop.svn.wordpress.org/trunk@51953 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
In [51921], the GitHub Actions workflows were updated to utilize the Slack notifications workflow as a callable one instead of on the `workflow_run` event.
This eliminated the need for an additional “Slack Notifications” workflow run for every completed workflow, but only when other workflows are updated as well. This resulted in notifications from older branches breaking, as the changes in [51921] were not backported.
Instead of backporting the needed changes now (the Slack workflow is still being polished), this commit partially restores the `workflow_run` event for older branches so that notifications will resume.
See #53363.
git-svn-id: https://develop.svn.wordpress.org/trunk@51934 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
