Skip to content

Separate Python package publishing, testing, and attestation - #8546

Draft
Amaury Chamayou (achamayou) wants to merge 5 commits into
microsoft:mainfrom
achamayou:achamayou-redesigned-goggles
Draft

Amaury Chamayou (achamayou) wants to merge 5 commits into
microsoft:mainfrom
achamayou:achamayou-redesigned-goggles

Conversation

@achamayou

@achamayou Amaury Chamayou (achamayou) commented Oct 9, 2026 •

Copy link
Copy Markdown
Member

Motivation

Follow up on #8501: Python packages will be released separately through the manually queued OneBranch pipeline. Remove the competing GitHub Actions publisher and keep release testing and Python attestations consistent with that split.

Implementation summary

  • Remove the GitHub Actions PyPI publisher and Python wheel building, artifact transfer, and attachment from the main CCF release workflow.
  • Use the latest released PyPI SDK in release-build tests, installed-package tests, and recovery benchmarks. Normal development and CI retain the local SDK; ordinary installed sandboxes retain their version-pinned default.
  • Separate Python wheel attestations from other release assets. After ESRP publication, a maintainer manually runs a dedicated GitHub workflow on the release tag using the original OneBranch build inputs. It verifies the tag/commit, published release, wheel metadata, and PyPI/downloaded digests against the OneBranch build before signing and uploading python-package.attestation.sigstore.json.

Safety and compatibility

No CCF runtime, protocol, or ledger-format changes. The GitHub Release review/publication gate, NPM publisher, and default development/CI SDK selection are preserved. Release builds intentionally test the already-published SDK rather than an unpublished local version.

Attestation is manually triggered in GitHub; no additional GitHub credential or dispatch job is needed in OneBranch. The attestation workflow must exist on main and the release tag. See the OneBranch release documentation for manual invocation and attestation-only retry instructions.

The Python attestation signs the verified published wheel; it does not claim that GitHub Actions built it or replace build-time OneBranch provenance. The end-to-end process still needs validation with a production OneBranch publication and manual attestation.

Local repository checks and release-mode recovery/logging tests passed. With LONG_TESTS=ON, cd build && ./tests.sh --output-on-failure -R '^lts_compatibility$' --no-tests=error fails with HTTP 500 during CCF 6.0.28 private ledger recovery. The same failure reproduces with the editable local SDK and the released SDK; this unrelated compatibility failure is not changed here.

Use the latest published SDK only in CCF release-build tests. Remove the legacy GitHub publisher and wheel release assets, and dispatch a digest-bound Python attestation from OneBranch after ESRP publication.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Avoid reinstalling the SDK in caller-owned virtual environments shared by release-test sandboxes. Cover inherited environments with regression cases while retaining published SDK installation in sandbox-owned environments.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Remove the OneBranch-to-GitHub dispatch stage and its credential requirement. Document manual attestation from the release tag using the original build inputs, and print the package version and wheel digest for maintainers.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

This branch has not been deployed

No deployments
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.

1 participant