Deploying Your WordPress Plugin’s “Tested Up To” Version Bump in Isolation

Keeping the “Tested Up To” version of your WordPress plugin up-to-date on WordPress.org is crucial for ensuring compatibility and giving your users confidence. However, the process of manually updating this information can be a bit tedious, often involving a new release even if no other code changes are necessary.

While there are existing GitHub Actions that can deploy plugin assets to WordPress.org, such as the excellent 10up/action-wordpress-plugin-asset-update, using them solely for updating the “Tested Up To” version without any customization can be less than ideal. You might inadvertently deploy other changes you’ve made to your readme.txt file or other assets, even if those weren’t intended for immediate release. This could lead to unexpected updates on the plugin directory.

Imagine you implemented a new plugin feature in your GitHub repository which is not released yet, and you’ve already included documentation about it in the readme.txt. You wouldn’t want that to be deployed by accident when all you want to do is bump the “Tested Up To” version.

This post highlights a targeted GitHub workflow for exactly this purpose, which allows you to automate the deployment of bumping your WordPress plugin’s “Tested Up To” version in isolation.

A More Targeted Approach: Updating Only the “Tested Up To” Version

To address this specific need, we need a more targeted solution – one that would update only the “Tested Up To” line in the readme.txt file on WordPress.org, directly from GitHub, without the risk of deploying any other unintended changes. This should also happen without needing to push a full new release of the plugin.

We can still use 10up/action-wordpress-plugin-asset-update for that workflow, but with some additional tweaks in place.

The initial implementation of such a workflow was developed in a pull request for the Performance Lab project – huge props to Shyamsundar Gadde for leading that effort. However, given that Performance Lab is a monorepo, that workflow included some specific logic that wouldn’t be necessary for most standalone WordPress plugin repositories.

Simplified for Your Plugin: Introducing the bump-tested-up-to-dotorg.yml Workflow

To make this more accessible for everyone, I’ve simplified the workflow for standard WordPress plugin repositories.

The core of this workflow is that it checks out the exact readme.txt file that is currently live on WordPress.org. It then proceeds to update only the “Tested Up To” entry within that file to reflect the WordPress version specified in your GitHub branch (typically the trunk or main branch).

The full workflow steps are:

1. Check out the GitHub repository (as always).
2. Manually download the latest readme.txt file currently used for your WordPress.org plugin repository.
3. Extract the “Tested Up To” version from the GitHub repository’s readme.txt.
4. Copy the downloaded readme.txt to override the GitHub repository’s readme.txt in the local checkout, then update the “Tested Up To” value with the version determined in the previous step.
5. Deploy the modified readme.txt (with just the version change) using 10up/action-wordpress-plugin-asset-update, while ensuring no other possibly modified files are being deployed.
   • Note: No extra check is needed in the workflow for whether the deployment is needed, even if the GitHub repository’s “Tested Up To” version is the same as the one that is already in the WordPress.org repository. That is because the action will automatically skip the deployment if there are no changes.

Here is the complete workflow file for reference:

name: Bump Tested up to on WordPress.org

on:
    workflow_dispatch:

jobs:
    bump-tested-up-to:
        name: Bump "Tested up to" version
        runs-on: ubuntu-latest
        steps:
            - name: Checkout code
              uses: actions/checkout@v4

            - name: Download WordPress.org readme
              env:
                  SLUG: ${{ github.event.repository.name }}
              run: |
                  # Download the current readme.txt from WordPress.org
                  curl -sSL --retry 3 --retry-delay 5 --retry-all-errors --fail -o /tmp/wp-org-readme.txt "https://plugins.svn.wordpress.org/$SLUG/trunk/readme.txt"
                  if [ $? -ne 0 ]; then
                    echo "::error::Could not fetch readme.txt from WordPress.org for $SLUG"
                    exit 1
                  fi

            - name: Extract local "Tested up to" version
              id: extract-tested-up-to
              run: |
                  LOCAL_TESTED_UP_TO=$(grep -E "^Tested up to:" "./readme.txt" | awk -F ': +' '{print $2}')
                  if [ -z "$LOCAL_TESTED_UP_TO" ]; then
                    echo "::error::Unable to parse local Tested up to version from readme.txt"
                    exit 1
                  fi

                  echo "version=$LOCAL_TESTED_UP_TO" >> $GITHUB_OUTPUT

            - name: Prepare and update readme.txt
              env:
                  LOCAL_TESTED_UP_TO: ${{ steps.extract-tested-up-to.outputs.version }}
              run: |
                  # Replace local readme.txt with WordPress.org version, updating only the "Tested up to" line.
                  cp /tmp/wp-org-readme.txt "./readme.txt"
                  sed -i -E 's/^(Tested up to:[[:space:]]*).+/\1'"$LOCAL_TESTED_UP_TO"'/' "./readme.txt"

                  # Show the diff of what's being updated.
                  # If there is no change, the following deployment step will simply bail, so we don't need to worry about it.
                  echo "Changes made to readme.txt:"
                  diff -u /tmp/wp-org-readme.txt "./readme.txt" || true

            - name: Deploy readme.txt to WordPress.org
              uses: 10up/action-wordpress-plugin-asset-update@stable
              env:
                  SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
                  SVN_USERNAME: ${{ secrets.SVN_USERNAME }}
                  SLUG: ${{ github.event.repository.name }}
                  SKIP_ASSETS: true
                  IGNORE_OTHER_FILES: trueCode language: YAML (yaml)

I’m already using this in my AI Services plugin, and you can see the workflow in action here: https://github.com/felixarntz/ai-services/blob/main/.github/workflows/bump-tested-up-to-dotorg.yml.

Easy to Adopt: Just Copy and Paste

The code for this workflow is entirely self-contained and not tied to the AI Services plugin in any way. You can simply copy and paste the contents of the bump-tested-up-to-dotorg.yml file from above or from the AI Services repository into your own WordPress plugin’s GitHub repository (under .github/workflows/).

To use the workflow, you can simply dispatch it manually whenever you want to bump the “Tested Up To” version, by navigating to https://github.com/USERNAME/REPOSITORY/actions/workflows/bump-tested-up-to-dotorg.yml and selecting “Run workflow”.

By using this GitHub workflow, you can ensure that your plugin’s “Tested Up To” version is always current without the need for a full release cycle or the risk of accidentally deploying other changes. This is a small automation that can save you time and potential headaches.

I hope you find this workflow useful for your own WordPress plugin maintenance! Feel free to take a look at the implementation and use it in your own plugin as is, or adapt it to your needs. If you have any feedback or suggestions for improvement, I’d love to hear them.