LCORE-1610: Updated Konflux dependencies#1424
Conversation
WalkthroughModify Tekton pipeline prefetch package lists (remove Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Possibly related PRs
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@requirements.hashes.source.txt`:
- Around line 295-297: Lockfile drift: google-cloud-resource-manager is pinned
to 1.17.0 in requirements.hashes.source.txt but uv.lock has 1.16.0; choose the
intended version (preferably 1.17.0 to match requirements.hashes.source.txt) and
regenerate/sync uv.lock using the project's lockfile generator so the package
version and hashes match; after regeneration, verify uv.lock now lists
google-cloud-resource-manager==1.17.0 with the same sha256 hashes as in
requirements.hashes.source.txt and commit the updated uv.lock.
🪄 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: 4c87bf31-8b12-4d95-b73f-7d5090201d90
📒 Files selected for processing (4)
.tekton/lightspeed-stack-pull-request.yaml.tekton/lightspeed-stack-push.yamlrequirements.hashes.source.txtrequirements.hashes.wheel.txt
💤 Files with no reviewable changes (1)
- requirements.hashes.wheel.txt
📜 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). (5)
- GitHub Check: build-pr
- GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
- GitHub Check: E2E: library mode / ci
- GitHub Check: E2E: server mode / ci
- GitHub Check: E2E Tests for Lightspeed Evaluation job
🔇 Additional comments (11)
.tekton/lightspeed-stack-push.yaml (1)
53-53:prefetch-inputpackage update looks structurally correct.The updated package string at Line 53 remains valid within the existing JSON payload and Tekton parameter shape.
.tekton/lightspeed-stack-pull-request.yaml (1)
61-61:prefetch-inputdependency list update is well-formed.Line 61 keeps the expected format and integrates cleanly with the existing pipeline parameter payload.
requirements.hashes.source.txt (9)
35-61:chardetbump/hash refresh looks good.Version and hash block at Lines 35-61 appears consistently regenerated.
289-291:google-cloud-aiplatformupdate is consistent.The version/hash pair at Lines 289-291 looks correct for a lock refresh.
301-303:googleapis-common-protosbump/hash refresh looks valid.
501-503:openaiversion/hash update looks consistent.
639-641:proto-plusbump and hashes look properly refreshed.
732-734:pythainlpupdate appears clean and consistent.
741-855:regexblock refresh looks internally consistent.Large hash-set refresh at Lines 741-855 appears correctly regenerated for the pinned version.
856-858:requestspin/hash update looks properly formed.
868-870:sse-starletteversion/hash update is consistent.
| google-cloud-resource-manager==1.17.0 \ | ||
| --hash=sha256:0f486b62e2c58ff992a3a50fa0f4a96eef7750aa6c971bb373398ccb91828660 \ | ||
| --hash=sha256:e479baf4b014a57f298e01b8279e3290b032e3476d69c8e5e1427af8f82739a5 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Source hash pin:"
rg -n '^google-cloud-resource-manager==' requirements.hashes.source.txt
echo
echo "uv.lock pin:"
rg -n -C2 'name = "google-cloud-resource-manager"|version = "1\.' uv.lock
echo
echo "Wheel hash pin (if present):"
fd '^requirements\.hashes\.wheel\.txt$' -x rg -n '^google-cloud-resource-manager==' {}Repository: lightspeed-core/lightspeed-stack
Length of output: 14314
Lockfile drift: google-cloud-resource-manager version mismatch between lockfiles.
requirements.hashes.source.txt pins version 1.17.0 (line 295), while uv.lock pins 1.16.0 (line 978). This divergence can cause different dependency versions to be installed depending on which lockfile is used. Regenerate and sync uv.lock to match.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@requirements.hashes.source.txt` around lines 295 - 297, Lockfile drift:
google-cloud-resource-manager is pinned to 1.17.0 in
requirements.hashes.source.txt but uv.lock has 1.16.0; choose the intended
version (preferably 1.17.0 to match requirements.hashes.source.txt) and
regenerate/sync uv.lock using the project's lockfile generator so the package
version and hashes match; after regeneration, verify uv.lock now lists
google-cloud-resource-manager==1.17.0 with the same sha256 hashes as in
requirements.hashes.source.txt and commit the updated uv.lock.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@requirements-build.txt`:
- Line 76: Replace the invalid pinned dependency "poetry-core==2.3.2" with the
released version "poetry-core==2.3.1" in the requirements file so the build uses
a valid Poetry core package; locate the line containing the token
poetry-core==2.3.2 and change it back to poetry-core==2.3.1.
In `@requirements.hashes.source.txt`:
- Around line 874-876: The requirements entry pins a non-existent package
version sse-starlette==3.3.4; update the requirement line to
sse-starlette==3.3.3 and regenerate or replace the associated --hash values
accordingly (or remove the two --hash entries) so the hashes match the 3.3.3
release; locate the sse-starlette==3.3.4 line in requirements.hashes.source.txt
and change the version and hashes for sse-starlette to the correct ones for
3.3.3.
🪄 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: 7ce2626d-bb86-4592-b9f5-ce4410d044fd
📒 Files selected for processing (2)
requirements-build.txtrequirements.hashes.source.txt
📜 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). (5)
- GitHub Check: build-pr
- GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
- GitHub Check: E2E: server mode / ci
- GitHub Check: E2E: library mode / ci
- GitHub Check: E2E Tests for Lightspeed Evaluation job
🔇 Additional comments (15)
requirements.hashes.source.txt (9)
301-303: Verify lockfile synchronization for google-cloud-resource-manager.A previous review flagged that
google-cloud-resource-managerhad version drift betweenrequirements.hashes.source.txt(1.17.0) anduv.lock(1.16.0). Confirm thatuv.lockhas been regenerated and now also pins version 1.17.0 with matching hashes.#!/bin/bash # Verify uv.lock now has google-cloud-resource-manager==1.17.0 echo "Checking uv.lock for google-cloud-resource-manager version:" rg -n -A2 'name = "google-cloud-resource-manager"' uv.lock | rg 'version' echo "" echo "Checking requirements.hashes.source.txt pin:" rg -n '^google-cloud-resource-manager==' requirements.hashes.source.txt
747-861: No changes needed. The version2026.3.32is valid and exists on PyPI, released on 2026-03-28 (March 28, 2026). While the version number contains "32," it does not strictly follow a YYYY.M.D (year.month.day) format—the third component is not the day of release. The version is legitimate and is the latest release of the regex package.
307-309: googleapis-common-protos==1.73.1 is valid and current.The version 1.73.1 is the latest release as of 2026-03-26 and is available on PyPI. The patch version bump from 1.73.0 is correct.
295-297: Version 1.143.0 is valid and safe to update.This is the latest version of google-cloud-aiplatform and includes security patches for previously known vulnerabilities (CVE-2026-2472, CVE-2026-2473). No security advisories exist for this release.
645-647: proto-plus==1.27.2 is the latest version.The version bump from 1.27.1 to 1.27.2 is a valid patch release.
738-740: pythainlp==5.3.3 is valid and current. This is the latest version available.
507-509: openai==2.30.0 is a safe, non-breaking minor version update.Version 2.30.0 is the latest release and includes new features (keys field for computer actions) and bug fixes (type alignment, endpoint sanitization, ResponseInputMessageItem type requirement), with no documented breaking changes.
862-864: No issues found with requests==2.33.0 update.Version 2.33.0 is the latest release and contains no open CVEs. In fact, this update fixes CVE-2026-25645, which affected earlier versions. Version 2.32.5 is also unaffected by any open CVEs. The update is safe to proceed with.
35-67: Clarify what "Fixed chardet issue" means in the commit message.Chardet is a transitive dependency (appears in
pyproject.tomlaschardet>=5.2.0and inrequirements-build.txtcomments). The version remains at 7.3.0 in the hash file, and the commit57610f5specifically modified the chardet pinning section. However, the commit message doesn't explain what was fixed. Was this:
- A hash consistency regeneration?
- A transitive dependency resolution issue?
- A hash pinning correctness problem?
Please clarify what issue was resolved so reviewers can verify the fix is complete.
requirements-build.txt (6)
148-148: LGTM: requests added to unsafe setuptools dependencies.The addition of
requeststo the unsafe dependencies comment is accurate, reflecting that setuptools has a dependency on requests. This aligns with the requests version update to 2.33.0 in requirements.hashes.source.txt.
158-158: LGTM: vcs-versioning added to unsafe setuptools dependencies.The addition of
vcs-versioningto the unsafe dependencies comment is accurate, reflecting its transitive relationship through setuptools-scm.
68-68: LGTM: vcs-versioning added to packaging dependencies comment.The addition of
vcs-versioningto the packaging dependencies list is accurate, as vcs-versioning depends on the packaging library.
100-101: New transitive dependency: vcs-versioning==1.1.1This is a new transitive dependency introduced by setuptools-scm 10.x. Version 1.1.1 is the latest release and satisfies the requirement specified in setuptools-scm 10.0.5.
84-84: No changes needed — setuptools-rust==1.12.1 is valid (latest available on PyPI).
86-86: setuptools-scm==10.0.5 is compatible with this project and requires no action.The project's Python version requirement (3.12–3.13) exceeds the minimum Python 3.10 required by setuptools-scm 10.0. The new vcs-versioning dependency introduced in 10.0 is already present in requirements-build.txt (v1.1.1), and hatch-vcs 0.5.0 properly depends on setuptools-scm 10.0.5.
| pluggy==1.6.0 | ||
| # via hatchling | ||
| poetry-core==2.3.1 | ||
| poetry-core==2.3.2 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the latest version of poetry-core Python package?
💡 Result:
The latest version of the poetry-core Python package is 2.3.1.
Citations:
- 1: https://github.com/python-poetry/poetry-core/releases
- 2: https://pypi.org/project/poetry-core/
- 3: https://github.com/python-poetry/poetry-core
poetry-core==2.3.2 does not exist; revert to 2.3.1.
The specified version 2.3.2 is not a released version of poetry-core. According to PyPI and official releases, the latest available version is 2.3.1. Change the pin back to poetry-core==2.3.1 to fix the build dependency.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@requirements-build.txt` at line 76, Replace the invalid pinned dependency
"poetry-core==2.3.2" with the released version "poetry-core==2.3.1" in the
requirements file so the build uses a valid Poetry core package; locate the line
containing the token poetry-core==2.3.2 and change it back to
poetry-core==2.3.1.
| sse-starlette==3.3.4 \ | ||
| --hash=sha256:84bb06e58939a8b38d8341f1bc9792f06c2b53f48c608dd207582b664fc8f3c1 \ | ||
| --hash=sha256:aaf92fc067af8a5427192895ac028e947b484ac01edbc3caf00e7e7137c7bef1 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the latest version of sse-starlette Python package?
💡 Result:
The latest version of the sse-starlette Python package is 3.3.3.
Citations:
- 1: https://github.com/sysid/sse-starlette/releases
- 2: https://pypi.org/project/sse-starlette/
- 3: https://pypistats.org/packages/sse-starlette
- 4: https://www.piwheels.org/project/sse-starlette/
- 5: https://github.com/sysid/sse-starlette
sse-starlette==3.3.4 does not exist on PyPI; downgrade to 3.3.3.
The latest available version of sse-starlette is 3.3.3. Version 3.3.4 does not exist and pinning to it will cause package installation to fail.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@requirements.hashes.source.txt` around lines 874 - 876, The requirements
entry pins a non-existent package version sse-starlette==3.3.4; update the
requirement line to sse-starlette==3.3.3 and regenerate or replace the
associated --hash values accordingly (or remove the two --hash entries) so the
hashes match the 3.3.3 release; locate the sse-starlette==3.3.4 line in
requirements.hashes.source.txt and change the version and hashes for
sse-starlette to the correct ones for 3.3.3.
1 participant
Description
LCORE-1610: Updated Konflux dependencies
Type of change
Tools used to create PR
Related Tickets & Documents
Summary by CodeRabbit