As WordPress plugin developers, we all strive to deliver timely updates and new features to our users. Manually deploying these updates can be a tedious and error-prone process. This post outlines a robust and efficient workflow utilizing GitHub Actions to automate your WordPress plugin deployments.

This guide is based on a real-world example, leveraging the deploy.yml workflow file from the rearrange-woocommerce-products plugin.

Why Automate?

Automating your deployment process offers several key benefits:

• Consistency: Ensures every deployment follows the same steps, reducing human error.
• Speed: Drastically cuts down the time it takes to release updates.
• Reliability: Minimizes the chances of broken releases due to missed steps.
• Focus: Frees up your time to focus on development, not deployment logistics.

The Core: GitHub Actions Workflow

Our automation hinges on a GitHub Actions workflow. Let’s break down the essential components of the deploy.yml file (you can view the full file here):

(Assuming you have a similar deploy.yml file)

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

Explanation:

• name: Deploy to WordPress.org: A human-readable name for your workflow.
• on: push: tags: - '*': This is crucial. The workflow is triggered only when a new tag is pushed to your repository. This ensures that a release is explicitly initiated by you, giving you control over when deployments happen. The * signifies that any new tag will trigger the workflow.
• jobs: deploy: Defines a single job named deploy.
• runs-on: ubuntu-latest: Specifies that the job will run on the latest Ubuntu environment.
• steps:: A sequence of tasks to be executed.
  • - uses: actions/checkout@v4: This standard action checks out your repository’s code, making it available to subsequent steps.
  • - name: WordPress.org Plugin Deploy: A descriptive name for the deployment step.
  • uses: 10up/action-wordpress-plugin-deploy@stable: This leverages an excellent community-maintained GitHub Action specifically designed for deploying WordPress plugins to WordPress.org. It handles the complexities of SVN interaction.
  • env:: This section defines environment variables required by the deployment action.
    • SVN_USERNAME: ${{ secrets.SVN_USERNAME }}: Your WordPress.org SVN username. Crucially, this is stored as a GitHub Secret. Never hardcode sensitive credentials directly in your workflow file.
    • SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}: Your WordPress.org SVN password, also stored as a GitHub Secret.

Setting Up GitHub Secrets

Before you can use this workflow, you need to set up your SVN credentials as GitHub Secrets:

1. Navigate to your GitHub repository.
2. Click on Settings.
3. In the left sidebar, click on Secrets and variables > Actions.
4. Click on New repository secret.
5. Create two secrets:
   • SVN_USERNAME with your WordPress.org username as the value.
   • SVN_PASSWORD with your WordPress.org password as the value.

Your Deployment Workflow in Action

Here’s the streamlined process for releasing a new version of your plugin:

1. Prepare Your Changes

First, make sure your local repository is clean and ready for a new release.

git add .
git commit -m "Prepare release v1.2.3" # Use a descriptive message

2. Tag Your Release

This is the most critical step for triggering the automated deployment. Replace 1.2.3 with your actual new version number.

git tag 1.2.3

3. Push Your Tag

Pushing the tag to your remote GitHub repository will initiate the workflow.

git push origin 1.2.3

4. Keep Your Main Branch Up-to-Date (Optional but Recommended)

While pushing the tag won’t trigger the deploy workflow again on your main branch, it’s good practice to ensure your main branch is in sync with your latest changes.

git push

This command pushes any committed changes on your current branch to origin/main (assuming you are on main). This push will not re-run the deploy workflow because the workflow is specifically configured to run only on tag pushes.

Manually Rerunning a Deployment

Sometimes, you might need to re-run a deployment for a specific tag (e.g., if a previous run failed due to a temporary issue).

Option A: GitHub UI (If available)

Often, if a workflow run fails or is cancelled, GitHub provides a “Re-run jobs” option directly on the workflow run page. This is the simplest method if available.

Option B: Delete and Re-push the Tag

If the re-run option isn’t suitable or available, you can force a re-run by deleting and re-pushing the same tag. This tricks GitHub into thinking it’s a “new” tag push.

# Delete the tag locally
git tag -d 1.2.3 # Replace with your current tag
# Delete the tag on GitHub
git push origin :refs/tags/1.2.3 # Replace with your current tag
# Create the tag again
git tag 1.2.3 # Replace with your current tag
# Push the tag again
git push origin 1.2.3 # Replace with your current tag

Important Considerations:

• Version Numbering: Ensure your readme.txt (or readme.md for some setups) in your plugin directory has the correct Stable tag: and Version: set to your new version number before tagging. The deployment action often relies on this.
• Plugin Assets: Make sure your assets folder (if you use one for screenshots, banners, etc.) is correctly structured for WordPress.org.
• Testing: Always test your plugin thoroughly before releasing a new version, even with an automated deployment.

Conclusion

By implementing this GitHub Actions workflow, you can significantly streamline your WordPress plugin update process, making it faster, more reliable, and less prone to human error. This allows you to focus on what you do best: building amazing WordPress plugins!

Happy deploying!