ci: publish to PyPI via Trusted Publishing on GitHub Releases

[sklinglernv]

Sets up automated PyPI publishing for the four workspace packages. Publishing a GitHub Release is the release ceremony — the release's tag is what uv-dynamic-versioning turns into the version, exactly as RELEASING.md already described.

Nothing here can publish anything on merge. publish.yml triggers only on release: published and workflow_dispatch, and no GitHub Release exists yet.

Why Releases rather than tag push

A Release is a tag, so versioning is unchanged. What it adds: notes live with the artifacts, a draft state to fix mistakes before anything fires, and a human click before an upload that can never be undone — PyPI does not allow reusing a version, even after a delete.

Safety gates

A bad upload is permanent, so the build job refuses to hand off unless:

• the built version equals the release tag, and is not a .devN version (which would mean the tag was not reachable from the checked-out commit — the shallow-clone failure mode);
• all four wheels import cleanly in a fresh venv, and nooa --version runs.

One environment per package

Publishing fans out into a 4-way matrix, each job in its own pypi-<package> environment.

PyPI keys a pending trusted publisher on (owner, repo, workflow, environment). Four packages sharing one environment collide — the second registration is rejected with "a pending trusted publisher matching this configuration has already been registered for a different project name", because PyPI cannot tell which project to create on first upload. Distinct environments also give per-package approval gates.

Each job uploads only its own artifacts. The glob anchors on the - before the version, so nooa-* matches the core's files and never nooa_cli-*; verified to split the 8 artifacts exactly 2-per-package.

uv --no-sources

Release builds now pass --no-sources, as the uv packaging guide recommends — it disables tool.uv.sources so the build is exercised the way a non-uv consumer sees it. Relevant here because all three sub-packages resolve the core via nooa = { workspace = true }. The CI build job mirrors the flag so it stays a real canary for release-build breakage.

Verified locally: all four build with --no-sources, twine check passes on all 8 artifacts, and cross-package deps come out as a plain Requires-Dist: nooa with no workspace leakage.

Packaging metadata

Project URLs on all four; classifiers and keywords on the core; READMEs for nooa-memory and nooa-bench, which would otherwise have published blank PyPI pages. nooa-memory's description read "not yet published" — that string is the one-liner PyPI renders under the package name.

Before the first release

• Register pending publishers for all four names (table in RELEASING.md) — environment name differs per package
• Admin: add required reviewers to the pypi-* environments

The environments themselves do not need pre-creating — GitHub creates them on first workflow reference. But an auto-created environment has no protection rules, so an admin should add reviewers before the first real release. A TestPyPI dry run (Actions → Publish → testpypi) is safe unattended.

🤖 Generated with Claude Code

[alessiodevoto]

requires-python = ">=3.12,<3.14" since this depends on nooa-cli that has <3.14

[sklinglernv]

fixed

[alessiodevoto]

Manual dispatch should be only for TestPyPI dry runs, but this also allows real PyPI, maybe to be on the safe side and avoid wrong releases we can do:

options: [testpypi]

and:

publish-pypi:
    if: github.event_name == 'release'

[sklinglernv]

fixed