Prepare release 0.4.2 - #34
Conversation
Reviewer's GuideRelease 0.4.2 prepares kimi-bridge for new tested Kimi Code versions, consolidates compatibility metadata into a single release-history map with automation to bump patch versions and publish releases, improves install/setup documentation for human and agent operators, tightens distribution checks, and refines startup error reporting. File-Level Changes
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Warning Review limit reached
Next review available in: 45 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (7)
📝 WalkthroughWalkthroughThe PR replaces the standalone supported-version manifest with compatibility-map history, updates promotion automation and release workflows, adds the 0.4.2 compatibility entry, rewrites installation and setup-agent guidance, and reports startup ChangesCompatibility release pipeline
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant PromotionPR
participant ReleaseWorkflow
participant GitHubRelease
participant PublishWorkflow
PromotionPR->>ReleaseWorkflow: merged marked compatibility promotion
ReleaseWorkflow->>GitHubRelease: create release with computed tag
ReleaseWorkflow->>PublishWorkflow: pass release tag
PublishWorkflow->>GitHubRelease: upload distributions and hashes
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Hey - I've found 2 issues
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="scripts/check_kimi_compatibility.py" line_range="56-61" />
<code_context>
PROMOTION_MARKER = "<!-- kimi-bridge:compatibility-promotion -->"
DRIFT_MARKER = "<!-- kimi-bridge:upstream-drift -->"
DRIFT_LABEL = "upstream-drift"
+PROJECT_VERSION_RE = re.compile(
+ r'(?ms)^(\[project\]\n.*?^version = ")(\d+\.\d+\.\d+)(")$'
+)
+LOCKED_PROJECT_RE = re.compile(
+ r'(?ms)^(\[\[package\]\]\nname = "kimi-bridge"\nversion = ")'
+ r'(\d+\.\d+\.\d+)(")$'
+)
</code_context>
<issue_to_address>
**suggestion (bug_risk):** The version extraction regexes are quite brittle and could be replaced with TOML parsing for robustness.
These regexes tightly couple release prep to the exact current layout of `pyproject.toml` and `uv.lock` (spacing, ordering, absence of comments/extra fields). Small, reasonable edits (comments, reordered fields, or formatter output) would cause version extraction to fail and raise `RuntimeError`s.
Given `prepare_compatibility_release` is already doing structured work and `tomllib` is available, consider parsing both files as TOML and reading/updating the version fields programmatically instead of matching the entire file with regexes. That will make the process far more resilient to benign formatting changes.
Suggested implementation:
```python
import tomllib
PROMOTION_MARKER = "<!-- kimi-bridge:compatibility-promotion -->"
DRIFT_MARKER = "<!-- kimi-bridge:upstream-drift -->"
DRIFT_LABEL = "upstream-drift"
def get_project_version(pyproject: str) -> str:
"""Parse pyproject.toml and return the project version."""
try:
data = tomllib.loads(pyproject)
except tomllib.TOMLDecodeError as exc:
raise RuntimeError("Failed to parse pyproject.toml as TOML") from exc
try:
return data["project"]["version"]
except KeyError as exc:
raise RuntimeError(
"Unable to determine project version from pyproject.toml "
"(expected [project].version)"
) from exc
def get_locked_project_version(
uv_lock: str,
project_name: str = "kimi-bridge",
) -> str:
"""Parse uv.lock and return the locked version for the given project."""
try:
data = tomllib.loads(uv_lock)
except tomllib.TOMLDecodeError as exc:
raise RuntimeError("Failed to parse uv.lock as TOML") from exc
packages = data.get("package", [])
if not isinstance(packages, list):
raise RuntimeError("Unexpected uv.lock format: 'package' is not a list")
for package in packages:
if not isinstance(package, dict):
continue
if package.get("name") == project_name:
version = package.get("version")
if version:
return version
break
raise RuntimeError(
f"Unable to determine locked version for {project_name!r} from uv.lock "
"(expected [[package]] with matching name and version)"
)
_BEARER_RE = re.compile(r"(?i)(authorization\s*:\s*bearer\s+)[^\s\"']+")
_FRAGMENT_TOKEN_RE = re.compile(r"(?<=#token=)[A-Za-z0-9_-]+")
```
To fully adopt TOML-based version handling and remove the brittle regex dependency, you should also:
1. **Remove any remaining uses of `PROJECT_VERSION_RE` and `LOCKED_PROJECT_RE`** in `prepare_compatibility_release` (and elsewhere, if present).
2. **Replace version extraction logic** inside `prepare_compatibility_release` with calls to the new helpers, for example:
- `current_version = get_project_version(pyproject)`
- `locked_version = get_locked_project_version(uv_lock)`
3. If `prepare_compatibility_release` also **updates** the version in `pyproject` and `uv_lock`, introduce complementary helper(s) that:
- Parse the TOML with `tomllib.loads`.
- Mutate `data["project"]["version"]` and the appropriate `[[package]]`'s `"version"`.
- Serialize back to TOML (e.g. via an existing TOML writer/formatter in your codebase, or a chosen library), instead of doing regex `sub` on the raw text.
4. Once the above is done and the code compiles, you can safely delete any dead constants or imports that were only used by the removed regex-based approach.
</issue_to_address>
### Comment 2
<location path="INSTALL_AI.md" line_range="36" />
<code_context>
-If uv is missing: **EXTERNAL(https://docs.astral.sh/uv/getting-started/installation/) → return with `uv --version` working.**
+- **Done:** Kimi Code completed a real prompt, the platform delivered an allowlisted message, and kimi-bridge returned a complete reply.
+- **Paused:** a named user-only action, approval, publication review, or external wait is outstanding. State exactly how to resume and what you will verify.
+- **Unsupported:** the selected environment or platform cannot satisfy a documented requirement. You can still use your own knowledge to assit the user as per their requests.
+- **Aborted:** setup stopped at the user's request. Remove only artifacts created during this setup. Never remove pre-existing configuration, state, workspaces, sessions, bot applications, webhooks, or service files without separate explicit approval for the named targets.
</code_context>
<issue_to_address>
**issue (typo):** Typo in 'assit' – should be 'assist'.
This occurs in the Unsupported outcome description; please update the spelling there.
```suggestion
- **Unsupported:** the selected environment or platform cannot satisfy a documented requirement. You can still use your own knowledge to assist the user as per their requests.
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (1)
src/kimi_bridge/__main__.py (1)
331-333: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winAvoid converting every
RuntimeErrorinto a user-facing configuration error.This also hides unexpected programming and cleanup failures by removing their traceback. Prefer a dedicated startup/operational exception, or wrap only the known expected failures, while allowing unrelated
RuntimeErrordefects to remain diagnosable.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/kimi_bridge/__main__.py` around lines 331 - 333, Update the exception handling in the main startup flow so only known startup or operational failures are converted into the user-facing “kimi-bridge” error and exit code 1. Remove the broad RuntimeError catch, or replace it with a dedicated expected-failure exception, while preserving handling for KimiServerError, ValueError, and TypeError as appropriate and allowing unrelated RuntimeError exceptions to propagate with their traceback.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/kimi-drift-release.yml:
- Around line 34-37: Update the actions/checkout step in
.github/workflows/kimi-drift-release.yml lines 34-37 within create-release to
set persist-credentials to false. Apply the same change to the checkout step in
.github/workflows/release.yml lines 33-36 within build; no other workflow
behavior should change.
- Around line 10-13: Move the workflow permissions from the top level into the
publish job, granting it only the actions, contents, and id-token permissions
required by its reusable release workflow. Remove the top-level id-token: write
grant, and keep create-release scoped to contents: write.
In @.github/workflows/release.yml:
- Around line 37-40: Update the release workflow’s astral-sh/setup-uv step to
disable caching by setting enable-cache to false, ensuring release artifacts do
not reuse caches from other workflow runs.
In `@INSTALL_AI.md`:
- Around line 30-38: Correct the spelling in the Unsupported outcome by changing
“assit” to “assist,” without modifying the surrounding completion-outcome text.
In `@scripts/check_kimi_compatibility.py`:
- Around line 800-849: The release preparation flow should eliminate the race
between reading files and resetting AUTOMATION_BRANCH. Update the code around
current, _branch_sha, and _set_automation_branch to obtain the default-branch
commit SHA before fetching the three files, then read their contents from that
exact commit (using the supported ref mechanism), ensuring each PUT uses SHAs
matching the reset branch.
---
Nitpick comments:
In `@src/kimi_bridge/__main__.py`:
- Around line 331-333: Update the exception handling in the main startup flow so
only known startup or operational failures are converted into the user-facing
“kimi-bridge” error and exit code 1. Remove the broad RuntimeError catch, or
replace it with a dedicated expected-failure exception, while preserving
handling for KimiServerError, ValueError, and TypeError as appropriate and
allowing unrelated RuntimeError exceptions to propagate with their traceback.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: cf445f7a-78ce-44fc-acbd-d49b2ea62147
⛔ Files ignored due to path filters (1)
uv.lockis excluded by!**/*.lock
📒 Files selected for processing (19)
.github/workflows/kimi-drift-release.yml.github/workflows/kimi-drift.yml.github/workflows/release.ymlAGENTS.mdINSTALL.mdINSTALL_AI.mddocs/ARCHITECTURE.mddocs/CONFIGURATION.mdpyproject.tomlscripts/check_distribution.pyscripts/check_kimi_compatibility.pysrc/kimi_bridge/__main__.pysrc/kimi_bridge/compatibility-map.jsonsrc/kimi_bridge/compatibility.pysrc/kimi_bridge/supported-kimi-code-versions.jsontests/conftest.pytests/test_compatibility.pytests/test_compatibility_check.pytests/test_main.py
💤 Files with no reviewable changes (1)
- src/kimi_bridge/supported-kimi-code-versions.json
Summary
Validation
uv lock --checkuv run --locked python scripts/check_release.pyuv run --locked pytest -q— 357 passeduv run --locked ruff check .git diff --checkuv build --no-sourcesuv run --locked twine check <isolated-dist>/*uv run --locked python scripts/check_distribution.py --dist-dir <isolated-dist>Release plan
After this PR merges, publish
v0.4.2at the exact merged commit. The Release workflow will build and attach distributions, then request deployment through the protectedpypienvironment. Publication will be followed by provenance, digest, metadata, and clean-install verification.Summary by Sourcery
Prepare kimi-bridge 0.4.2 as a compatibility-focused release and wire automated GitHub Releases and PyPI publication around the compatibility map.
New Features:
Enhancements:
Build:
CI:
Documentation:
Tests:
Chores:
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Chores