ci(release): use shared Python publishing actions - #706
Conversation
Migrate production PyPI releases to the commit-pinned sdk-actions configure, validation, approval, and build-and-ship flow. Enable SBOM attestations while preserving stable approval gating and manual prerelease version overrides.
David Elner (delner)
left a comment
David Elner (delner)
left a comment
There was a problem hiding this comment.
Overall looks good, but there's a couple of things worth addressing particularly as it pertains to tooling (and how we update the workflow in the future.) These should be relatively easy fixes. We will need to update repo settings and PyPi to match before we merge this repo.
|
thanks for the review David Elner (@delner)! Pushed up changes in 424ca7f, I also updated environments + pypi publishing |
Align production Python releases with the Ruby SDK turnkey flow: require a committed version at an explicit SHA, gate manual stable and prerelease publishes, and keep the existing Python build verification and tag format. Update the release preparation workflow and publishing documentation; TestPyPI and canary publishing remain unchanged.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 95cd0cec0f
ℹ️ 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 (@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 (@codex) address that feedback".
| working_directory: py | ||
| python_version: .tool-versions | ||
| release_tag: ${{ needs.configure.outputs.release_tag }} | ||
| on_release_branch: ${{ needs.configure.outputs.on_release_branch }} |
There was a problem hiding this comment.
When release_type=stable is dispatched with a SHA outside main, this passes on_release_branch to the shared validator but does not enable release-branch enforcement; the accompanying documentation confirms that an off-branch SHA only produces a warning. After environment approval, the workflow can therefore publish and permanently tag an unmerged commit as a stable PyPI release. Enforce main for stable runs while retaining warning-only behavior for prereleases.
AGENTS.md reference: AGENTS.md:L294-L299
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 5feaea8b. Stable runs now set enforce_release_branch=true, while prerelease runs keep warning-only off-main behavior. The publishing docs now state the distinction explicitly.
Reject stable release SHAs outside `main` before environment approval so an unmerged commit cannot be permanently published and tagged. Keep prerelease branches warning-only to match the documented release flow.
3 participants
Replace the custom production PyPI workflow with the commit-pinned
sdk-actionsturnkey flow.Stable releases now use the merge commit from the version-bump PR, and the workflow rejects stable
release SHAs outside
main. Prereleases require the prerelease version to be committed on the targetbranch; off-
mainprerelease branches produce a warning instead of failing. Both use thepublishenvironment, while dry runs usepublish-dry-run.Keep the Python-specific
make install-dev verify-buildchecks, release-channel templating, andexisting
py-sdk-v{version}tag format. Production publishes also generate and attest a CycloneDXSBOM through OIDC trusted publishing.
TestPyPI prereleases, canary publishing, and the canary scheduler are intentionally unchanged.
Required repository configuration:
publishandpublish-dry-runpublish-py-sdk.yamland environmentpublishSLACK_SDK_RELEASE_CHANNELvisible to this repositoryValidated with
actionlint, the sdk-actions workflow validator and baseline comparison,scripts/ensure-pinned-actions.sh, and pre-commit.