LCORE-1966: Removed lxml#1699
Conversation
|
Warning Rate limit exceeded
To continue reviewing without waiting, purchase usage credits in the billing tab. ⌛ 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: ASSERTIVE Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (5)
WalkthroughDependencies are reorganized across the project: ChangesDependency Updates
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
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.
Actionable comments posted: 1
🤖 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 `@requirements.hashes.wheel.txt`:
- Around line 259-260: The zipp wheel entry has an incorrect SHA256 hash (the
line containing "zipp==3.23.0" with the hash sha256:2f6742e0...) — regenerate
the hashes file and replace this entry with the correct hash by running the
hash-generation step again; run the universal hash generator (uv) with
--generate-hashes --universal to recreate requirements.hashes.wheel.txt so the
"zipp==3.23.0" entry matches the PyPI-published sha256 (and update any other
mismatched entries produced by the run).
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: e81a91b0-a96b-47c6-a29c-993b68cabf58
⛔ Files ignored due to path filters (1)
uv.lockis excluded by!**/*.lock
📒 Files selected for processing (4)
.tekton/lightspeed-stack-pull-request.yaml.tekton/lightspeed-stack-push.yamlpyproject.tomlrequirements.hashes.wheel.txt
💤 Files with no reviewable changes (1)
- pyproject.toml
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (12)
- GitHub Check: unit_tests (3.13)
- GitHub Check: unit_tests (3.12)
- GitHub Check: build-pr
- GitHub Check: Pylinter
- GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
- GitHub Check: E2E: library mode / ci / group 1
- GitHub Check: E2E: server mode / ci / group 1
- GitHub Check: E2E: server mode / ci / group 2
- GitHub Check: E2E: library mode / ci / group 2
- GitHub Check: E2E: library mode / ci / group 3
- GitHub Check: E2E: server mode / ci / group 3
- GitHub Check: E2E Tests for Lightspeed Evaluation job
🔇 Additional comments (2)
.tekton/lightspeed-stack-pull-request.yaml (1)
61-61: LGTM —lxmlremoved andmaturinadded consistently withlightspeed-stack-push.yaml..tekton/lightspeed-stack-push.yaml (1)
53-53: ⚡ Quick winNo action needed —
protobufandfilelockare covered by hermetic prefetch viarequirements.hashes.source.txt(lines 410 and 790 respectively), not through the binary wheels path. The hermetic build system supports both source and binary distributions; these packages are correctly handled as source distributions and will not cause prefetch failures.
| zipp==3.23.0 \ | ||
| --hash=sha256:2f6742e089020240e014478d428fd79059270c56a2f7947d37c6f1d2ae639174 No newline at end of file | ||
| --hash=sha256:2f6742e089020240e014478d428fd79059270c56a2f7947d37c6f1d2ae639174 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Fetch the zipp 3.23.0 wheel hash from PyPI JSON API and compare
curl -s "https://pypi.org/pypi/zipp/3.23.0/json" \
| python -c "
import json, sys
data = json.load(sys.stdin)
for f in data['urls']:
if f['filename'].endswith('.whl'):
print(f['filename'], '->', f['digests']['sha256'])
"Repository: lightspeed-core/lightspeed-stack
Length of output: 173
The zipp==3.23.0 wheel hash is incorrect and does not match the PyPI-published artifact.
The hash in the file (sha256:2f6742e089020240e014478d428fd79059270c56a2f7947d37c6f1d2ae639174) does not match the official hash on PyPI (sha256:071652d6115ed432f5ce1d34c336c0adfd6a884660d1e9712a256d3d3bd4b14e).
Regenerate requirements.hashes.wheel.txt using uv with the --generate-hashes --universal flags to ensure all hashes are correct and match the published artifacts.
🤖 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 `@requirements.hashes.wheel.txt` around lines 259 - 260, The zipp wheel entry
has an incorrect SHA256 hash (the line containing "zipp==3.23.0" with the hash
sha256:2f6742e0...) — regenerate the hashes file and replace this entry with the
correct hash by running the hash-generation step again; run the universal hash
generator (uv) with --generate-hashes --universal to recreate
requirements.hashes.wheel.txt so the "zipp==3.23.0" entry matches the
PyPI-published sha256 (and update any other mismatched entries produced by the
run).
7a8a0d0 to
712422b
Compare
712422b to
541965f
Compare
Description
LCORE-1966: Removed
lxmlType of change
Tools used to create PR
Related Tickets & Documents
Summary by CodeRabbit