Release automation

[gabrielcld2]

Deployment process

This is what the production release process will look like from now on:

1. Prepare master branch

This is pretty much as before:

• prepare all changes in a PR against master
• this should also include the following:
  • updated version in both .version and package.json
  • updated readme.txt changelog
• merge the master PR

2 Create and publish GH release

This is also similar to what was done before:

• Go to the repository on GitHub → Releases → Draft a new release
  • Create a new tag (e.g. 3.3.4) targeting master
  • Set the release title and notes (copy and format the changelog from the readme.txt)
  • Publish as a standard release
  • Note: pre-release can be used to do a dry-run instead which will trigger the workflow but won't push to wp.org's SVN repository.

3. The GH workflow

Publishing the release will automatically trigger .github/workflows/deploy-to-wp-org.yml, which:

1. Runs the full CI suite to ensure the build isn't broken
2. Installs npm and Composer dependencies
3. Builds JS/CSS assets (npm run build)
4. Copies all plugin files into build/ and update version references (via grunt prepare)
5. Deploys to WP.org SVN via the 10up action — commits to trunk/, creates tags/<version>/, and updates assets/
6. Attaches a .zip of the plugin to the GitHub release

QA notes

• We can try triggering a dry-run by creating a pre-release in GH.

[PatelUtkarsh]

Left some suggestions but overall looks good!

[PatelUtkarsh]

💡 thought: This action is archived and deprecated by GitHub since 2021.

Should we migrate it to more active ones like:

- name: Upload release asset
  uses: softprops/action-gh-release@v2
  with:
    files: ${{ steps.deploy.outputs.zip-path }}

[gabrielcld2]

@PatelUtkarsh It seems that "softprops/action-gh-release" serves a different purpose from my understanding though, no? 🤔 It seems to be aimed at creating github releases, while here we're trying to upload assets to the manually created release https://github.com/softprops/action-gh-release

[utkarshcloudinary]

@gabrielcld2 Good question, but softprops/action-gh-release actually handles this case too 👍

When the workflow is triggered by a release event, the action does not create a new release - it detects the existing release for the current tag and updates it in place, uploading anything passed via files: as release assets. Creating releases is just one of its modes; attaching assets to an existing release is the most common usage and exactly what the (archived) actions/upload-release-asset did.

From their README (Uploading release assets):

"If a tag already has a GitHub release, the existing release will be updated with the release assets."

The migration would be a drop-in replacement:

# After the deployment, upload the zip to the existing GitHub release.
- name: Upload release asset
  uses: softprops/action-gh-release@v2
  with:
    files: ${{ steps.deploy.outputs.zip-path }}

No upload_url, asset_name, or asset_content_type plumbing needed — it infers all of that. The GITHUB_TOKEN env is also unnecessary (it uses the default token), though the job may need permissions: contents: write depending on the repo's default workflow permissions.

Two things to be aware of:

1. The asset will be named after the actual zip filename rather than ${{ github.event.repository.name }}.zip if keeping the old name matters, add a rename step before upload.
2. If the repo's default GITHUB_TOKEN permissions are read-only, the job needs an explicit permissions: contents: write.

Since actions/upload-release-asset has been archived since 2021 and won't receive security or Node-runtime updates, I'd still suggest making the switch in this PR while we're already touching this workflow.

[utkarshcloudinary]

With workflow_call, secrets are not passed automatically; the caller must add secrets: inherit (or ci.yml must declare the secret under on.workflow_call.secrets). As written, every release-triggered run will execute E2E with an empty CLOUDINARY_E2E_URL, which will silently test the wrong target or fail; blocking the deploy since deploy_to_wp_repository has needs: lint_and_test.

Suggested change

	uses: ./.github/workflows/ci.yml
	uses: ./.github/workflows/ci.yml
	secrets: inherit