Implement GitHub workflow to build and deploy standalone plugins

[felixarntz]

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.

[joemcgill]

Suggestions for the requirements:

• This workflow should be part of a release process, not a merge, so it should only run when a new release tag is added
• Only modules with changes since the last release should be deployed
• We'll need a process by which we bump version numbers on each individual plugin as part of the development process. Perhaps that could happen in the build process in Implement CLI command to for a build process to transform modules into standalone plugins #635

[felixarntz]

@joemcgill I agree with your first point. The other two points, which are related, we may want to further discuss on #635 where this is currently being covered by the proposed requirements.

For some context, I am proposing the following:

• Always have the versions of PL plugin and all standalone plugins in sync.
• Drawback: Some standalone plugin releases may not come with any actual changes.
• Benefit: Much easier to manage for us, and easier for anyone to keep track of which version is the latest for the individual plugins (since they'd all be the same).

To me, I don't consider the drawback relevant enough to "fix". Is there any real problem by triggering an update (not more than once a month anyway) without actual changes?

[mukeshpanchal27]

@joemcgill @felixarntz I have an open PR in which I use the 10up Deploy action. Can you please review it and share your feedback.

There is already a plugin called Dominant Color hosted on wp.org with the same slug as the PL module, so there may be a conflict in the future when we run the script for dominant-color module. 

[felixarntz]

@joemcgill @felixarntz I have an open PR in which I use the 10up Deploy action. Can you please review it and share your feedback.

Thanks @mukeshpanchal27! I'm not very familiar with GH Actions, so I'd appreciate if @spacedmonkey could give this a first review.

There is already a plugin called Dominant Color hosted on wp.org with the same slug as the PL module, so there may be a conflict in the future when we run the script for dominant-color module.

Good catch! We can't just take that over, so how do we want to name our plugin? Maybe dominant-color-feature? WDYT @mukeshpanchal27 @joemcgill @spacedmonkey?

[joemcgill]

What about dominant-color-images or some thing more descriptive?

[mukeshpanchal27]

What about dominant-color-images

LGTM. @felixarntz WDYT?

Once the name is finalised, we have to open PR for those changes before #640 to start.

[felixarntz]

@joemcgill @mukeshpanchal27 Sorry for the delayed reply here, dominant-color-images sounds great to me. We should then also rename the module title accordingly.

[mukeshpanchal27]

Closed in #686