ci: publish all packages from a single pypi job

[u9g]

What

Collapse the per-package publish matrix in publish.yml into a single job that downloads every dist-* artifact and runs pypa/gh-action-pypi-publish once.

Why

The pypi environment now has required reviewers (see the hardening thread in #team-agents-tickets). Each matrix leg is its own pending deployment, so the v1.8.2 release raised one review request per package and the GitHub Slack app posted 100+ messages to #updates-code, each tagging all six reviewers.

With one publish job there is one pending deployment per release: one approval click, one Slack message.

Notes

• Trusted publishing mints a token scoped to every project whose publisher config matches the workflow and environment, so one job can upload all packages.
• skip-existing: true keeps republishes working. Before, a package that was already on PyPI only failed its own matrix leg. Now all dists upload from one job, so already-published files must be skipped instead of aborting the rest.
• The dist-* pattern also matches the per-OS intermediate artifacts for blockguard and durable. They contain the same wheel filenames as the merged artifact, so merging them is a no-op.
• Downstream jobs (docs, deploy-examples, dispatch-downstream-bumps) already keyed off the aggregate needs.publish.result, so their behavior is unchanged.

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🔴 Partial builds produce successful releases

When a package build fails, pattern downloads the remaining artifacts and publishing can succeed. The ignored build failure lets downstream deployment and version bumps proceed after an incomplete release.

Learn more

The build job is a matrix over every discovered package. Its aggregate result becomes failure or cancelled when a package build does not complete, but the publish job runs whenever discovery succeeded. A wildcard artifact download only requires at least one matching artifact and cannot detect which expected package is absent. The publish action can therefore upload the available distributions and return success. The dependent docs, examples, and downstream-bump jobs then treat the incomplete release as complete.

Example: Suppose 78 package builds upload artifacts and livekit-plugins-openai fails before upload. The wildcard downloads the 78 available artifacts, publishes them, and returns success. The workflow bumps downstream repositories even though the new OpenAI package version is absent from PyPI.

Recommended fix: Gate the publish job on needs.build.result == 'success' while retaining always() if needed for explicit result checks. Alternatively, validate the downloaded artifacts against needs.discover.outputs.packages before publishing and fail on every missing package.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[u9g]

Local verification of the upload behavior (the OIDC step can't run outside Actions):

• actionlint on the workflow: no new findings, the 4 shellcheck warnings it reports are already on main.
• Against a local pypiserver with twine 7.0.0 (the version pinned by the pypa action), built wheels for livekit-agents, plugins-deepgram, plugins-openai:
  • one twine upload with all three wheels: all uploaded, exit 0.
  • republish with a 4th wheel (plugins-cartesia) and no skip-existing: aborted on the first duplicate, cartesia never uploaded, exit 1. This is the regression skip-existing guards against.
  • same republish with skip-existing: the three duplicates skipped with warnings, cartesia uploaded, exit 0.