ci: release from main and prepare 0.2.0

[hectorvent]

What

• .releaserc.json / semver.yml: semantic-release runs on pushes to main (was release/* branches), with a concurrency group so runs from merges close together queue instead of racing on the release commit and tag.
• scripts/set_version.py (semantic-release's prepare step): bumps the version in pyproject.toml and the project entry in uv.lock, and uv.lock is now a release asset. CI installs with uv sync --locked, so a release that bumped only pyproject.toml (the old inline prepareCmd) would leave main's CI red after every release.
• publish.yml: a workflow_dispatch with a tag input; the checkout builds that tag. This publishes an existing release tag with the current workflow, the same safety net the Node module needed today.
• pyproject.toml and uv.lock set to 0.2.0, plus a new CHANGELOG.md with the 0.2.0 entry.
• CONTRIBUTING: releases come from main.

Why

PyPI has only 0.1.1, cut from release/0.1.x on 2026-05-02. That branch holds only test-release commits (fix: initial release, fix: second release - test and their chore(release) commits), so 0.1.1 is essentially the first commit. Everything merged to main since has never shipped, notably #1 (new service configs, TLS/storage, with_log_level, the dedicated-network fix).

semantic-release only ran on release/* branches, so it could never ship main.

Why 0.2.0 is cut by hand once

• The 0.1.x tags are not in main's history, so semantic-release on main has no previous release to build on.
• Review and enhance testcontainers-floci-python module #1's subject is not a Conventional Commit, so the commit analyzer would not count it.
• Dry run of this config on main: "No git tag version found on branch main … Analysis of 8 commits complete: no release". So merging this publishes nothing.

After merge:

1. Tag 0.2.0 on the merge commit and create the GitHub release 0.2.0.
2. The release triggers publish.yml, which publishes testcontainers-floci==0.2.0 to PyPI through the trusted publisher that already published 0.1.1.
3. From then on, feat:/fix: merges release automatically from 0.2.0.

release/0.1.x and its tags are left as they are; retiring the branch is a separate call.

Area

Release workflows, version metadata, changelog, CONTRIBUTING. No library code changes.

Tests

• ruff check ., ruff format --check . and uv lock --check pass.
• scripts/set_version.py updates both pyproject.toml and uv.lock (checked on a copy).
• The semantic-release dry run on main with this config: no release.

[greptile-apps]

Confidence Score: 5/5

[High risk] Rewires release automation to publish from main branch.

The PR appears safe to merge; all previous findings are addressed.

What we checked:

• Manual builds require a tag: The checkout prefixes manual inputs with refs/tags/, so branch names do not select branches.
• Rejected locks leave files unchanged: The script checks the lock entry before writing either file. The new test covers this rejection.

Summary

This PR moves automatic releases to main and prepares version 0.2.0.

• Release preparation updates both pyproject.toml and uv.lock.
• Manual publishing selects an existing tag and can also publish to TestPyPI.
• All three previous findings are addressed. No new actionable issues were found.
• The required greptile_confidence label could not be added because GitHub authentication was unavailable.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  Main[Push to main] --> Release[semantic-release]
  Release --> Versions[Update both version files and changelog]
  Versions --> Tag[Commit and create release tag]
  Tag --> Published[Publish GitHub release]
  Published --> Build[Build tagged source]
  Manual[Manual dispatch with existing tag] --> Build
  Build --> PyPI[Publish to PyPI]
  Build --> Test{Pre-release or testpypi selected?}
  Test -->|Yes| TestPyPI[Publish to TestPyPI]

Loading

_{Reviews (2) · Last reviewed commit: "ci: release from main and prepare 0.2.0" · Reviewed by Greptile}