ci: auto-publish dev release to PyPI on every commit to main

[samsja]

Summary

• New workflow .github/workflows/publish-dev.yml runs on every push to main.
• It tags the commit as renderers-v<next-patch>.dev<N> (where N = commits since the latest non-prerelease tag) and publishes the wheel to PyPI as a pre-release.
• Builds run from the freshly-created tag so hatch-vcs resolves a clean PEP 440 version (no +gHASH local segment that PyPI rejects).
• Mirrors the build → publish split from publish.yml so OIDC stays scoped to the publish job only.

Notes

• Reuses the existing pypi-prod environment / trusted publisher. Confirm the PyPI Trusted Publisher allows publish-dev.yml as a workflow name — if it's pinned to publish.yml, the entry needs to be added.
• The tag job pushes with GITHUB_TOKEN, which deliberately does not re-trigger publish.yml (avoids double-publish).
• Counter is derived from git rev-list --count <release>..HEAD, so each main commit maps to a unique dev version even across reruns.

Test plan

• Merge to main and confirm a renderers-v0.1.8.devN tag appears and a matching pre-release version lands on PyPI.
• Verify the next commit increments N and publishes cleanly.
• Confirm publish.yml does not also fire from the auto-pushed tag.

🤖 Generated with Claude Code

---

Note

Medium Risk
Automates tagging and publishing to the production PyPI project on every main push; mis-tagging, trusted publisher config, or workflow bugs could create unintended public prereleases.

Overview
Adds a new GitHub Actions workflow, publish-dev.yml, that runs on every push to main and automatically creates a renderers-v<next-patch>.dev<N> tag based on the latest non-prerelease release tag and commit count.

The workflow then builds the wheel from that tag (to ensure a clean PEP 440 version) and publishes the resulting artifacts to PyPI using the existing pypi-prod OIDC/trusted publisher setup, keeping the build→publish job split so only the publish job has id-token: write.

^{Reviewed by Cursor Bugbot for commit 73aa68c. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Auto-publish dev releases to PyPI on every commit to main

Adds a publish-dev.yml GitHub Actions workflow that runs on every push to main.

• Computes the next dev tag (renderers-v<NEXT>.dev<N>) from the latest non-prerelease tag, bumping patch and using commit count since last release as N.
• Creates and pushes the tag if it does not exist, then builds the package from that tag using uv build.
• Publishes the resulting wheel to PyPI as a pre-release via OIDC (pypa/gh-action-pypi-publish).
• Concurrency is scoped per ref with cancel-in-progress: false to avoid dropped publishes.

^{Macroscope summarized 73aa68c.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR adds automated publishing to PyPI on every main branch commit. Changes to production deployment automation that affect public package registries warrant human review to verify the versioning and publish configuration.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 73aa68c. Configure here.}

[cursor]

pipefail makes grep abort before empty-check runs

Medium Severity

When all renderers-v* tags are pre-release (or none exist), grep -Ev filters every line and exits with code 1. Because set -euo pipefail is active, the pipeline on lines 35–37 aborts the script immediately — the if [ -z "$LATEST_RELEASE" ] guard on line 38 is never reached, so the friendly error message is dead code. The job fails with a confusing, unexplained error instead. Appending || true to the pipeline (or wrapping the grep in { grep ... || true; }) would let the empty-check execute as intended.

 

^{Reviewed by Cursor Bugbot for commit 73aa68c. Configure here.}