Release management: automate deployment of tags to SVN

[jeherve]

As we're starting to release more and more often, and more and more plugins, I believe one of the manual steps of our release process could be automated.

• Folks on other teams aren't always familiar with SVN and the intricacies of deploying a plugin update to WordPress.org.
• We already have quite a few checks in place before a release is published on GitHub in the mirror repo.
• Until our monorepo repo, there were still some big differences between the tag we created on GitHub and the code that eventually was tagged in SVN; since we started working with mirror repos and tagging releases there, the code that is tagged is really production-ready.

Deployment to SVN typically includes 5 main steps:

1. Push the changes to trunk
2. Create a new directory for the tag in tags/
3. Update the stable tag in tags/x.x/readme.txt
4. When and if a release has to be made available to the general public, update the stable tag in trunk/readme.txt
5. Clean up old beta tags from tags/

I think we could reasonably aim to automate parts of that process. One part we won't want to automate just yet is step 5. Update the stable tag in trunk, thus making a release available, should still be a manual step for now. One additional benefit of keeping this step manual is that it makes it clear who is in charge of a deployment / release, even if the initial tag deployment was done by an automated process (and thus stored credentials).

There is prior art we could use to get started with this:

• There are some actions like this one available: https://github.com/10up/action-wordpress-plugin-deploy
• We've done some work in-house for such deployments: see PCYsg-mMA-p2
• We already have a process in place to enable GitHub actions on specific mirror repos:

  jetpack/.github/files/build-all-projects.sh

  Lines 151 to 160 in a158349

  	# Copy autotagger, autorelease, and/or npmjs-autopublisher if enabled
  	if jq -e '.extra.autotagger // false' composer.json > /dev/null; then
  	cp -r "$BASE/.github/files/gh-autotagger/." "$BUILD_DIR/.github/."
  	fi
  	if jq -e '.extra.autorelease // false' composer.json > /dev/null; then
  	cp -r "$BASE/.github/files/gh-autorelease/." "$BUILD_DIR/.github/."
  	fi
  	if jq -e '.extra["npmjs-autopublish"] // false' composer.json > /dev/null; then
  	cp -r "$BASE/.github/files/gh-npmjs-autopublisher/." "$BUILD_DIR/.github/."
  	fi

I think a good first candidate for this process could be the Jetpack plugin, since we now release weekly. We could then expand this to our other standalone plugins with a matching W.org plugin.

cc @kraftbj and @anomiex, since we've talked about this in the past.

---

References:

• p9dueE-3ca-p2

[anomiex]

The main question that always comes up when this is proposed is whether WordPress.org will allow us to automate the commits from a "bot" account of some sort, versus having to have a human put their SVN credentials into the GitHub secrets.

[jeherve]

whether WordPress.org will allow us to automate the commits from a "bot" account of some sort, versus having to have a human put their SVN credentials into the GitHub secrets.

I can reach out to the Plugins team about this. That said, the action I referenced above already pushed other plugin authors to switch to commits by a shared account. Here are some examples, including the Gutenberg plugin. To add to that, I think that having a personal account switching the stable version each time may help with this too, since we'll know each time who is handling that release.