Skip to content

chore: Trusted environment publish hardening#70

Merged
daxpryce merged 3 commits into
devfrom
trusted-environment-publish-hardening
Jun 2, 2026
Merged

chore: Trusted environment publish hardening#70
daxpryce merged 3 commits into
devfrom
trusted-environment-publish-hardening

Conversation

@daxpryce

@daxpryce daxpryce commented Jun 2, 2026

Copy link
Copy Markdown
Contributor

Moving to a trusted publication process through pypi and github environments. Also simplifying the release process. Previously pre-releases would be published via merge to dev and final releases when we merge to main, but we're switching over to a tag release model off of main instead.

daxpryce and others added 2 commits June 2, 2026 12:10
- Rename build.yml → ci.yml (lint + build + test on push/PR only)
- Remove version-munging job and manifest_version.py script; version is
  now solely what's in Cargo.toml
- Create publish.yml triggered on v* tags with:
  - OIDC trusted publishing (id-token: write, no stored credentials)
  - pypi-publish environment (requires manual approval + tag restriction)
  - pypa/gh-action-pypi-publish for upload
  - GitHub Release creation with checksums
- Remove dev/main branch publish logic and prerelease handling

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Ensures the tagged commit exists on the main branch before building
and publishing. Combined with tag protection rules (v* restricted to
maintainers) and environment approval, this provides defense-in-depth.

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

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

This PR hardens and simplifies the project’s release workflow by moving to PyPI trusted publishing via GitHub Environments and switching releases to a tag-driven model off main (instead of publishing prereleases from dev and finals from main merges).

Changes:

  • Replace the prior combined CI/build/publish workflow with a dedicated CI workflow and a tag-triggered Publish to PyPI workflow.
  • Implement trusted publishing (pypa/gh-action-pypi-publish) and environment-gated publishing.
  • Remove build-number/version materialization logic and the previous branch-based publish flow.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File Description
.github/workflows/publish.yml Adds tag-triggered build + trusted PyPI publish + GitHub Release creation.
.github/workflows/ci.yml Adds CI workflow for formatting, linting, tests, and artifact builds across platforms.
.github/workflows/build.yml Removes the prior combined CI/build/publish workflow and branch-based publishing logic.
.github/build/manifest_version.py Removes the build-number-based version materialization script used by the old release flow.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread .github/workflows/publish.yml Outdated
Comment thread .github/workflows/publish.yml
Comment thread .github/workflows/publish.yml
Comment thread .github/workflows/publish.yml
- Scope workflow-level permissions to contents:read; only publish job
  gets id-token:write and contents:write
- Add tag/version mismatch check (tag v1.3.0 must match Cargo.toml 1.3.0)
- Add skip-existing to pypi-publish for idempotent re-runs
- Add Rust and Python unit tests to the release build job

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

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

.github/workflows/publish.yml:31

  • The Cargo.toml version check is brittle: it relies on grep '^version' ... | head -1, which will silently start reading the wrong version = ... line if the file is reordered (e.g., a [dependencies.<crate>] table with a top-level version key appears before [package]). Since this gate controls releases, it’s safer to parse TOML and read [package].version explicitly.

@daxpryce
daxpryce merged commit 27fbaf0 into dev Jun 2, 2026
17 checks passed
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