fix(ci): disable build in semantic-release action, build in CI

[jbdevprimary]

Problem

PR #21 failed during release with:

CalledProcessError: Command 'uv build' returned non-zero exit status 127.

Root cause: The Docker container doesn't have installed.

Solution

Decouple building from versioning:

1. **Set ** in python-semantic-release action
2. Add separate build step after version bump (runs in CI environment with uv)
3. **Remove ** from pyproject.toml (not needed)

Benefits

✅ Builds happen in properly configured CI environment
✅ Follows separation of concerns pattern
✅ semantic-release focuses on versioning only
✅ No dependency on tools in action's container

Testing

This is a fix: commit - will trigger patch release when merged.

Flow:

1. semantic-release bumps version
2. uv build creates wheel/sdist
3. PyPI publish uploads artifacts
4. GitHub release created with artifacts

Refs #21

---

Note

Moves package build out of python-semantic-release and into the CI workflow to ensure builds run in the configured environment.

• In ci.yml, set python-semantic-release build: false and add a conditional uv build step after versioning; keep PyPI and GitHub Releases publish steps gated on released
• In pyproject.toml, remove build_command, simplify release commit_message, and drop changelog.template_dir to align with CI-driven builds

^{Written by Cursor Bugbot for commit 08de718. This will update automatically on new commits. Configure here.}

[jbdevprimary]

/gemini review

[gemini-code-assist]

Code Review

This pull request correctly addresses a CI failure by moving the package build step out of the python-semantic-release action and into a dedicated CI step. The corresponding changes in pyproject.toml to disable the build command are appropriate. I have raised one point of feedback concerning the removal of the template_dir configuration for the changelog, as this could be an unintended change that alters the changelog format. Otherwise, the changes are a solid improvement to the release workflow.

[gemini-code-assist]

The removal of template_dir causes python-semantic-release to revert to its default changelog template, which will likely alter the formatting of CHANGELOG.md in future releases. This change appears unrelated to the primary goal of fixing the CI build process and might be an unintended side-effect. While using the default template may be acceptable, this is a significant change to the project's release artifact generation that should be deliberate.

[jbdevprimary]

🤖 Agent Handoff: @cursor

Enterprise Dashboard: jbcom/control-center#505

Context

CI fix for semantic-release. Part of extended-data-library 1.0 stabilization.

Your Responsibilities

1. Handle ALL AI PR feedback
2. Fix CI if failing
3. Merge to unblock docs: final status report for 1.0 stabilization effort #18 (1.0 stabilization docs)

Related

• docs: final status report for 1.0 stabilization effort #18: Final status report for 1.0 - merge after this

Please respond with status.

[jbdevprimary]

Addressing @gemini-code-assist's feedback: The template_dir = "templates" configuration was removed because the templates directory does not exist in the repository root (confirmed via ls). Keeping this configuration caused errors in python-semantic-release. If custom templates are needed in the future, the directory should be created first. I've also updated the workflow to use softprops/action-gh-release for more reliable artifact uploads after the build step.

[gemini-code-assist]

Thanks for the detailed explanation, @jbdevprimary! Your reasoning for removing template_dir = "templates" is perfectly sound; it's always best to remove configurations that point to non-existent resources and cause errors.

Regarding the update to use softprops/action-gh-release, that's a solid choice for ensuring reliable artifact uploads in your CI/CD pipeline. It's a widely used and robust action for managing GitHub releases.