Skip to content

ci: bump pypa/gh-action-pypi-publish to v1.14.2, release arcade-serve 3.4.2 - #908

Merged
EricGustin merged 4 commits into
mainfrom
ericgustin/fix-pypi-publish-metadata-2-5
Aug 13, 2026
Merged

ci: bump pypa/gh-action-pypi-publish to v1.14.2, release arcade-serve 3.4.2#908
EricGustin merged 4 commits into
mainfrom
ericgustin/fix-pypi-publish-metadata-2-5

Conversation

@EricGustin

@EricGustin EricGustin commented Aug 13, 2026

Copy link
Copy Markdown
Member

What broke

The arcade-serve 3.4.1 release never reached PyPI. The pypi-publish job in run 31654382725 failed at the upload step:

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

PyPI still shows 3.4.0 as latest. detect-version-changes and build-and-test both passed; only the publish step failed.

Why

The publish step was pinned to cef2210, a release/v1 commit from 2026-02-18 that bundles twine 6.1.0 / packaging 25.0. That packaging release only recognizes core metadata versions up to 2.4.

Meanwhile the build step runs uv build, which resolves the newest Hatchling at build time, and that now emits Metadata-Version: 2.5. Both the wheel and the sdist from the failing run carry 2.5. Nothing changed in the package itself; the build side moved forward and the pinned publisher did not.

Verification

I downloaded the actual artifacts from the failing run and parsed them with both packaging versions:

  • packaging==25.0 (pinned action) rejects the wheel: invalid or unparsed metadata
  • packaging==26.2 (v1.14.2) parses it and reports metadata_version = 2.5

v1.14.2 bundles twine 7.0.0 / packaging 26.2.

The changes

  1. Bump the action pin to v1.14.2 (a892a5a), still SHA-pinned.
  2. Bump arcade-serve to 3.4.2.

The version bump is here rather than in a follow-up PR because of how the release workflow triggers. It fires only on a push to main, and check-version-changes.sh looks for a changed version = line in the HEAD^..HEAD diff of a package's pyproject.toml. A workflow-only fix would merge without releasing anything, and re-running the failed job would not help either, since a re-run uses the workflow file as of the original triggering commit and would pick up the old pin again.

Merging this PR pushes both changes to main in one commit. That push runs the workflow with the fixed pin and the changed version line, so 3.4.2 publishes on merge.

Notes

  • 3.4.2 contains no code changes over 3.4.1. 3.4.1 will simply never exist on PyPI.
  • The downstream constraint in arcade-mcp-server (arcade-serve>=3.4.0,<4.0.0) still holds, so no dependent needs updating.
  • This bug was never specific to arcade-serve. The next version bump of any package in the repo would have hit the same failure.
  • Worth confirming on PyPI after merge that 3.4.2 actually lands.

Tracked in TOO-1850.


Note

Low Risk
CI dependency pin and a version-only release bump; no application or security logic changes.

Overview
Fixes failed PyPI uploads by SHA-pinning pypa/gh-action-pypi-publish to v1.14.2 in release-on-version-change.yml, replacing an older release/v1 commit whose bundled twine/packaging rejected wheels built with Metadata-Version 2.5.

Triggers a new release by bumping arcade-serve from 3.4.1 → 3.4.2 in libs/arcade-serve/pyproject.toml so the version-change workflow runs on merge with the fixed publisher (3.4.1 never shipped; 3.4.2 is a republish with no package code changes).

Reviewed by Cursor Bugbot for commit 9f889a5. Bugbot is set up for automated code reviews on this repo. Configure here.

The pinned commit (cef2210, 2026-02-18) bundles twine 6.1.0 / packaging
25.0, which only recognizes core metadata versions up to 2.4. The
Hatchling that `uv build` resolves now emits `Metadata-Version: 2.5`, so
twine rejected the distributions before upload:

    InvalidDistribution: Invalid distribution metadata:
    '2.5' is not a valid metadata version

This blocked the arcade-serve 3.4.1 release. v1.14.2 bundles twine 7.0.0
/ packaging 26.2, which parses the failing artifacts without error.
@greptile-apps

greptile-apps Bot commented Aug 13, 2026

Copy link
Copy Markdown

Greptile Summary

The PR updates the SHA-pinned PyPI publishing action to the v1.14.2 commit and bumps arcade-serve to 3.4.2 so the corrected release workflow publishes a new package version.

  • Replaces the publisher revision with tooling that accepts Core Metadata 2.5.
  • Advances arcade-serve from 3.4.1 to 3.4.2 to trigger version-change detection on merge.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename Overview
.github/workflows/release-on-version-change.yml Updates the SHA-pinned PyPI publisher to the commit underlying v1.14.2, preserving the existing artifact path and trusted-publishing configuration.
libs/arcade-serve/pyproject.toml Bumps the package patch version to 3.4.2; existing dependent constraints continue to accept this version.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    A[Merge to main] --> B[Detect arcade-serve version change]
    B --> C[Build and test 3.4.2]
    C --> D[Download distributions]
    D --> E[Publish with gh-action-pypi-publish v1.14.2]
    E --> F[arcade-serve 3.4.2 on PyPI]
Loading

Reviews (4): Last reviewed commit: "ci: pin publish action to the v1.14.2 co..." | Re-trigger Greptile

@codecov

codecov Bot commented Aug 13, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

3.4.1 was built but never uploaded, so the release workflow has to be
re-triggered to get these changes onto PyPI. That workflow only fires on
a push to main whose diff contains a changed `version = ` line in a
package's pyproject.toml, so republishing requires a new version number.

No code changes since 3.4.1; the downstream constraint in
arcade-mcp-server (`arcade-serve>=3.4.0,<4.0.0`) still holds.
@EricGustin EricGustin changed the title ci: bump pypa/gh-action-pypi-publish to v1.14.2 ci: bump pypa/gh-action-pypi-publish to v1.14.2, release arcade-serve 3.4.2 Aug 13, 2026
[project]
name = "arcade-serve"
version = "3.4.1"
version = "3.4.2"

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

required to rerun the gha

Conflict in the pypi-publish action pin. #901 (dependabot) moved it to
ba38be9e, which still bundles twine 6.1.0 / packaging 25.0 and therefore
still rejects `Metadata-Version: 2.5`. Kept this branch's a892a5a
(v1.14.2, twine 7.0.0 / packaging 26.2), which is a descendant of
ba38be9e, so nothing from #901 is lost.

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit d4462c3. Configure here.

Comment thread .github/workflows/release-on-version-change.yml Outdated
v1.14.2 is an annotated tag, so `git/refs/tags/v1.14.2` resolves to the
tag object (a892a5a) rather than the commit it points at. GitHub Actions
resolves `uses: owner/repo@<sha>` against commits only, so the previous
pin would have failed to resolve the action.

dc37677 is the commit v1.14.2 points at. It carries the same twine 7.0.0
/ packaging 26.2 that this change is after, and still has ba38be9e (the
pin from #901) as an ancestor.
@EricGustin
EricGustin merged commit 597deba into main Aug 13, 2026
50 checks passed
@EricGustin
EricGustin deleted the ericgustin/fix-pypi-publish-metadata-2-5 branch August 13, 2026 01:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants