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
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 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
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
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
When a contributor opens their first pull request to `wordpress-develop`, the “Welcome” workflow runs and leaves a comment with guidance, helpful information, and resources.
However, because a workflow run triggered by the `pull_request` event runs against the workflow and code from the merge commit, the needed context and permissions to comment on the pull request are missing. By changing the trigger event to `pull_request_target`, the workflow runs against the workflow and code in the base of the pull request and is able to comment on when appropriate.
See #50401.
git-svn-id: https://develop.svn.wordpress.org/trunk@49169 602fd350-edb4-49c9-b593-d223f7449a82
When a workflow is cancelled, it’s marked as a failure. This is not ideal because the commit attached to the workflow run will appear as though it introduced a problem, but this may not be true.
Because GitHub Actions work a bit differently than Travis builds, it’s unlikely that the same bottleneck will be encountered in workflows.
This change removes all workflow job steps that cancel previous workflows.
See #50401.
git-svn-id: https://develop.svn.wordpress.org/trunk@49168 602fd350-edb4-49c9-b593-d223f7449a82
This change introduces 6 different workflows accounting for all of the testing and analysis currently performed in Travis CI & Appveyor:
- Checking PHP & JS coding standards are followed
- Running the end-to-end test suite.
- Running QUnit tests on JavaScript files.
- Scanning for PHP compatibility issues with supported version.
- Running the PHPUnit test suite.
- Verifying NPM related tasks do not cause errors on Windows.
Additionally, a seventh workflow is included that will leave a "welcome" comment when a contributor opens their first pull request to the `wordpress-develop` mirror.
These workflows are currently in an experimental phase. For that reason, Travis CI and Appveyor will continue to run until all of the bugs can be worked out.
Props ayeshrajans, helen, ocean90, desrosj.
See #50401.
git-svn-id: https://develop.svn.wordpress.org/trunk@49162 602fd350-edb4-49c9-b593-d223f7449a82
