Perform dry run of WebP Uploads release workflow

[felixarntz]

As we would like to publish a first version of the WebP Uploads standalone plugin tomorrow, following #699 we should perform a dry run of the corresponding GitHub workflow.

Once it has been successfully completed, the last step before the actual release is to make the last follow up changes to #686, e.g. using the actual 10up deploy action instead of the custom deploy.sh copy and relying on the proper SVN credentials via GitHub secrets.

[joemcgill]

I've completed a dry run of the release process for tomorrow, and everything looks to have worked as expected. Review the log from the dry run.

Specifically, it looks like all the files that were built by the build process were correctly staged for commit (copied below)

A  +    tags/1.0.0-RC1
A       tags/1.0.0-RC1/can-load.php
A       tags/1.0.0-RC1/fallback.js
A       tags/1.0.0-RC1/helper.php
A       tags/1.0.0-RC1/hooks.php
A       tags/1.0.0-RC1/image-edit.php
A       tags/1.0.0-RC1/load.php
A       tags/1.0.0-RC1/readme.txt
A       tags/1.0.0-RC1/rest-api.php
A       tags/1.0.0-RC1/settings.php
A       trunk/can-load.php
A       trunk/fallback.js
A       trunk/helper.php
A       trunk/hooks.php
A       trunk/image-edit.php
A       trunk/load.php
A       trunk/readme.txt
A       trunk/rest-api.php
A       trunk/settings.php

I also manually tested the built plugin locally along with the Performance Lab plugin and verified that there were no errors when both were installed together (our automated tests should catch this, but nice to confirm).

A couple of notes about the process...

1. Currently the manual workflow requires that you manually enter a plugin slug and a version number. For my dry run I used webp-uploads and 1.0.0-RC1, respectively, but we may want to simplify this in the future to avoid human error and force it to use a version number from the plugins.json file.
2. The names for each job could be improved to be a bit more readable. Instead of "New Release", it could read "Prepare Release" and then the second job could be "Deploy Release".
3. It looks like the way this is set up, we will end up running the deploy job once for each module in the plugins.json file, which means we will build all of the plugins for each plugin in the matrix even though we're only deploying individual plugins each time. This is fine for WebP Uploads, but something we could look into improving before deploying additional standalone plugins

I'll open a PR to handle the next steps that @felixarntz mentioned above:

Once it has been successfully completed, the last step before the actual release is to make the last follow up changes to #686, e.g. using the actual 10up deploy action instead of the custom deploy.sh copy and relying on the proper SVN credentials via GitHub secrets.

[felixarntz]

Thanks @joemcgill!

Currently the manual workflow requires that you manually enter a plugin slug and a version number. For my dry run I used webp-uploads and 1.0.0-RC1, respectively, but we may want to simplify this in the future to avoid human error and force it to use a version number from the plugins.json file.

+1, let's open a ticket to handle the version automatically, as it is part of plugins.json. For tomorrow, we should also make sure to pass the same version, we shouldn't use 1.0.0-RC1 if plugins.json has 1.0.0. What we deploy should always be aligned with that JSON file.

[felixarntz]

PR #701 approved! Let's merge it by tomorrow morning, so that it is in trunk before we do the actual deployment of WebP Uploads.

[mukeshpanchal27]

For tomorrow, we should also make sure to pass the same version, we shouldn't use 1.0.0-RC1 if plugins.json has 1.0.0. What we deploy should always be aligned with that JSON file.

+1 agree with you.