fix: Use uv for build/publish and add version check#966
Conversation
Update GitHub Actions to use astral-sh/setup-uv for building and publishing, upgrade actions/setup-python to v6, and extract the package version from pyproject.toml. Add a PyPI check (via curl) to skip build/publish when the version already exists and gate the build/publish steps on that result; use UV_PUBLISH_TOKEN for publishing. Also adjust sdks/mcp/pyproject.toml version to 0.1.0.
There was a problem hiding this comment.
Pull request overview
This pull request modernizes the MCP package publishing workflow by migrating from legacy Python build tools (build and twine) to uv, and implements version duplicate-prevention checks. The workflow now extracts the version directly from pyproject.toml instead of git tags, ensuring consistency between the package metadata and what gets published.
Changes:
- Updated the publishing workflow to use
uv buildanduv publishinstead ofpython -m buildandtwine upload - Added a pre-publish check that queries PyPI to skip building/publishing if the version already exists
- Changed version extraction to read directly from
pyproject.tomlusing grep instead of parsing git tags - Downgraded package version from 0.1.1 to 0.1.0 in
pyproject.toml
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| .github/workflows/publish-mcp.yml | Modernized workflow to use uv (v4) for build/publish, added PyPI version existence check, switched from PYPI_TOKEN to UV_PUBLISH_TOKEN secret, and changed version extraction to read from pyproject.toml |
| sdks/mcp/pyproject.toml | Downgraded package version from 0.1.1 to 0.1.0 |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| [project] | ||
| name = "openrag-mcp" | ||
| version = "0.1.1" | ||
| version = "0.1.0" |
There was a problem hiding this comment.
The version is being downgraded from "0.1.1" to "0.1.0". This is problematic because:
- Version downgrades can cause confusion and break semantic versioning conventions
- If version 0.1.1 was already published to PyPI, users who have installed it won't receive updates until a version higher than 0.1.1 is released
- The README.md (line 32) references version 0.2.1 in an example, suggesting there may be published versions higher than 0.1.0
Consider incrementing the version to a higher number (e.g., 0.1.2 or 0.2.0) instead of downgrading. If this downgrade is intentional and version 0.1.1 was never published, please add a comment in the PR description explaining why.
| version = "0.1.0" | |
| version = "0.1.2" |
| - name: Install build tools | ||
| run: pip install build twine | ||
| - name: Install uv | ||
| uses: astral-sh/setup-uv@v4 |
There was a problem hiding this comment.
The workflow uses setup-uv@v4, but other workflows in the repository (build-multiarch.yml, test-integration.yml, update-uv-lock.yml) still use setup-uv@v3. While this is not necessarily a problem since v4 should be compatible, it creates an inconsistency across workflows.
Consider updating all workflows to use the same version (v4) for consistency, or document why different versions are used in different workflows.
| uses: astral-sh/setup-uv@v4 | |
| uses: astral-sh/setup-uv@v3 |
| else | ||
| echo "exists=false" >> $GITHUB_OUTPUT |
There was a problem hiding this comment.
The version check doesn't handle potential network failures or PyPI API issues. If curl fails or PyPI is temporarily unavailable, the HTTP_STATUS variable might contain an error code (like 500, 503) or be empty, which would incorrectly set exists=false and attempt to publish.
Consider adding error handling to detect non-200/404 status codes and fail the workflow explicitly in those cases, for example:
if [ "$HTTP_STATUS" = "200" ]; then
echo "exists=true" >> $GITHUB_OUTPUT
elif [ "$HTTP_STATUS" = "404" ]; then
echo "exists=false" >> $GITHUB_OUTPUT
else
echo "Unexpected HTTP status: $HTTP_STATUS"
exit 1
fi| else | |
| echo "exists=false" >> $GITHUB_OUTPUT | |
| elif [ "$HTTP_STATUS" = "404" ]; then | |
| echo "exists=false" >> $GITHUB_OUTPUT | |
| else | |
| echo "Unexpected HTTP status from PyPI: $HTTP_STATUS" | |
| exit 1 |
This pull request updates the MCP publishing workflow and corrects the package version in
pyproject.toml. The workflow now usesuvfor building and publishing, checks if a version already exists on PyPI before publishing, and ensures the published version matches the one specified inpyproject.toml.Workflow improvements:
.github/workflows/publish-mcp.ymlto useactions/setup-python@v6andastral-sh/setup-uv@v4, replacing legacy build tools withuvfor building and publishing the package.pyproject.tomlinstead of the git tag, ensuring consistency between the workflow and the package metadata.Version correction:
sdks/mcp/pyproject.tomlto set the package version to0.1.0, aligning it with the workflow and preventing mismatches during publishing.