10up Releases WordPress GitHub Actions To Streamline Plugin Deployment

According to GitHub, developers have contributed more than 1,200 Actions to GitHub Marketplace since GitHub Actions was released in beta last year. Our mission to craft tools for content creators — including developers — and our passion for open-source contribution led us to make a solution that uses GitHub Actions to radically streamline and simplify WordPress plugin release management.

Automating Your Workflow With GitHub Actions
GitHub Actions enables you to create custom software development life cycle (SDLC) workflows directly in your GitHub repository. You can write individual tasks, called actions, and combine them to create a custom workflow. Workflows are custom automated processes that you can set up in your repository to build, test, package, release, or deploy any code project on GitHub.

As a WordPress core lead developer and Director of Open Source Initiatives at 10up, I immediately saw the opportunity to use GitHub Actions to make specific tasks easier for WordPress plugin developers, like deploying a plugin and its assets/readme updates to the official WordPress.org plugin repository.

We previously introduced early versions of these Actions, and now they’re ready for primetime following the announcement of general availability of GitHub Actions — an announcement that took the time to spotlight our “WordPress publishing” solution:

WordPress GitHub Actions Mention on the GitHub Blog

This official call out follows an earlier GitHub blog post, highlighting it in more detail back in October:

WordPress Plugin Deploy Mention on the GitHub Blog

Deploying A Plugin To The WordPress.org Repository

Many WordPress plugins are developed on GitHub using Git. WordPress.org, however, uses Subversion (SVN) to manage changes to its codebase. Unfortunately, because SVN is not used by most plugin developers day-to-day, it has resulted in many hours spent navigating SVN and developers writing and running their own ad-hoc processes to deploy plugins to WordPress.org.

This obstacle was the perfect opportunity for us to explore innovative applications of GitHub Actions, and provide a tool that makes it much simpler for developers to deploy plugins to WordPress.org so they no longer have to learn or remember how to use SVN.

Our first Action, WordPress Plugin Deploy, publishes your WordPress plugin updates to the official WordPress plugin repository when you tag a new release.

Whenever you tag a new version of your plugin on GitHub, whether by command line or using GitHub releases, your changes will be committed to both trunk and the appropriate tags subfolder in your WordPress.org plugin’s repository.

This Action commits the contents of your Git tag to the WordPress.org plugin repository using the same tag name, removing a `v` prefix if present. It can exclude files as defined in either .distignore or .gitattributes, and moves anything from a .wordpress-org subdirectory to the top-level assets directory in SVN (plugin banners, icons, and screenshots).

10up already uses this GitHub Action to deploy:

If you want to use this Action, you’ll need to add a workflow file to the .github/workflows directory in the root of your plugin repository. It is a plain text configuration file that defines the workflow steps and references our Action in the WordPress Plugin Deploy step. A sample workflow file is available in our repository to help you get started.

Github Actions

Deploying Plugin Readme/Asset Updates To The WordPress.org Repository

WordPress plugin developers often need to deploy minor updates to the repository between new plugin releases, such as updating the “Tested Up To” version number or updating screenshots. Until now, developers were required to go into SVN and perform the updates manually or consider tagging the update as a new release.

Our second Action, WordPress.org Plugin Readme/Assets Update, updates assets between plugin releases, like bumping the version number or updating screenshots.

This Action commits any readme and WordPress.org-specific assets changes in a specified branch to the WordPress.org plugin repository only if no other changes have been made since the last deployment to WordPress.org. It also handles committing the changes to the stable tag, as that is what WordPress.org uses to display plugin information. This makes it easier for plugin developers to update information separately from functional changes, provided the Git branching methodology avoids changing anything else in that branch between functional releases. In a typical Git workflow, we recommend committing those changes directly to master and merging back into develop from there.

Streamlining Workflows With GitHub Actions

Adding our WordPress GitHub Actions to your plugin development workflow removes duplicative efforts across GitHub and WordPress.org and automates and streamlines deployment processes, saving valuable time and resources, and ensuring synchronicity. For a development team, it also enhances security and reduces concern related to who has commit access for team-managed plugins on WordPress.org.

Looking To The Future

As we look to the future, our focus is turning to existing workflows and Actions that demonstrate the creative potential to stretch GitHub Actions in innovative ways.

For example, for our Distributor plugin, we’re using a workflow that leverages a build process and GitHub Pages Deploy to automatically generate developer documentation based on code comments in the repository. This means we no longer need to dedicate resources to keeping public hook documentation up to date. The workflow reads through the code, identifies the comments, generates documentation on the plugin’s hooks (actions and filters), and deploys it to GitHub Pages to create a built-in documentation site.

If you document the hooks in your WordPress project using the JSDoc standard, you can use our step-by-step guide to implement the same workflow for your WordPress plugin.

10up aims to make a better web with finely crafted websites, innovative tools for content creators, and open-source contributions that drive growth—it’s not just good citizenship: it’s good business. If you want to be part of a company that is solving challenging problems, working on exciting open-source projects, and building interesting tools, come work with us.

  1. Really great work. Props to you for putting the time into creating these and sharing with the community. I’m already using your actions to deploy our plugins to .org and it works a treat.

    Re: the Github Pages Deploy action, you said:

    The workflow reads through the code, identifies the comments, generates documentation on the plugin’s hooks (actions and filters), and deploys it to GitHub Pages to create a built-in documentation site.


    What? Seriously?!! If you have any more info on this I’d be very keen to hear. It would be a game changer for us to generate this stuff automatically.

    Thanks again…

  2. Great work! Any plans to implement support for build with Composer/NPM/Yarn etc. during deployment? Might be able to solve this with different actions, but would def. be handy to keep everything in one action.

    • Hi! I would recommend using separate steps in your workflow file for any builds, as these actions are meant to stay relatively unopinionated and focused rather than dictating the development process and tooling for everybody’s plugins. The sample workflow file shows an `npm build` step running before the deployment, and there is support for `.distignore` specifically for the case of built files that are excluded from version control but do need to be deployed.

      Is there a particular hurdle you’ve come across that makes you lean toward wanting everything in a single action?

Leave a Comment

Finely crafted websites & tools that make the web better.