Feature Description

Follow up to #635, #636, and #637: Once the CLI command from that issue has been implemented, we should use this issue to implement a new GitHub workflow like deploy-standalone-plugins.yml which uses the CLI command to build the plugins and then deploys them individually to their respective WordPress.org plugin repository folder.

Requirements

• A new GitHub workflow .deploy-plugins.yml should be implemented, for now to deploy modules as standalone plugins to the WordPress plugin repository.
  • It should use the build-plugins script from Implement CLI command to for a build process to transform modules into standalone plugins #635 to transform certain modules (based on the plugins.json file) to standalone plugins.
  • It should then check out the individual SVN repositories for those plugins from the plugins.json file, and for each plugin replace the current trunk folder content with the newly built plugin.
  • From there on, it should only proceed for each plugin if the version in the plugin's main file and the plugin's readme.txt file matches and is greater than the version that was previously in those files. (The only exception is if this is the initial release, i.e. there was no version before.) If so, the next steps for each plugin are:
    • Copy the trunk folder to a new tags/$version folder.
    • SVN-add / SVN-delete any files as needed based on svn status.
    • Commit the new code.
  • A lot of the above logic can probably be based on the code from https://github.com/10up/action-wordpress-plugin-deploy - however we cannot use that GitHub action directly here since it is intended to work only for one plugin in one repository (while we have a monorepo here). Another potentially useful resource for some of the logic needed could be https://github.com/Automattic/jetpack/tree/trunk/.github.
  • Let's implement scripts (e.g. .sh or .js) as needed - it's probably not a good idea to bake all of this logic directly into a GitHub workflow YAML file, as that would get overly complicated.
  • For triggering this workflow, as a starting point we can probably set it to only run when a new Performance Lab plugin release is made, i.e. this would also trigger a new release of any standalone plugins if their versions were intentionally increased. We can always enhance this later if we e.g. also need to trigger manual releases for those plugins. Note that in the future, once the standalone plugins are no longer part of the PL plugin, the trigger will have to be changed anyway, so this is just a temporary measure.