[PR #44] [MERGED] ci: bump gh-action-pypi-publish to v1.14.2 so publishing accepts Metadata-Version 2.5 #52

New issue

Closed

opened 2026-10-31 22:01:02 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 22:01:02 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/Comfy-Org/comfy-python-sdk/pull/44
Author: @wei-hai
Created: 8/11/2026
Status: ✅ Merged
Merged: 8/12/2026
Merged by: @wei-hai

Base: main ← Head: wei/fix-pypi-publish-action-metadata-2-5

📝 Commits (1)

36a4148 ci: bump gh-action-pypi-publish to v1.14.2 so publishing accepts Metadata-Version 2.5

📊 Changes

1 file changed (+5 additions, -2 deletions)

View changed files

📝 .github/workflows/publish.yml (+5 -2)

📄 Description

Bumps pypa/gh-action-pypi-publish from v1.12.4 (Jan 2025) to v1.14.2, so the publish step can accept the wheels the build step produces.

Why

The v0.1.6 publish failed at the upload step:

Checking dist/comfy_sdk-0.1.6-py3-none-any.whl:
ERROR InvalidDistribution: Invalid distribution metadata: '2.5' is not a valid metadata version

The build job installs its tooling unpinned (pip install build twine), so it now builds a wheel carrying Metadata-Version 2.5 and validates it with a current twine — which passes. The publish job then hands that same wheel to the action pinned at v1.12.4, whose bundled packaging predates metadata 2.5 and rejects it.

The two jobs were validating the same artifact with different tooling versions, so the build-time gate structurally could not catch this — twine check passed and the upload failed on the identical file.

Scope

The one-line pin, applied to both the PyPI and TestPyPI steps (same action, same failure mode), plus a comment recording the version floor so the pin doesn't get rolled back.

Deliberately not included: pinning build/twine in the build job. That would also prevent the drift and is arguably the more complete fix, but it's a separate decision about tooling policy and would put the repo on a manual upgrade treadmill — worth its own discussion rather than riding along here.

Verification

The action bump can't be exercised before merge: the publish job only runs on a release event, and workflow_dispatch is a build-only dry run that never reaches it. Checked instead:

The pin resolves to the real thing — dc37677b2e1c63e2034f94d8a5b11f265b73ba33 is the commit pypa/gh-action-pypi-publish tag v1.14.2 dereferences to.
YAML still parses.
Trusted-Publishing setup is untouched; the action's inputs (packages-dir, skip-existing, repository-url) are unchanged between v1.12.4 and v1.14.2, so no call-site changes are needed.

Real verification is the next release publishing successfully.

Follow-up

v0.1.6 is tagged and the GitHub Release is published, but nothing reached PyPI (the failure is pre-upload, so the version number is still unused). Once this merges, the tag and Release need to be recreated at the new main so the publish re-runs against the fixed workflow — the existing tag points at a commit that still carries v1.12.4. @comfyorg/sdk 0.1.6 is already live on npm, so reusing 0.1.6 here keeps the two SDKs in lockstep.

Summary by CodeRabbit

Chores
- Updated package publishing workflows to support artifacts using Metadata-Version 2.5.
- Improved compatibility when publishing releases to PyPI and TestPyPI.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/Comfy-Org/comfy-python-sdk/pull/44 **Author:** [@wei-hai](https://github.com/wei-hai) **Created:** 8/11/2026 **Status:** ✅ Merged **Merged:** 8/12/2026 **Merged by:** [@wei-hai](https://github.com/wei-hai) **Base:** `main` ← **Head:** `wei/fix-pypi-publish-action-metadata-2-5` --- ### 📝 Commits (1) - [`36a4148`](https://github.com/Comfy-Org/comfy-python-sdk/commit/36a4148e194425728e99c9acae95092faa5dae58) ci: bump gh-action-pypi-publish to v1.14.2 so publishing accepts Metadata-Version 2.5 ### 📊 Changes **1 file changed** (+5 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `.github/workflows/publish.yml` (+5 -2) </details> ### 📄 Description Bumps `pypa/gh-action-pypi-publish` from v1.12.4 (Jan 2025) to v1.14.2, so the publish step can accept the wheels the build step produces. ## Why The v0.1.6 publish failed at the upload step: ``` Checking dist/comfy_sdk-0.1.6-py3-none-any.whl: ERROR InvalidDistribution: Invalid distribution metadata: '2.5' is not a valid metadata version ``` The `build` job installs its tooling unpinned (`pip install build twine`), so it now builds a wheel carrying **Metadata-Version 2.5** and validates it with a current twine — which passes. The `publish` job then hands that same wheel to the action pinned at v1.12.4, whose bundled packaging predates metadata 2.5 and rejects it. The two jobs were validating the same artifact with different tooling versions, so the build-time gate structurally could not catch this — `twine check` passed and the upload failed on the identical file. ## Scope The one-line pin, applied to both the PyPI and TestPyPI steps (same action, same failure mode), plus a comment recording the version floor so the pin doesn't get rolled back. Deliberately **not** included: pinning `build`/`twine` in the build job. That would also prevent the drift and is arguably the more complete fix, but it's a separate decision about tooling policy and would put the repo on a manual upgrade treadmill — worth its own discussion rather than riding along here. ## Verification The action bump can't be exercised before merge: the publish job only runs on a `release` event, and `workflow_dispatch` is a build-only dry run that never reaches it. Checked instead: - The pin resolves to the real thing — `dc37677b2e1c63e2034f94d8a5b11f265b73ba33` is the commit `pypa/gh-action-pypi-publish` tag `v1.14.2` dereferences to. - YAML still parses. - Trusted-Publishing setup is untouched; the action's inputs (`packages-dir`, `skip-existing`, `repository-url`) are unchanged between v1.12.4 and v1.14.2, so no call-site changes are needed. Real verification is the next release publishing successfully. ## Follow-up `v0.1.6` is tagged and the GitHub Release is published, but nothing reached PyPI (the failure is pre-upload, so the version number is still unused). Once this merges, the tag and Release need to be recreated at the new `main` so the publish re-runs against the fixed workflow — the existing tag points at a commit that still carries v1.12.4. `@comfyorg/sdk` 0.1.6 is already live on npm, so reusing 0.1.6 here keeps the two SDKs in lockstep.  ## Summary by CodeRabbit * **Chores** * Updated package publishing workflows to support artifacts using Metadata-Version 2.5. * Improved compatibility when publishing releases to PyPI and TestPyPI.  --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 22:01:02 +00:00