This repository uses a Python-first release flow.
The only release authority is:
python-semantic-release
Version source of truth:
pyproject.toml
Releases are cut from:
main
feat:-> minor bumpfix:-> patch bumpperf:-> patch bumpfeat!:/fix!:/BREAKING CHANGE:-> major bump
Examples:
feat: add new retrieval workflow
fix: correct docker image tag handling
feat!: replace legacy release system
Each real release can produce:
- a git tag like
v1.48.2 - updated
CHANGELOG.md - updated version in
pyproject.toml - a GitHub release
- a PyPI package release
- compose bundle assets attached to the GitHub release
Docker image builds are driven directly by the main release workflow after a successful semantic release.
Release flow:
python-semantic-releasecomputes and creates the release tag- Python package artifacts are built and published
- compose bundles are attached to the GitHub release
- Docker images are built and pushed in the same workflow using the released tag
This avoids the GitHub Actions limitation where tags created by GITHUB_TOKEN do not reliably trigger downstream workflows.
The Docker workflow builds and pushes:
talk2aiagents4pharmatalk2biomodelstalk2scholarstalk2knowledgegraphs
CPU/GPU variants are preserved where configured by the workflow.
The standalone docker_build.yml workflow remains available for manual or tag-based rebuilds, but normal releases no longer depend on it being triggered by a separate workflow event.
Compose bundles are packaged during the main release workflow and uploaded as release assets.
They do not own the GitHub release body and do not append large repeated release text.
Before changing release behavior:
uv sync --extra dev
uv run semantic-release --version
uv run semantic-release version --help
uv build
uv run twine check dist/*