Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 56 minutes and 42 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (3)
📝 WalkthroughWalkthroughVersion bump from 2.1.20 to 2.1.21 across workspace metadata and package configuration, coupled with significant enhancements to the CI publish script to support readme metadata in wheels, implement concurrent PyPI uploads via thread pooling, and add post-upload verification. Changes
Sequence DiagramsequenceDiagram
participant CI as CI/Publish Script
participant Pool as Thread Pool
participant PyPI as PyPI (uv publish)
participant API as PyPI JSON API
participant Out as Output/Logs
CI->>CI: Load wheels from dist/wheels/
CI->>CI: Build task queue (per wheel)
CI->>Pool: Submit concurrent upload tasks
loop For each wheel
Pool->>PyPI: uv publish --check-url WHEEL
PyPI-->>Pool: Success/Failure + output
Pool-->>Out: Log recent output lines
end
Pool-->>CI: All results aggregated
alt Any upload failed
CI->>Out: Exit with failure
else All uploads succeeded
CI->>API: Query PyPI JSON API
API-->>CI: Return published filenames
CI->>CI: Verify expected wheels present
alt Verification passed
CI->>Out: Confirm publication success
else Verification failed
CI->>Out: Exit with verification error
end
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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 |
2.1.20 shipped with mode=0o755 on the `fbuild` / `fbuild-daemon`
console scripts but with external_attr=0x01ed0000 — i.e. the mode
bits were set correctly but the file-type bit (S_IFREG) was zero.
pip's wheel installer calls stat.S_ISREG() on the upper 16 bits of
external_attr before deciding whether to apply the script's mode;
without the IFREG bit that test returns False, pip falls back to
umask defaults (0o644), and the binary lands on disk without +x:
/opt/hostedtoolcache/Python/3.12.13/x64/bin/fbuild:
Permission denied (exit code 126)
Windows doesn't care about exec bits on .exe files, which is why
2.1.20 looked fine on `uv tool install fbuild==2.1.20` on Windows
but was broken for every Linux/macOS user. It's also the root
cause of #129 — #135's "preserve exec bit" fix set
the mode but not the file-type bit.
Reference: uv / ruff / maturin-built wheels all have
external_attr=0x81ed0000 (S_IFREG | 0o755) on their script entries.
Verified locally by rebuilding the Linux x86_64 wheel against the
existing binary artifact: new external_attr=0x81ed0000, IFREG=True.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.1.20 is stuck on PyPI with unusable Linux/macOS wheels (missing S_IFREG on `fbuild` / `fbuild-daemon` script entries → `Permission denied` on every non-Windows install). The fix from the previous commit only takes effect on a fresh release; PyPI does not allow overwriting an existing version's wheel filenames. Release notes vs 2.1.20: - fix(publish): set S_IFREG on wheel script entries so pip applies +x to bundled binaries on Linux/macOS - fix(publish): per-wheel concurrent upload with post-upload verification, so partial uploads never silently succeed Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1.2.12 is the last zccache release that ships broken Linux/macOS wheels — the bundled `zccache` binary lacks +x and every cache operation fails with `Permission denied`. The upstream fix landed in zccache 1.2.13 (zackees/zccache#35: S_IFREG + create_system=3 on wheel script entries). Bumping the floor so fresh pip installs of fbuild 2.1.21 don't pin themselves to a broken zccache. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The fbuild PyPI project page has been blank because the hand-built wheels' METADATA only carried the four required headers (Name, Version, Summary, Requires-Python) with no description body. PyPI falls back to the project's one-line summary when no description is present, so users landing on pypi.org/project/fbuild/ saw one line of text instead of the README. - Add `readme = "README.md"` to `[project]` in pyproject.toml so standard packaging tools (and the inspection snippet below) can discover the README file without guessing. - Teach `read_project_meta()` to load the file when present. - Extend wheel METADATA with `Description-Content-Type: text/markdown` and the README body, per PEP 566. fbuild's Rust crates are not published to crates.io (no `cargo publish` in `ci/publish.py`, no PUBLISHABLE_CRATES list, and none of `fbuild-core`, `fbuild-cli`, etc. exist on crates.io), so no Cargo.toml `readme = "README.md"` lines are needed here. Rides with 2.1.21. Verified: rebuilt the Linux x86_64 wheel locally, METADATA now contains the Description-Content-Type header and a 24 KB markdown body. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2bd0285 to
6652ae5
Compare
Summary by CodeRabbit
Chores
New Features
Bug Fixes