✨ chore(publish): improve PyPI workflow gating and bump logic Add a CI to gate the workflow and skip expensive steps for release commits, preventing double publishing and runs- publish workflow into two jobs (ci -> publish) and publish depend on ci to early exit and clearer job.

[alain-sv]

• Tighten repo-only conditionals and set fetch-depth:0 for full git
  history for version operations.
• OIDC and contents permissions clearer.
• Simplify and harden version bump step:
• standardize step id bump and COMMIT_MESSAGE env.
• detect [MAJOR]/[MINOR]/[PATCH] markers in commit (case-
  insensitive) and to minor.
• emit part to GITHUB_OUTPUT downstream use.
• Update bump/commit behavior - use-actionsbot] identity to make trace
  and avoid ambiguous author info.
• call bump-my-version with the selected part and push follow-tags.
• Remove local version extraction consolidate bump+push.
• Rename step title and Hatch build unchanged.

Motivation: make automated versioning and publishing robust,
prevent accidental double on release commits, and
simplifycommit-message-driven version bumps.

[qodo-code-review]

Review Summary by Qodo

Improve PyPI workflow gating and automate version bumping

✨ Enhancement

Walkthroughs

Description

• Split publish workflow into CI gate and publish jobs
  - CI job skips on release commits to prevent double publishing
  - Publish job depends on CI for clearer execution flow
• Simplify version bump detection with case-insensitive markers
  - Detect [MAJOR]/[MINOR]/[PATCH] in commit messages
  - Default to minor bump if no marker found
• Use github-actions[bot] identity for clearer commit attribution
• Automate CHANGELOG rotation via bump-my-version configuration
• Update python-package workflow to support workflow_call and main branch
• Improve justfile commands for dev setup and release workflow

Diagram

flowchart LR
  A["Push to main"] --> B["CI Job"]
  B --> C{Release commit?}
  C -->|Yes| D["Skip workflow"]
  C -->|No| E["Publish Job"]
  E --> F["Detect bump type"]
  F --> G["Bump version & CHANGELOG"]
  G --> H["Build & publish to PyPI"]

Loading

File Changes

1. .github/workflows/publish-pypi.yml ✨ Enhancement +28/-37

Restructure publish workflow with CI gating

• Split workflow into two jobs: CI gate and publish with dependency
• Add conditional to skip workflow on release commits (chore(release):)
• Simplify version bump detection using case-insensitive regex patterns
• Use github-actions[bot] identity for commits instead of generic github-actions
• Add fetch-depth: 0 for full git history
• Remove manual version extraction steps

.github/workflows/publish-pypi.yml

---

2. .github/workflows/python-package.yml ✨ Enhancement +3/-2

Enable workflow as reusable CI gate

• Add main branch to push and pull_request triggers
• Add workflow_call trigger to enable reusable workflow pattern

.github/workflows/python-package.yml

---

3. docs/CHANGELOG.md Formatting +8/-8

Standardize CHANGELOG version header format

• Standardize version headers with bracket notation [version]
• Update Unreleased header to [Unreleased] format
• Apply consistent formatting across all version entries

docs/CHANGELOG.md

---

View more (2)

4. justfile ✨ Enhancement +18/-6

Improve justfile commands and add ship workflow

• Rename dev-install to install-dev and update to use uv sync
• Rename push-tags to push_tags for consistency
• Add new ship command for production release with bump type embedding
• Update release command to use renamed push_tags

justfile

---

5. pyproject.toml ⚙️ Configuration changes +6/-1

Configure automated CHANGELOG rotation on version bump

• Update bump-my-version commit message format to chore(release): v{new_version}
• Add CHANGELOG.md to bumpversion files configuration
• Configure automatic CHANGELOG rotation with version and date

pyproject.toml

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Rebase after tagging ☑ 🐞 ≡

Description

The publish workflow runs bump-my-version (which commits and tags) and then rebases onto
origin/main; if origin/main advanced, the rebase rewrites the bump commit but leaves the tag
pointing to the pre-rebase commit, so git push --follow-tags may not push the release tag.

Code

.github/workflows/publish-pypi.yml[R71-73]

        git fetch origin main
        git rebase origin/main
        git push --follow-tags
-          # Store the new version
-          echo "NEW_VERSION=$(grep '^VERSION =' src/supervaizer/__version__.py | cut -d '"' -f2)" >> $GITHUB_OUTPUT

Evidence

bump-my-version is configured to create both a commit and a tag, but the workflow rebases after
running it. Rebasing can rewrite the just-created bump commit; tags don’t automatically move with
rebased commits, and --follow-tags only pushes tags reachable from the commit being pushed, so the
release tag can be left behind and never pushed.

.github/workflows/publish-pypi.yml[64-73]
pyproject.toml[128-137]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow tags/releases via `bump-my-version` and then performs `git rebase origin/main`. If main has advanced, the rebase rewrites the bump commit hash while the tag remains on the old commit; `git push --follow-tags` may then fail to push the new release tag.
### Issue Context
`pyproject.toml` config enables both `commit = true` and `tag = true`, so `bump-my-version bump` creates the tag before the rebase step runs.
### Fix Focus Areas
- .github/workflows/publish-pypi.yml[64-73]
- pyproject.toml[128-137]
### Suggested fix approaches (pick one)
1) **Rebase/pull before bumping**:
- `git fetch origin main`
- `git reset --hard origin/main` (or `git pull --rebase origin main`)
- then run `bump-my-version bump ...`
- then `git push --follow-tags`
2) **Keep bump commit stable**:
- Remove the post-bump `git rebase` entirely, and instead fail fast if remote moved (or use `git pull --rebase` before bump).
3) **If you must rebase after bump** (not recommended):
- Move/update the tag to the rebased commit (delete + recreate tag) before pushing, and push tags explicitly.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Double CI on main ☑ 🐞 ➹

Description

On pushes to main, python-package.yml runs as its own workflow and is also invoked as a reusable
workflow from publish-pypi.yml, resulting in two CI executions per push.

Code

.github/workflows/python-package.yml[R8-11]

+    branches: ["develop", "main"]
pull_request:
-    branches: ["develop"]
+    branches: ["develop", "main"]
+  workflow_call:

Evidence

publish-pypi.yml is triggered on push to main and calls ./.github/workflows/python-package.yml
as job ci. Separately, python-package.yml itself is also configured to trigger on push to main,
so both will run for the same event.

.github/workflows/publish-pypi.yml[3-7]
.github/workflows/publish-pypi.yml[12-19]
.github/workflows/python-package.yml[6-12]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
CI runs twice on each push to `main` because `python-package.yml` is both (a) triggered by `push` to `main` and (b) called via `workflow_call` from the publish workflow.
### Issue Context
The publish workflow already uses `python-package.yml` as a reusable workflow job to gate publishing.
### Fix Focus Areas
- .github/workflows/python-package.yml[6-12]
- .github/workflows/publish-pypi.yml[12-19]
### Suggested fix approaches (pick one)
1) **Single source of truth for main CI**:
- Remove `main` from `python-package.yml` `on.push.branches` (and optionally from `pull_request.branches` only if undesired).
- Keep `workflow_call` so publish can run CI.
2) **Keep python-package as standalone on main**:
- Stop calling `python-package.yml` from `publish-pypi.yml` and instead gate publishing via a different mechanism (e.g., split publish into a workflow triggered by `workflow_run` of the standalone CI).
Either approach prevents duplicated CI spend and confusing duplicate checks.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Stale dev-install docs ☑ 🐞 ⚙

Description

The justfile recipe was renamed from dev-install to install-dev, but documentation still
instructs running just dev-install, which will fail for contributors.

Code

justfile[R13-16]

+# Install dev dependencies
+install-dev:
+    uv sync --extra dev

Evidence

The repo now defines install-dev: in justfile, but both CONTRIBUTING.md and GEMINI.md still
reference the removed dev-install recipe name.

justfile[13-16]
CONTRIBUTING.md[15-23]
GEMINI.md[5-12]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Docs instruct `just dev-install`, but the recipe is now named `install-dev`. This breaks the documented setup steps.
### Issue Context
`justfile` removed `dev-install:` and added `install-dev:`.
### Fix Focus Areas
- justfile[13-16]
- CONTRIBUTING.md[15-23]
- GEMINI.md[5-12]
### Suggested fixes
- Update docs to say `just install-dev`.
- Optionally add a backward-compatible alias in `justfile`:
- `dev-install: install-dev`
so existing contributor muscle-memory continues to work.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more