Continuing the transition to GitHub Actions for automated testing

Two months ago, the configuration files needed to run automated tests using GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. Actions were added to WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

GitHub Actions allows us to automate software workflows directly in GitHub, triggered by GitHub events. By switching, we are able to take advantage of a unified interface, inline annotations for linting issues in pull requests, the broader open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. ecosystem building and using Actions including existing work in Gutenberg, and free availability for public repositories. Note that private repositories do use the monthly bucket of included minutes.

Introducing GitHub Actions for Automated Testing

During this transition process, the workflows have been running smoothly with only small issues coming up (which have been fixed). The workflows are also performing better or identically to those run in TravisCI.

With the branching of 5.6, the workflows have been running for both trunk and the 5.6 branches. This has allowed them to be tested successfully in both the primary and non-primary branches.

Since [49162], an additional workflow that generates a code coverage report has also been introduced. Currently, this workflow generates coverage reports for both single and multisite installs and uploads the reports as artifacts to the workflow run. For now, this workflow runs weekly on Sunday at 00:00 UTC. #52141 has been opened to explore submitting the reports to an external service

Additionally, TravisCI has made further changes to their pricing models. As a result, no builds for the WordPress organization have run since the first week of December. When this happened, efforts to transition all repositories under the WordPress GitHub organization from TravisCI to GitHub Actions were accelerated.

As of today, all repositories have been fully transitioned to GitHub Actions except the WordPress Coding Standards (which has an open PR being actively refined), and the ones noted below. These are lower priority repositories because they are updated much less frequently than others. Here they are ranked in order of priority highest to lowest:

Pull requests are very much welcome!

The Appveyor build configuration (which has been replaced with the Test NPM on Windows workflow) was removed from Core in [49779,49809-49814], and the TravisCI configuration was removed in [49876-49898].

Forked repositories

To avoid workflows from running unnecessarily, conditional checks have been added to prevent all workflows from running in forked repositories. There are two exceptions to this:

  • When a pull request is opened to the official wordpress-develop repository from a fork.
  • When a pull request is opened to a forked repository from within a fork.

Known next steps (updated)

  1. Add and configure SlackSlack Slack is a Collaborative Group Chat Platform The WordPress community has its own Slack Channel at notifications. In addition to sending the results of the whole build of a core commit into #core, we may also want to consider a firehose channel for PRs. This may require all workflows to be combined into a single workflow if needed middleware cannot be found.
  2. Backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. the workflow files to actively maintained older branches.
  3. Finish backporting the local Docker environment to branches 3.7-4.5. This is blocked by:
    • wpdev-docker-images#46, which aims to fix the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 5.2 PHPUnit image to include the requred version of PHPUnit (3.6).
    • WP branches <= 4.5 are running a version of NodeJS that is too old for the needed NPM packages required to run the local Docker environment.
  4. Move to GitHub badges for build status indicators – note that these are per-workflow, which is different from the single badge for the entire Travis build for a given commit. However, GitHub does report an overall status for a commit/PR, so we may be able to use that information as well. It seems that the expectation in the greater developer community is that projects report status with a singular badge. Like the Slack notifications, this may require the workflows to be combined in the absence of middleware.
  5. Report test results to the Host Test Results page. The MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. version being tested is not currently being reported (see phpunit-test-runner#135).
  6. Switch to ESLint from JSHint, as the latter does not appear to easily support inline annotations, and the former is in broader usage including in core for docs, GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. and many community projects. See #31823 for more – volunteers very much appreciated here.

Committers: Until the Slack notifications are configured, please monitor the workflow runs associated with your commits to ensure they pass.

The goal is for the remaining repositories and items 1-3 above to be completed in January 2021.

Props @helen for peer reviewing this post.

#build-test-tools, #github, #github-actions