Automatic PRs for new ClassicPress and WordPress versions

[nylen]

We should set up a bot to make new PRs to this repository when new ClassicPress or WordPress versions are released, to enable the new version for the migration plugin.

There are 2 cases to handle:

New ClassicPress version addressed in #38

The ClassicPress migration plugin needs to use a ClassicPress build with a different structure, because WordPress can only do an upgrade from a zip file that contains a single folder named wordpress. (Some history and links at ClassicPress/ClassicPress#148.)

To avoid an extra manual step in the release process, we generate these migration builds along with the nightly builds: https://github.com/ClassyBot/ClassicPress-nightly/releases

A new nightly build is released every day shortly after midnight UTC.

We need to create a PR against this repository every time the nightly build changes to a new base version number, indicating that a release has been done. Here is an example of such a commit: 348751d

New WordPress version

An initial attempt at this was made in #36 and #38 but it needs more work before being committed, see 9a480d6 for more info.

When a new version of WordPress is released this also needs to be tested manually (because a new WP version could break the migration process) and then enabled.

An automated PR could be created for this too, though again it needs to be tested carefully before being merged.

Here are two examples of such commits, they should look a bit different depending on whether it was a major or a minor version of WordPress that was released:

• 44e4315
• 02a9a5f

[mattyrob]

I've been experimenting with bash scripting and regex and have the following as a potential starting point to fix the 3 issues raised about the last attempted code, specifically these issues were:

• The current substitution command will lead to invalid replacements
  over time since it isn't limited to the specific place in the file that
  should be edited.
• The 'other' versions array indicating which beta/RC releases of
  WordPress should be allowed is not updated.
• This action probably does not correctly handle "5.9" vs "5.9.0" in
  major WP versions.

The code below hopefully makes the substitution more specific, it handles the 'other' versions more specifically and it also handles the WP release versioning better. It may well be clunky and I expected more improvements can be made but posting here so there is a record and starting point.

name: Check for WordPress release

 on:
   schedule:
     - cron: '0 1 * * *'

 jobs:
   release-check:
     runs-on: ubuntu-latest
     steps:
       - name: Check release repository
         run: |
           echo "Collect and process json"
           RELEASE_DATA=$(wget -cq "https://api.wordpress.org/core/version-check/1.7/" -O - | jq --compact-output '.[] | limit( 1; .[] ) | {current}')
           CURRENT_DATA=$(echo ${RELEASE_DATA} | grep -Eo -m1 '[[:digit:]]+\.[[:digit:]]+\.?[[:digit:]]*')
           echo "current_version=${CURRENT_VERSION}" >> $GITHUB_ENV
       - name: Checkout repository
         uses: actions/checkout@v2
       - name: Compare to Repository
         run: |
           MAX_WP_VERSION=$(grep -Eo -m1 "'max'\s*=>\s'([[:digit:]]\.[[:digit:]]\.?[[:digit:]]*)'" ./v1/migration/index.php)
           echo ${MAX_WP_VERSION} > ./max_wp_version.txt
           WP_VERSION=$(echo "${MAX_WP_VERSION}" | grep -Eo -m1 '[[:digit:]]\.[[:digit:]]\.?[[:digit:]]*')
           if [ ${{ env.current_version }} != ${WP_VERSION} ]; then
             sed -i "s|${WP_VERSION}|${{ env.current_version}}|" ./max_wp_version.txt
             NEW_WP_VERSION=$(cat ./max_wp_version.txt)
             sed -i "s|${MAX_WP_VERSION}|${NEW_WP_VERSION}|" ./v1/migration/index.php
             PARTS=(`echo ${{ env.current_version}} | tr '.' ' '`)
             if [ -z $PARTS[3] ]; then
               NEW_PATCH_RELEASE=$(echo ${PARTS[1]}.${PARTS[2]}.1)
             else
               NEW_PATCH_RELEASE=$(echo ${PARTS[1]}.${PARTS[2]}.$(( ${PARTS[3]} + 1 )))
             fi
             if [ 9 = ${PARTS[2]} ]; then
               NEW_RELEASE=$(echo $(( ${PARTS[1]} + 1 )).0)
             else
               NEW_RELEASE=$(echo ${PARTS[1]}.$(( ${PARTS[2]} + 1 )))
             fi
             PATCH_RC_VERSION=$(grep -Eo -m1 "(#\^[[:digit:]]+\\\.[[:digit:]]+\\\.[[:digit:]]+)-\(alpha" ./v1/migration/index.php)
             RC_VERSION=$(grep -Eo -m1 "(#\^[[:digit:]]+\\\.[[:digit:]]+)-\(alpha" ./v1/migration/index.php)
             sed -i "s|${PATCH_RC_VERSION}|${NEW_PATCH_RELEASE}|" ./v1/migration/index.php
             sed -i "s|${RC_VERSION}|${NEW_RELEASE}|" ./v1/migration/index.php
       - name: Create Pull Request
         id: createpr
         uses: peter-evans/create-pull-request@v3
         with:
           committer: GitHub <noreply@github.com>
           author: ${{ github.actor }} <${{ github.actor }}@users.noreply.github.com>
           branch: release/${{ env.current_version }}
           commit-message: Update API for new WordPressPress Release
           title: Update API for ${{ env.current_version }} release
           body: |
             Update API Endpoint
             - Update endpoint to release ${{ env.current_version }}
             - Update release date to ${{ env.release_date }}

[bahiirwa]

@mattyrob is there a place for us to test this?

[mattyrob]

@bahiirwa It is possible to test step wise in in Linux command line. With higher confidence in what we have we can create and tweak the workflow later if needed.