ci: manage releases with release-please

[IsmaelMartinez]

Moves releases onto release-please, so the tag is created by a merged PR rather than a button.

Why now: v0.44.0 was published with the placeholder tag untagged-64e9bbbb…, which failed Publish's SemVer gate, so nothing reached PyPI or Docker Hub. That is the third release needing a manual fix, after #2573 and #2592. Details in #2885.

• release-type: python updates [project].version in pyproject.toml, the only place the version lives here. The setup.py, setup.cfg and __init__.py updaters are all createIfMissing: false, so their absence is a no-op, and there is no version.py.
• Manifest starts at 0.45.0, matching pyproject.toml and the newest real tag (the draft v0.46.0 is untagged, so it does not count). include-v-in-tag keeps the vX.Y.Z shape publish.yml parses; bump-minor-pre-major keeps features on a minor bump while we are pre-1.0.
• No GITHUB_TOKEN fallback on the token, deliberately: a release created with GITHUB_TOKEN does not trigger other workflows, so Publish would never fire and the tag would ship nothing. The job fails closed if RELEASE_TOKEN is unset. Please sanity-check that secret is scoped for this.
• CHANGELOG.md gets a 0.45.0 heading so release-please has a stable insertion point. Without it the first generated entry lands inside the 2023 archive, under a paragraph saying those entries describe no release after that date. The archive moved to RELEASE_NOTES.md, which already held the v0.7–v0.11 notes.

publish.yml is untouched. It still fires on release: published, and its finalize bump becomes a no-op because release-please has already set the version.

Three things I did not fix here, flagged rather than left implicit:

1. Order of operations. If 0.46.0 is published before this merges, .release-please-manifest.json must be bumped to 0.46.0 in the same breath. Manifest mode treats that file as the current version, so leaving it at 0.45.0 makes the next release PR propose 0.46.0 again and collide with the existing tag.
2. Prerequisite cleanup. Done since this was opened: v0.44.0 is tagged and the runaway v64.1.0 draft is gone. What remains is the Release Drafter draft v0.46.0 (untagged, target main). Once the drafter workflow is removed nothing rewrites it, so either publish it as 0.46.0 and bump the manifest as in point 1, or delete it before release-please opens its first release PR.
3. Two things Release Drafter did that this does not. Its autolabeler applied type labels from PR titles, and $CHANGES listed every merged PR regardless of title format. release-please silently drops commits whose subject is not a conventional commit, and those also do not bump the version — 7 of the last 96 qualify, including Fix: log dropped inline comments (#2876) and enable bedrock access through private VPC endpoint (#2663). Worth a title check in CI; happy to follow up with one plus an actions/labeler config.

Happy to split the Release Drafter removal into its own PR if you would rather land the config first.

Refs #2885

[IsmaelMartinez]

/agentic_review

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 📜 Skill insights (0)

1. Release pull requests fail CI 🐞 Bug ≡ Correctness

Description

The root release-please package updates pyproject.toml but has no updater for the project version
recorded in uv.lock. Every generated version-bump pull request therefore leaves the lockfile at
the previous version, causing uv lock --check in pull-request CI to fail and block the release
flow.

Code

release-please-config.json[R5-6]

+      "release-type": "python",
+      "changelog-path": "CHANGELOG.md",

Evidence

The new configuration selects the Python release updater but provides no lockfile updater. The
repository's lockfile independently stores the exact root package version, pull-request CI validates
that lockfile, and the existing publish finalizer explicitly runs uv lock after changing the
project version, demonstrating that both files must be synchronized.

release-please-config.json[3-12]
pyproject.toml[5-7]
uv.lock[2464-2467]
.github/workflows/build-and-test.yaml[19-23]
.github/workflows/publish.yml[272-290]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Release Please updates the project version in `pyproject.toml` without updating the corresponding root-package version in `uv.lock`. Generated release pull requests consequently fail the existing `uv lock --check` CI step.

## Fix Focus Areas
- release-please-config.json[3-12]
- uv.lock[2464-2467]
- .github/workflows/build-and-test.yaml[19-23]

## Recommended Fix
Extend the release automation so each generated release pull request also updates or regenerates `uv.lock` alongside `pyproject.toml`. Ensure the resulting pull request contains the new `pr-agent` version in both files and passes `uv lock --check`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

• Author self-review: I have reviewed the code review findings, and addressed the relevant ones.

Context sources

✅ Tickets: 🎫 v0.40.0 and v0.41.0 never reached PyPI: release token's PyPI account has no verified primary email 🎫 v0.44.0 was published without a tag, so nothing shipped 🎫 v0.41.1 Docker images not yet available on Docker Hub

Review mode: ⚖️ Balanced: This changes release automation, versioning, tags, credentials, and workflow triggers, creating substantial CI and publication risk across multiple files, but not enough independent logic density to warrant extended review.

Tip of the day

💡 Did you know, you can ask Qodo to dismiss a finding you disagree with, with your reason on record

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous reviews

Review updated until commit 2603a93 ⚖️ Balanced

Results up to commit N/A

Sorry, something went wrong

We weren't able to complete the code review on our side. Please try again manually by commenting /agentic_review on this PR.

[naorpeled]

Let's talk about this in our next meeting 🙏

[qodo-free-for-open-source-projects]

1. Release pull requests fail ci 🐞 Bug ≡ Correctness

The root release-please package updates pyproject.toml but has no updater for the project version
recorded in uv.lock. Every generated version-bump pull request therefore leaves the lockfile at
the previous version, causing uv lock --check in pull-request CI to fail and block the release
flow.

Agent Prompt

## Issue description
Release Please updates the project version in `pyproject.toml` without updating the corresponding root-package version in `uv.lock`. Generated release pull requests consequently fail the existing `uv lock --check` CI step.

## Fix Focus Areas
- release-please-config.json[3-12]
- uv.lock[2464-2467]
- .github/workflows/build-and-test.yaml[19-23]

## Recommended Fix
Extend the release automation so each generated release pull request also updates or regenerates `uv.lock` alongside `pyproject.toml`. Ensure the resulting pull request contains the new `pr-agent` version in both files and passes `uv lock --check`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit 2603a93