Skip to content

Release tooling: PyPI Trusted Publishing + v1.0.0 - #14

Merged
CryptoFewka merged 1 commit into
mainfrom
chore/pypi-release-1.0.0
Jun 25, 2026
Merged

Release tooling: PyPI Trusted Publishing + v1.0.0#14
CryptoFewka merged 1 commit into
mainfrom
chore/pypi-release-1.0.0

Conversation

@CryptoFewka

@CryptoFewka CryptoFewka commented Jun 25, 2026

Copy link
Copy Markdown
Contributor

What

Sets the repo up to publish to PyPI through the GitHub Release flow, and cuts the version to 1.0.0.

Release automation

  • .github/workflows/release.yml runs when a GitHub Release is published. It builds the sdist + wheel and uploads to PyPI via Trusted Publishing (OIDC) (id-token: write, environment: pypi) — no API token stored in the repo. Actions are SHA-pinned to match the repo's hardening convention (pypa/gh-action-pypi-publish v1.14.0).
  • A verify step asserts the release tag (with optional leading v) matches the package version, so a release can never publish a version different from what its tag claims.

Versioning

  • Bumped to 1.0.0; Development Status classifier flipped to 5 - Production/Stable.
  • Made src/optimum_keysync/__init__.py:__version__ the single source of truth via setuptools dynamic version (dynamic = ["version"] + [tool.setuptools.dynamic]), so pyproject.toml and the package can't drift. (Previously both hardcoded the version independently.)

Docs/examples

  • README Releasing section documents the flow.
  • k8s example image tag bumped to 1.0.0.

Verified locally

  • python -m buildoptimum_keysync-1.0.0.tar.gz + ...-py3-none-any.whl (dynamic version resolves to 1.0.0).
  • pytest 84 passed; ruff and mypy clean.

⚠️ One-time setup required before the first release works

Register the trusted publisher on PyPI (PyPI is configured in its web UI, not here):

  • Project: optimum-keysync
  • Owner / repo: getoptimum/optimum-customer-key-import
  • Workflow filename: release.yml
  • Environment name: pypi

Also create the pypi environment in repo Settings → Environments (optionally add release protection rules). If the project doesn't exist on PyPI yet, use PyPI's "pending publisher" so the first release creates it.

How to cut the release after merge

  1. Merge this PR to main.
  2. Publish a GitHub Release tagged v1.0.0.

Written with Claude Code

Summary by CodeRabbit

  • New Features

    • Added automated PyPI release publishing from GitHub Releases.
    • Package and deployment images now use version 1.0.0.
  • Documentation

    • Added release instructions for publishing a new version and setting up trusted publishing.
  • Chores

    • Updated the project version to 1.0.0 across release and deployment configs.

- Add .github/workflows/release.yml: on a published GitHub Release, build the
  sdist + wheel and upload to PyPI via Trusted Publishing (OIDC, id-token:
  write, environment: pypi). No API token stored. Actions pinned to SHAs.
- Verify-tag-matches-version guard so a release can't publish a different
  version than its tag claims.
- Bump to 1.0.0 and flip the Development Status classifier to Production/Stable.
- Make __init__.__version__ the single source of truth via setuptools dynamic
  version, so pyproject and the package can't drift.
- README 'Releasing' section; bump the k8s example image tag to 1.0.0.

Build verified locally (optimum_keysync-1.0.0 sdist + wheel); 84 tests pass.
@coderabbitai

coderabbitai Bot commented Jun 25, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

This PR adds a GitHub Actions release workflow for published GitHub Releases. The workflow checks that the release tag matches src/optimum_keysync/__init__.py, builds an sdist and wheel, and publishes to PyPI using OIDC Trusted Publishing. It also updates the README release instructions, bumps the package version to 1.0.0, and updates the Kubernetes CronJob image tag to 1.0.0.

Sequence Diagram(s)

sequenceDiagram
  participant GitHubRelease as GitHub Release
  participant ReleaseWorkflow as release workflow
  participant Checkout as actions/checkout
  participant SetupPython as actions/setup-python
  participant Build as python -m build
  participant Publish as pypa/gh-action-pypi-publish
  participant PyPI as PyPI

  GitHubRelease->>ReleaseWorkflow: published event
  ReleaseWorkflow->>Checkout: checkout pinned commit
  ReleaseWorkflow->>SetupPython: install Python 3.12
  ReleaseWorkflow->>ReleaseWorkflow: compare release tag with __version__
  ReleaseWorkflow->>Build: build sdist and wheel
  ReleaseWorkflow->>Publish: publish artifacts via OIDC
  Publish->>PyPI: upload distributions
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Title check ⚠️ Warning The title is relevant to the release changes, but it does not match the required type(domain/pkg): summary format. Rename it to follow type(domain/pkg): short imperative summary using an allowed type such as chore or feat.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/release.yml:
- Line 31: The checkout step in the release workflow is persisting credentials
unnecessarily, so update the actions/checkout usage to disable credential
persistence for this job. Adjust the checkout configuration so the workflow
still fetches the repo but does not keep the token in local git config, and keep
the change scoped to the checkout action invocation in the release job.

In `@README.md`:
- Around line 140-141: The release instructions in the README are pointing to
the wrong version source, since the workflow uses optimum_keysync.__version__
rather than pyproject.toml. Update the release docs to tell maintainers to bump
the version where the package actually reads it, then commit, merge to main, and
create the GitHub Release tagged v<version>; also align the release workflow
reference in .github/workflows/release.yml with the same version source so the
documented steps match the version check.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository: getoptimum/coderabbit/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 25c79856-d533-4307-a7ea-a9529bec773a

📥 Commits

Reviewing files that changed from the base of the PR and between ae5d117 and 1268826.

⛔ Files ignored due to path filters (1)
  • pyproject.toml is excluded by none and included by none
📒 Files selected for processing (4)
  • .github/workflows/release.yml
  • README.md
  • examples/kubernetes/cronjob.yaml
  • src/optimum_keysync/__init__.py

steps:
# Action versions pinned to commit SHAs (tag in the comment) per the
# OpenSSF / GitHub-hardening guidance used across this repo's workflows.
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

Disable checkout credential persistence.

This job never pushes to GitHub, so keeping the checkout token in local git config only increases exposure to later steps and build hooks.

Suggested fix
-      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+        with:
+          persist-credentials: false

As per path instructions, "Check permissions (least privilege) ... Flag secret exposure in logs, overly broad permissions" and zizmor warns "credential persistence through GitHub Actions artifacts (artipacked)."

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
persist-credentials: false
🧰 Tools
🪛 zizmor (1.26.1)

[warning] 31-31: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/release.yml at line 31, The checkout step in the release
workflow is persisting credentials unnecessarily, so update the actions/checkout
usage to disable credential persistence for this job. Adjust the checkout
configuration so the workflow still fetches the repo but does not keep the token
in local git config, and keep the change scoped to the checkout action
invocation in the release job.

Sources: Path instructions, Linters/SAST tools

Comment thread README.md
Comment on lines +140 to +141
1. Bump `version` in `pyproject.toml` and merge to `main`.
2. Publish a GitHub Release tagged `v<version>` (e.g. `v1.0.0`).

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Point the release docs at the real version source.

Line 140 still tells maintainers to bump pyproject.toml, but this PR’s workflow reads optimum_keysync.__version__. Following the README as written will cause the next tagged release to fail the version check. Also at: .github/workflows/release.yml: Line 46.

Suggested fix
-1. Bump `version` in `pyproject.toml` and merge to `main`.
+1. Bump `src/optimum_keysync/__init__.py`'s `__version__` and merge to `main`.

As per path instructions, "Prioritize technical accuracy and copy-pastable commands" and "Flag references to removed APIs, wrong paths, or steps that contradict the repo."

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
1. Bump `version` in `pyproject.toml` and merge to `main`.
2. Publish a GitHub Release tagged `v<version>` (e.g. `v1.0.0`).
1. Bump `src/optimum_keysync/__init__.py`'s `__version__` and merge to `main`.
2. Publish a GitHub Release tagged `v<version>` (e.g. `v1.0.0`).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@README.md` around lines 140 - 141, The release instructions in the README are
pointing to the wrong version source, since the workflow uses
optimum_keysync.__version__ rather than pyproject.toml. Update the release docs
to tell maintainers to bump the version where the package actually reads it,
then commit, merge to main, and create the GitHub Release tagged v<version>;
also align the release workflow reference in .github/workflows/release.yml with
the same version source so the documented steps match the version check.

Source: Path instructions

@CryptoFewka
CryptoFewka merged commit 31a245f into main Jun 25, 2026
3 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.

1 participant