feat(release): build and publish sdist/wheels on GitHub Release - #1207
Conversation
Adds a hash-pinnable, PyPI-published artifact path so downstream consumers (LineageWeave) can depend on fast-mlsirm through a normal versioned requirement instead of an unhashable git source, which currently makes every LineageWeave PR fail the org's sandboxed coverage-evidence review gate (uv export cannot emit --hash for a git dependency). Builds sdist + wheels (linux x86_64/aarch64 manylinux2014, macos universal2, windows x86_64) via maturin-action on GitHub Release publish, verifies with twine check, attaches the artifacts to the release, and publishes to PyPI using the existing PIPY_TOKEN/ PIPY_USERNAME org secrets. See ContextualWisdomLab/.github#1212 for full root-cause evidence.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
📝 WalkthroughWalkthroughThe pull request adds a GitHub Actions workflow that builds source and platform-specific wheel distributions when a release is published. It validates the artifacts, attaches them to the GitHub Release, and publishes them to PyPI. ChangesPyPI release automation
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: 🟠 High · up to This PR adds automated package publishing, but the current workflow can execute an unsanitized release tag in a credentialed job, cannot upload release assets with its current permissions, and uses a floating build-tool version that can change released artifacts; merge is not ready until these issues are corrected. Sequence Diagram(s)sequenceDiagram
participant Release as Published release
participant Actions as GitHub Actions
participant Builders as Build jobs
participant Publish as Publish job
participant GitHub as GitHub Release
participant PyPI
Release->>Actions: Trigger workflow
Actions->>Builders: Run sdist and wheel builds
Builders-->>Publish: Provide distribution artifacts
Publish->>Publish: Validate artifacts with Twine
Publish->>GitHub: Upload release assets
Publish->>PyPI: Publish distributions
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
opencode-agent
Bot
added
area: ci-cd
|
@opencode-agent please review — this is a direct test of the review-pipeline fix landed in ContextualWisdomLab/.github#1221 (root cause #3 of ContextualWisdomLab/.github#1212). |
2 participants
Change
Adds a release-controlled package publication path for hash-pinnable
fast-mlsirmsdists and wheels, with exact-tag provenance, pinned build/publish tooling, isolated GitHub release writes, and explicit recovery semantics for the two publication sinks.Release provenance and trigger integrity
release-tag.ymlcreates the immutable tag/GitHub Release and explicitly dispatchespublish-pypi.ymlfrom that exact tag; it does not depend on a token-createdreleaseevent recursively starting another workflow.verify-releasechecks out the exact dispatched tag with persisted credentials disabled and requires the tag to equalv{project.version}.v1.14.1.Publication boundaries
release-assetsalone getscontents: write; PyPI publication retainscontents: readand thepypienvironment.gh release uploadthroughRELEASE_TAGrather than shell expression interpolation.pypa/gh-action-pypi-publish@dc37677b2e1c63e2034f94d8a5b11f265b73ba33,PIPY_TOKEN, no runtime Twine install, noskip-existing, and no token-path attestation claim.needs: release-assets, so a previously failed PyPI publish can be retried even when immutable GitHub assets already exist and correctly reject replacement.Test-first evidence
68e93b349afc44fb6d4ae9450aa9afde0fbe0281→ GREEN2c95af58af1e1c1bb0947efc5c696941557598f8covers exact-tag checkout, version matching, pinned tooling, isolated permissions, safe tag transport, pinned PyPA publishing and credential semantics.3ad31e7b667058263c5231c852ce6c0489250a22→ GREEN0d9d327c8fba49b1b85a194243ea920ceca4f680removes--clobber.3647e605052c988758d21746feb9ecf64b370ac6→ GREENa10d3fa53c688b1e03628515f8dd6ffc01ec1a83; evidence4ba34e945e67949400af9b0109574a07c5dd45d0.64b06c808413c0fe3ddcbfd0d6e9ef8ab7dddb4d→ GREENb51b88c6ee2cf68449ea3b0494607af731bad8a4: contract test requires both publication sinks to depend directly on[sdist, wheels], not on each other.32030e8640ad2003fe91bfc395a04885aceff95frecords independent PyPI recovery while retaining immutable GitHub/PyPI duplicate-filename failure semantics. The corresponding coupling review thread is resolved; unrelated secret-provisioning and macOS operational notes remain current until proven externally.Acceptance boundary
Protected base remains
main@04d0bc21a2a20693bcf16108cd76d394fe844d23; exact current head is32030e8640ad2003fe91bfc395a04885aceff95f, open, non-Draft and mergeable. Every predecessor-head check/review is historical after the recovery commits. Repository source cannot prove the externalpypienvironment, the literalPIPY_TOKENsecret, or the first real macOS universal2 artifact. The next canonical release remains the operational acceptance point for those external facts. Merge only after all exact-current-head protected CI/security/package/SBOM/provenance/coverage/review requirements are terminal and clean; no gate bypass, self-approval, force update or credential invention.