Published

The WordPress.org plugin repository still uses Subversion in 2020, and a lot of developers have been frustrated about this for many years already. Most developers use git as their daily source control versioning system, and going back to running svn commands feels like a step back in time to a previous decade. This is kind of true, since Subversion was popular in the 2000’s but has been in a steady decline since and git has been the industry standard at least since early 2010’s. Git is far superior to svn in features and speed, so no wonder developers dislike having to use something inferior after learning about git.

Due to legacy reasons, WordPress.org has not yet migrated to git, and it might take several years more to do so. At the moment developers are stuck inventing creative ways not to have to use svn and instead keep their plugin code in git and use different tools to automatically sync from git (for example on Github) to svn (on WordPress.org).

Deprecating deployer.seravo.com

Seravo announced in late 2017 a service to enable WordPress plugin developers to host their code in git on Github.com and automatically sync that to WordPress.org without developers having to run any svn commands themselves. The service was built and run in collaboration with Arūnas Liuiza, who presented about it in WordCamp Jyväskylä in February 2019.

At its peak over 250 plugins were synced by deployer.seravo.com from Github to the WordPress plugin repository, but we have not done any further development on it. As of today no more bugfixes will be done and deployer.seravo.com will be completely shut down and stop working on October 1st 2020.

Use Github Actions to sync to plugins.wordpress.org

Github.com introduced in late 2019 a new feature called Github Actions, which is their take on a CI/CD system. This can be used to achieve the same thing deployer.seravo.com did, so we recommend migrating to it using the Github Actions presented below.

For Github Actions to work, two things are needed: scripts in .github/workflows that are run automatically by Github on every git push, and credentials to access svn.wordpress.org.

Add Github actions for plugin releases and readme updates

There is no need to constantly sync to plugins.wordpress.org. It is relevant only on two occasions: when there is a new release that needs to be available to users, or when the plugin metadata such as the readme.txt updates.

New releases are done in this scheme simply by tagging a new version in git. Add this to .github/workflows/wp-release-on-tag.yml that will run on every tag to publish the tagged code on plugins.wordpress.org (uses action by 10up):

name: Deploy to WordPress.org
on:
  push:
    tags:
    - "*"
jobs:
  tag:
    name: New tag
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - name: WordPress Plugin Deploy
      uses: 10up/action-wordpress-plugin-deploy@master
      env:
        SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
        SVN_USERNAME: seravo

Remember to update SVN_USERNAME to match yours!

Metadata updates don’t depend on tags, but only if the relevant metadata files have been updated or not. For metadata to be updated add this as .github/workflows/wp-sync-assets.yml (uses action by 10up):

name: Plugin asset/readme update
on:
  push:
    branches:
    - master
jobs:
  master:
    name: Push to master
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - name: WordPress.org plugin asset/readme update
      uses: seravo/action-wordpress-plugin-asset-update@master
      env:
        SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
        SVN_USERNAME: seravo

If the Git repository name is not the same as the plugin name on WordPress.org, the plugin name must be defined in an environmental variable SLUG by adding a new row to both of the .yml files:

...  
env:
    SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
    SVN_USERNAME: seravo
    SLUG: plugin-name-on-wordpress-org

Those who used the Seravo Deployer had their assets on a separate branch called assets. For this Github Action to work, the contents of that branch needs to be merged on the main branch. It can be achieved with:

git checkout assets
mkdir .wordpress-org
git mv * .wordpress-org/
git commit -am "Move assets to separate directory in before merge in master branch"
git push
git checkout master
git pull origin assets --allow-unrelated-histories
git push

Store SVN_PASSWORD in Github Secrets

You can use your existing personal credentials, or create a separate machine account on wordpress.org for the purpose. Define the username in the action yml file. Since the password is sensitive, it naturally cannot be visible in the code repository, and therefore it needs to be added to Github Secrets as the variable SVN_PASSWORD, which can then be seen by the Github Action when it runs but otherwise it stays secret. Define this in your repository Settings under Secrets.

Github Secrets
Define SVN_PASSWORD in Github Secrets

If you have everything done correctly, you should see Github Actions in action!

Github Actions running
Github Actions running

Examples in action

To see examples in action, check out for example: