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 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. https://github.com/ 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 https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. 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. https://www.mysql.com/. 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. https://wordpress.org/gutenberg/ 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

Proposal: Update all git repositories to use `trunk` instead of `master`

The WordPress 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. community cares about diversity. We strive to maintain a welcoming environment where everyone can feel included, by keeping communication free of discrimination, incitement to violence, promotion of hate, and unwelcoming behavior.

WordPress Etiquette

As a part of tearing down the systems of oppression that exist in the world, WordPress should remove references to master and replace them with trunk in all git repositories.

Master as the primary branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". in git has its roots in BitKeeper which explicitly used it to mean master/slave relationships. Master/Slave is terminology rooted in oppression.

This may require updates to scripts so everything continues to function correctly. For things on GithubGitHub GitHub is a website that offers online implementation of git repositories that can 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. https://github.com/, there is a tool worth exploring to help with this: https://github.com/liyanchang/default-branch-migration

WordPress would not be alone in working to remove master/slave terminology. Github is changing the default, popular plugins such as Jetpack are updating and open source projects like Drupal and Python have already made this change. This is also in line with the work to eliminate whitelist/blacklist from the Core codebase.

This is a small move, but if it makes one more person comfortable contributing to a WordPress project, it will be worth it.

EDIT: This proposal originally suggested using main, I have modified it to use trunk based on feedback.

Props @desrosj and @jeffpaul for pre-publication feedback

#git, #github

Git Mirror History Breakage

A few years ago, I started publishing a mirror of WordPress on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can 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. https://github.com/. It was subsequently promoted to WordPress/WordPress. What I neglected to do, however, was provide an appropriate authors.txt file, until recently. That means that earlier commits are attributed to dummy e-mail addresses and as such cannot be associated with user accounts on GitHub. Considering the recent introduction of contributions on GitHub, this seems a shame. Also, if we were to move to GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. in the future, we would probably want our official mirror to have the best possible data.

Proposed

That we re-run the git-svn import with a proper authors.txt file.

Upsides

We’ll have a proper Git mirror with good and consistent author data, that we can, if desired, use for a future migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. to Git. Commits will be properly attributed in GitHub.

Downsides

This will break Git history. If you have a Git checkout of WordPress, either standalone or in a submodule, that’ll mean that you’ll have to rebase your master branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". off of origin (or even better, blow the whole thing away and re-clone).

So: thoughts? Would this ruin your day?

#git, #github

For forking pleasure: http://github.com/…

For forking pleasure: http://github.com/wordpress/

#git, #github