Configure DRY_RUN to Github Action

[mukeshpanchal27]

Bug Description

Follow-up issue for #710 (comment)

The 10up deploy action officially support DRY_RUN mode that can be used while testing this action.

- name: WordPress Plugin Deploy
      uses: 10up/action-wordpress-plugin-deploy@stable
      with:
        dry-run: true

[mukeshpanchal27]

We have two option here to configure DRY_RUN.

Option 1
Add dry-run: true in the GitHub action configuration, which will enable it to run in both automated and manual actions. Please refer to the issue description for instructions on how to implement this.

Option 2 (Suggest by @joemcgill)
If we only want to use it for testing purposes and limit it to manual workflows, we can add a new boolean-type input option for workflow_dispatch.

i.e.

dry-run:
   type: boolean
   description: 'True to set debug mode'

@felixarntz and @joemcgill, I would appreciate your feedback on this. Thank you!

[felixarntz]

@mukeshpanchal27 @joemcgill Could we alternatively set a dry-run default based on certain criteria? I'm thinking something like:

• If the workflow is run in a PR / branch other than trunk, set dry-run to true by default.
• If the workflow is run in the trunk branch, set dry-run to false by default.

[joemcgill]

@mukeshpanchal27 I'm not sure I understand what you're proposing with Option 1. If we update the configuration with dry-run: true, then we would need to edit that file every time we want to perform an actual release in order to set dry-run to false.

@felixarntz:

Could we alternatively set a dry-run default based on certain criteria?

That's an interesting idea. Currently, there are two workflows that deploy plugins to the plugin repo:

1. Deploy to WordPress.org – Deploys the Performance Lab plugin only when a GitHub release is published (i.e. the common workflow for the 10up/action-wordpress-plugin-deploy action).
2. Deploy standalone plugins to WordPress.org – Deploys all of the standalone plugins that are developed in the mono-repo (e.g., modules). This workflow also always runs when a Performance Lab release is published. It can also be triggered manually with the workflow_dispatch event to publish specific plugins.

For both workflows, we could run the workflow when a release is drafted but not yet published and set dry-run to true if the release is not published, e.g.:

  release:
    types: [published, created]

For the Deploy standalone plugins workflow, when triggered by manual workflow_dispatch events, automatically setting the dry-run value based on the selected branch would be a nice safeguard. I also think having a checkbox for dry run on the UI that shows on that workflow would be a nice touch. See screenshot of the current UI shown by GitHub for triggering the manual standalone releases:

[mukeshpanchal27]

Thank you, @felixarntz and @joemcgill, for sharing your thoughts.

In my opinion, I believe there is no need to make any changes to the Performance Lab release action (Deploy to WordPress.org) because we do not want to check the DRY_RUN option for that particular action.

However, for the Deploy standalone plugins workflow, instead of configuring the DRY_RUN option, I suggest adding a checkbox for a manual workflow_dispatch. This will allow us to perform a DRY_RUN manually, specifically for the initial release of the standalone plugin, and we can accomplish this through a manual workflow. Additionally, the 10up deploy action has already been fixed to prevent the re-publishing of the same version of a plugin, so it will never override the same version.

Let me know if you have any further questions or concerns.

[joemcgill]

That plan works for me. We can always add support for dry run on drafted releases in a separate PR.