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
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
This change adds a list of paths to check when determining which workflows to run on `pull_request`. This will prevent certain workflows from running unnecessarily when the files updated are not related to the tests and checks being performed.
Props peterwilsoncc, johnbillion.
Fixes#52667.
git-svn-id: https://develop.svn.wordpress.org/trunk@50479 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 `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
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 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
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
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
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
