Release job

[ejfine]

Why is this change necessary?

The template had no Release workflow. The existing Publish / Publish to Staging workflows re-run lint/test/build themselves, duplicating everything CI already does for the commit. We want a release path that instead relies on a passing CI run — modeled on the copier-nuxt-python-intranet-app release.yaml — while publishing to PyPI (using the existing publish.yaml as the PyPI reference).

While wiring this up we also found that instantiated repos hit pylint R0801 duplicate-code between git_tag.py and extract_project_version.py, because this repo carried a pre-refactor fork of git_tag.py (symlinked from copier_template_resources/) that parsed pyproject.toml itself.

How does this change address the issue?

• CI builds the distribution. Added a build job to ci.yaml.jinja that runs uv build --no-sources and uploads a python-package-distributions artifact (if-no-files-found: error), wired into workflow-summary (needs + fail-check).
• New release.yaml.jinja. Manual workflow_dispatch with a dry_run input, generated for both libraries and executables. A guard job requires the ci.yaml run for the current commit to be completed/success (including the workflow-summary job), extracts the version via extract_project_version.py, and confirms the tag is absent — real releases must run from main. The flow then branches on deploy_as_executable:
  • Library: download the CI-built dist (never rebuilds), publish to Test PyPI and verify a fresh install, push the v<version> tag, publish to PyPI and verify again, then create a GitHub Release with generated notes.
  • Executable: push the v<version> tag, download every exe-{os}-{python} artifact the CI executable job built, package each (tar on Linux / zip on Windows), and attach them all to a GitHub Release. No PyPI publish.
    All tag/publish/release jobs are skipped on dry_run.
• Aligned git_tag.py with base/nuxt. Replaced the local fork with the base version (--version required, no pyproject.toml parsing), and collapsed the copier_template_resources/ symlink into a real file at template/.github/workflows/git_tag.py (matching its sibling extract_project_version.py). Updated all call sites in publish.yaml and release.yaml to source the version from extract_project_version.py and pass --version.
• Docs. Documented the Release workflow in the generated README, plus a TODO to eventually merge Publish / Publish to Staging into Release.

What side effects does this change have?

• CI now has an extra build job on every run (gated {% if not is_frozen_executable %} to match publish.yaml).
• git_tag.py's CLI changed: --version is now required and it no longer prints/parses the version. Any external caller relying on the old no-arg print behavior must switch to extract_project_version.py.
• create-tag gained a needs dependency (guard in release.yaml, get-values in publish.yaml) to obtain the version.
• template/.github/workflows/git_tag.py changed from a symlink to a regular file; copier_template_resources/git_tag.py was deleted.

How is this change tested?

Rendered the template with copier (data1 / PyPI) and verified:

• ci.yaml, release.yaml, publish.yaml all parse as YAML; job graph, needs, and dry_run guards asserted correct.
• All git_tag.py call sites pass --version; version sourced from extract_project_version.py.
• pylint on the rendered scripts: 10.00/10 (previously exit 8 / R0801). ruff and pyright pass on the source git_tag.py.
• CodeArtifact conditional branches render structurally (kept for parity so existing CodeArtifact users aren't broken).

Final enforcement happens in the lint-matrix CI job, which generates across data1/2/3 and runs pre-commit on the output.

Other

• Fixed a pre-existing template bug: is_frozen_executable (used to gate entrypoint.py, main.py, publish.yaml, publish_to_staging.yaml) is undefined and evaluates falsy — so executable projects shipped with no entrypoint.py/main.py yet still got PyPI publish workflows. Renamed all guards (plus the CI build job) to the real deploy_as_executable question. release.yaml is intentionally ungated — it serves both cases and branches internally; publish.yaml / publish_to_staging.yaml stay library-only. Verified renders: executables now get entrypoint.py/main.py, no publish, and a release.yaml that attaches the CI-built executables; libraries get publish/release + the CI build job and no entrypoint/main.
• Test-data coverage gap (follow-up): after the fix, no tests/copier_data file is PyPI + library (data1/data3 = PyPI + executable, data2 = CodeArtifact + library), so lint-matrix no longer exercises the PyPI-library publish/release path. Consider a data file with python_package_registry: PyPI and deploy_as_executable: no.
• release.yaml's create-tag pushes the tag before publish-to-primary; the GitHub Release step then attaches to that existing tag (softprops/action-gh-release handles a pre-existing tag gracefully — no conflict).

[coderabbitai]

Warning

Review limit reached

@ejfine, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 58 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: b42e3533-4f16-4125-99f3-dc7060ac2053

📥 Commits

Reviewing files that changed from the base of the PR and between 14aa2a6 and 0988527.

📒 Files selected for processing (13)

• .config/.copier-answers.yml
• .config/.copier-managed-files.json
• copier_template_resources/git_tag.py
• template/.github/workflows/ci.yaml.jinja
• template/.github/workflows/extract_project_version.py
• template/.github/workflows/git_tag.py
• template/.github/workflows/git_tag.py
• template/.github/workflows/release.yaml.jinja
• template/.github/workflows/{% if not deploy_as_executable %}publish.yaml{% endif %}.jinja
• template/.github/workflows/{% if not deploy_as_executable %}publish_to_staging.yaml{% endif %}.jinja
• template/README.md.jinja
• template/src/{% if deploy_as_executable %}entrypoint.py{% endif %}.jinja
• template/src/{{ package_name.replace('-', '_') }}/{% if deploy_as_executable %}main.py{% endif %}.jinja

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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