ci: publish on tag push instead of the release event

[chengzeyi]

python-publish.yml triggers on release: published, but that event never reaches it.

python-packages.yml creates the GitHub Release on tag push using GITHUB_TOKEN, and GitHub deliberately does not start new workflow runs from events produced by GITHUB_TOKEN (the anti-recursion rule). So the Release appears, every other check goes green, and the package is silently never uploaded.

This bit wavespeed twice — 2.0.0 and again at 2.0.1 today. Both times the fix was manual: delete and recreate the Release, or workflow_dispatch on main.

 on:
-  release:
-    types: [published]
+  push:
+    tags:
+      - "v[0-9]+*"
   workflow_dispatch:

with the job if updated from github.event_name == 'release' to == 'push'.

A tag push is a real user action, so it triggers workflows normally. workflow_dispatch on main stays as the escape hatch.

release: published is replaced rather than kept alongside: keeping both would let a manually-created Release and a tag push each fire an upload of the same version, and the second would fail against PyPI. One unambiguous trigger is better than two that mostly do not overlap.

Workflow file only — the build and trusted-publishing steps are untouched.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a5b91499ab

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Gate PyPI publishing on the GitHub release

On a version-tag push this workflow now runs independently of .github/workflows/python-packages.yml; in that workflow, gh_release is a separate job guarded by the github-release environment, with no dependency connecting it to this deployment. If the release job is awaiting approval or fails, this job can still irreversibly publish the package to PyPI, whereas the previous release: published trigger guaranteed that the GitHub release existed first. Run publishing after gh_release succeeds or otherwise trigger it from that successful workflow.

Useful? React with 👍 / 👎.