Automatically add new WP versions to supported version matrix

[kadamwhite]

We should set up a periodic action to check for new versions of WordPress, and make sure that the container for this tester utility can be used with those versions. This will ensure that we can always point our tests at the most recent WordPress version.

This related scheduled action can be used as a guide for how we can implement this:

Example GH Action to update WP-CLI dependency each week

name: Update WP-CLI

on:
  workflow_dispatch:
  schedule:
    - cron: "0 0 * * 1" # Every Monday at midnight

jobs:
  update-wp-cli:
    name: Update WP-CLI
    if: github.repository == ${{ github.event.repository.full_name }}
    permissions:
      contents: write
      pull-requests: write
    runs-on: ubuntu-latest
    steps:
      - name: Check out source code
        uses: actions/checkout@v4

      - name: Get latest WP-CLI version
        id: latest
        run: |
          LATEST=$(curl -s https://api.github.com/repos/wp-cli/wp-cli/releases/latest | jq -r '.tag_name' | sed 's/^v//')
          echo "version=${LATEST}" >> "$GITHUB_OUTPUT"

      - name: Update WP-CLI version in Dockerfile
        run: |
          sed -i "s/WP_CLI_VERSION=[0-9]\+\.[0-9]\+\.[0-9]\+/WP_CLI_VERSION=${{ steps.latest.outputs.version }}/g" Dockerfile

      - name: Create pull request
        uses: peter-evans/create-pull-request@v7
        with:
          branch: update-wp-cli
          commit-message: "Update WP-CLI to v${{ steps.latest.outputs.version }}"
          title: "Update WP-CLI to v${{ steps.latest.outputs.version }}"
          body: "Automated update of WP-CLI to the latest release."
          base: master
          # Edit this list when supported version branches change.
          labels: |
            dependencies
            backport v8.2-branch
            backport v8.3-branch
            backport v8.4-branch
            backport v8.5-branch
          signoff: true
          delete-branch: true

Notes: Use latest versions of relevant GH actions; and, we don't need the backport branches in our case, I believe.

This updates a constant in a file to point to the most recent WP-CLI version, so that a container built from the repo where this action is taken from will always have the latest WP-CLI available. We can leverage it as inspiration for how to schedule the check, and how to quickly test for / identify the latest version available via the GH API.

We can check for recent WordPress versions using the https://github.com/wordpress/wordpress repository, tags like 7.0, 6.0.12, etcetera track the latest versions.

We do not need to specify the patch version, only the minor release version.

Open questions: is there a good way to add support for testing against PRERELEASE versions, for beta validation?