LCORE-858: hermetic build with CPU torch

[raptorsun]

Description

Type of change

• Refactor
• New feature
• Bug fix
• CVE fix
• Optimization
• Documentation Update
• Configuration Update
• Bump-up service version
• Bump-up dependent library
• Bump-up library or tool used for development (does not change the final image)
• CI configuration change
• Konflux configuration change
• Unit tests improvement
• Integration tests improvement
• End to end tests improvement

Tools used to create PR

Identify any AI code assistants used in this PR (for transparency and review context)

• Assisted-by: (e.g., Claude, CodeRabbit, Ollama, etc., N/A if not used)
• Generated by: (e.g., tool name and version; N/A if not used)

Related Tickets & Documents

• Related Issue #
• Closes #

Checklist before requesting a review

• I have performed a self-review of my code.
• PR has passed all pre-merge test jobs.
• If it is a core feature, I have added thorough tests.

Testing

• Please provide detailed steps to perform tests related to this code change.
• How were the fix/results from this change verified? Please provide relevant screenshots or results.

Summary by CodeRabbit

• New Features

  • ARM64 build platform added; explicit "build source image" and hermetic build options exposed.
  • New hermetic and torch-specific pinned requirement files for reproducible installs.

• Improvements

  • Prefetching for RPM and multiple pip inputs; pipeline and task timeouts extended to 4 hours.
  • Multi-arch RPM lock and repository configuration for consistent system packages.
  • Makefile targets and helper script to generate/prune hermetic requirement files and emit Torch pins.

• Documentation

  • README expanded with Konflux/hermetic build and dependency update guidance.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Adds hermetic multi-arch build support: Tekton pipelines gain hermetic/prefetch params and 4h timeouts; Containerfile gains an arch-aware conditional hermetic install path and copies arch-specific requirements; new hermetic/tensor requirement files, RPM inputs/lock, UBI repo, Makefile targets and helper script added; docs updated.

Changes

Cohort / File(s)	Summary
Tekton pipeline configs ./.tekton/lightspeed-stack-pull-request.yaml, ./.tekton/lightspeed-stack-push.yaml	Added linux-c6gd2xlarge/arm64 to build-platforms; introduced pipeline params build-source-image, prefetch-input (JSON with RPM + pip inputs), and hermetic; added 4h timeouts for pipeline and tasks in both params and spec.
Containerfile build logic Containerfile	COPY now includes ${LSC_SOURCE_DIR}/requirements.*.txt; single uv sync replaced by conditional RUN: if /cachi2/cachi2.env exists, source it, create/activate uv venv and install arch-specific requirements.*.txt (using find-links and --no-index); else run original uv sync --locked --no-dev --group llslibdev.
Python dependency files & build tooling pyproject.toml, requirements.hermetic.txt, requirements.torch.txt, Makefile, scripts/remove_torch_deps.sh	pyproject.toml torch source entry converted to a list and assigned group = "llslibdev"; added requirements.hermetic.txt and pinned requirements.torch.txt (torch==2.7.1+cpu with hashes/index); Makefile adds TORCH_VERSION and konflux-requirements target and updates help; new script scripts/remove_torch_deps.sh removes torch deps from generated requirement files.
RPM inputs & UBI repo rpms.in.yaml, rpms.lock.yaml, ubi.repo	Added rpms.in.yaml listing RPM packages and repofile references; added rpms.lock.yaml lockfile with multi-arch package metadata (URLs, checksums, arch sections); added ubi.repo with UBI9 BaseOS/AppStream/CodeReady repository stanzas.
Docs README.md	Added Konflux/hermetic build documentation, guidance for updating dependency and RPM files, macOS-specific notes, and minor formatting/TOC updates.

Sequence Diagram(s)

mermaid
sequenceDiagram
participant Dev as Developer/CI
participant Tekton as Tekton Pipeline
participant Builder as Image Builder (Docker/Buildkit)
participant PyPI as pip / local find-links
participant Repo as UBI Repo / RPM server

Note over Tekton,Builder: New params: hermetic, prefetch-input, build-source-image; multi-arch includes arm64
Dev->>Tekton: Trigger PipelineRun (params include hermetic, prefetch-input)
Tekton->>Builder: Start build for target platforms (x86_64, arm64)
Builder->>Builder: COPY source + `requirements.*.txt` into image
alt hermetic == true
    Builder->>Builder: Detect `/cachi2/cachi2.env` and source it
    Builder->>Builder: Create & activate uv venv
    Builder->>PyPI: Install from local find-links using `requirements.*.txt` with `--no-index`
else hermetic == false
    Builder->>PyPI: Run `uv sync --locked --no-dev --group llslibdev`
end
Builder->>Repo: Install RPMs using `ubi.repo` and `rpms.lock.yaml` URLs
Builder-->>Tekton: Push built multi-arch image(s)

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~30 minutes

• Pay special attention to:
  • Containerfile hermetic branch: /cachi2/cachi2.env detection, uv venv creation/activation, find-links and --no-index usage, and exact architecture-specific requirements filenames.
  • Tekton params/spec: JSON formatting of prefetch-input, duplication between params and pipelineSpec, and propagation to PipelineRun templates.
  • rpms.lock.yaml / rpms.in.yaml: verify URLs, checksums, arch sections and consistency.
  • Makefile konflux-requirements flow and scripts/remove_torch_deps.sh correctness for generated files.

Possibly related PRs

• LCORE-497, LCORE-498, LCORE-499: Bundle most of ansible, assist-installer, default run.yaml dependencies, with pytorch and libs that depends on it. #292 — overlaps on uv/venv install flow, PyTorch/uv config and pinned torch handling.

Suggested reviewers

• tisnik
• matysek

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: adding hermetic build support with CPU torch, which is directly reflected across multiple files (Tekton configs, Containerfile, requirements, Makefile, scripts, and documentation).
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (5)

requirements.torch.txt (1)

1-27: Check torch hashes cover all wheels used in multi-arch hermetic builds.

The file cleanly pins torch==2.7.1 with hashes, which matches the llslibdev group in pyproject.toml. Given the header shows uv pip compile ... --python-platform x86_64-unknown-linux-gnu, please verify that the hash set also includes the wheel(s) actually used on aarch64; otherwise hermetic installs on the arm builder could fail with hash mismatches. If not already handled, consider generating per-arch torch requirement files or regenerating this file so its hashes match all targeted platforms. Based on learnings, the version choice itself (2.7.1) is fine.

pyproject.toml (1)

58-64: Clarify Pyright exclude path vs guideline (src/auth/k8s.py vs src/authentication/k8s.py).

Coding guidelines call for excluding src/auth/k8s.py from Pyright, but the current config excludes src/authentication/k8s.py. If the module has been renamed, the guideline is stale; if not, this exclude may not be hitting the intended file. Please confirm the actual path and align either the config or the guideline to avoid confusion (and optionally exclude both paths if that’s safer for now).

.tekton/lightspeed-stack-pull-request.yaml (1)

33-39: PR PipelineRun hermetic + arm64 config matches push; consider deduplicating prefetch JSON.

Mirroring the arm64 platform, hermetic flag, build-source-image='true', and the same prefetch-input JSON plus 4h timeouts keeps PR builds aligned with push builds, which is good. To reduce future drift, consider centralising the long prefetch-input JSON (e.g., via a shared template variable) so push and PR YAML stay in lockstep.

Also applies to: 635-637

Containerfile (1)

25-36: Hermetic install branch matches cachi2 setup; consider also hermeticising the initial uv install.

The conditional branch that sources /cachi2/cachi2.env, creates a no-index venv with uv venv --seed --no-index --find-links ${PIP_FIND_LINKS}, and then installs requirements.$(uname -m).txt plus requirements.torch.txt is consistent with the Tekton prefetch-input and multi-arch design, while the else path preserves the previous uv sync behaviour. If you want the uv bootstrap itself to be hermetic as well, you could wrap the earlier pip3.12 install "uv==0.8.15" in the same /cachi2/cachi2.env logic so it also uses ${PIP_FIND_LINKS} when available, for example:

-RUN pip3.12 install "uv==0.8.15"
+RUN if [ -f /cachi2/cachi2.env ]; then \
+      . /cachi2/cachi2.env && pip3.12 install --no-index --find-links ${PIP_FIND_LINKS} "uv==0.8.15"; \
+    else \
+      pip3.12 install "uv==0.8.15"; \
+    fi

This would make the entire Python tooling stack reproducible under cachi2. Based on learnings, continuing to rely on uv for env management is in line with previous guidance.

rpms.lock.yaml (1)

1-355: Consider adding documentation on lockfile generation and maintenance.

This lockfile lacks inline comments explaining its purpose, generation method, or intended usage. Given that it's part of a hermetic build system, clarify:

• How and when this lockfile is generated (is it automated or manual?)
• What tool/process resolves rpms.in.yaml → rpms.lock.yaml?
• Are there validation checks to ensure consistency across architectures?

This would improve maintainability for future updates.

Do you want me to help draft a README or inline documentation explaining the lockfile structure and generation process?

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6cfaeab and c4ead8a.

⛔ Files ignored due to path filters (1)

• uv.lock is excluded by !**/*.lock

📒 Files selected for processing (9)

• .tekton/lightspeed-stack-pull-request.yaml (2 hunks)
• .tekton/lightspeed-stack-push.yaml (2 hunks)
• Containerfile (1 hunks)
• pyproject.toml (1 hunks)
• requirements.hermetic.txt (1 hunks)
• requirements.torch.txt (1 hunks)
• rpms.in.yaml (1 hunks)
• rpms.lock.yaml (1 hunks)
• ubi.repo (1 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

pyproject.toml

📄 CodeRabbit inference engine (CLAUDE.md)

pyproject.toml: Configure pylint with source-roots = "src"
Exclude src/auth/k8s.py from pyright type checking

Files:

• pyproject.toml

🧠 Learnings (3)

📚 Learning: 2025-11-24T16:58:04.410Z

Learnt from: CR
Repo: lightspeed-core/lightspeed-stack PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:58:04.410Z
Learning: Use Python package manager `uv` with `uv run` prefix for all development commands

Applied to files:

• requirements.hermetic.txt

📚 Learning: 2025-11-24T16:58:04.410Z

Learnt from: CR
Repo: lightspeed-core/lightspeed-stack PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:58:04.410Z
Learning: Use `uv sync --group dev --group llslibdev` to install development dependencies

Applied to files:

• Containerfile
• pyproject.toml

📚 Learning: 2025-08-18T11:45:59.961Z

Learnt from: matysek
Repo: lightspeed-core/lightspeed-stack PR: 292
File: pyproject.toml:77-77
Timestamp: 2025-08-18T11:45:59.961Z
Learning: torch==2.7.1 is available on PyPI and is a valid version that can be used in dependency specifications.

Applied to files:

• requirements.torch.txt

⏰ 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). (4)

• GitHub Check: build-pr
• GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
• GitHub Check: e2e_tests (ci)
• GitHub Check: e2e_tests (azure)

🔇 Additional comments (7)

.tekton/lightspeed-stack-push.yaml (1)

30-36: Hermetic + arm64 push PipelineRun params look consistent; validate platform ID and files.

Extending build-platforms with linux-c6gd2xlarge/arm64, wiring hermetic='true', build-source-image='true', and the prefetch-input JSON (rpm + pip with requirements.x86_64.txt, requirements.aarch64.txt, requirements.hermetic.txt, requirements.torch.txt) plus 4h timeouts all align with the Containerfile and hermetic setup. Please just confirm that:

• linux-c6gd2xlarge/arm64 is a valid platform name for your multi-platform-controller, and
• all four listed requirements files exist at the repo root and are kept in sync with the container build logic.

Also applies to: 632-634

pyproject.toml (1)

91-94: Scoping torch to the pytorch-cpu index for llslibdev looks correct.

Limiting the custom pytorch-cpu index to the llslibdev group keeps global dependency resolution unchanged while ensuring the dev/lib group’s torch==2.7.1 comes from the CPU wheels only. This matches the hermetic torch pinning strategy and keeps behaviour predictable.

requirements.hermetic.txt (1)

1-2: Hermetic uv/pip pins look reasonable; keep them aligned with the container image.

Pinning uv==0.8.15 and pip==24.2 gives cachi2 a clear target for hermetic prefetch and matches the uv version installed in the Containerfile. Just ensure these versions are updated in lockstep with the base image and pip3.12 install "uv==..." when you bump them.

rpms.in.yaml (1)

1-4: RPM prefetch config aligns with Containerfile usage.

Listing gcc, jq, and patch with arches: [x86_64, aarch64] and referencing ./ubi.repo matches the RPMs you install in the Dockerfile and should let cachi2 provide them hermetically for both architectures.

ubi.repo (1)

1-62: UBI 9 repo definitions look standard and suitable for hermetic RPM prefetch.

BaseOS, AppStream, and CodeReady Builder RPM repos are enabled with GPG checks, while debug/source repos are disabled, which is a sane default and aligns with rpms.in.yaml’s contentOrigin. This should give cachi2 a stable, verified source for the RPM set across both architectures.

rpms.lock.yaml (2)

1-4: File structure is well-formed and consistent.

The lockfile header and schema are properly structured.

---

5-183: Unable to complete verification—repository access unavailable.

The verification cannot be performed due to persistent repository access failures. The original review comment identifies a legitimate concern about architectural package differences (aarch64 includes libasan and libubsan, x86_64 includes glibc-headers), but confirming whether these differences are intentional requires access to rpms.in.yaml to compare against the input specification.

Manual verification is required:

• Check rpms.in.yaml to confirm if these architectural differences are specified intentionally
• If specified, document the rationale for the differences
• If not specified, the lock file may contain inconsistencies that need correction

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

gcc 11.5.0-5.el9_5 CVE vulnerabilities security advisories Red Hat UBI9

💡 Result:

Short answer: Red Hat released RHSA-2025:1346 (issued 2025-02-12) which fixes CVE-2020-11023 in the gcc/libgcc/libstdc++ family; the fixed package version is 11.5.0-5.el9_5 (the RHEL9 / UBI9 builds). Upgrade to gcc-11.5.0-5.el9_5 (and corresponding libgcc/libstdc++ packages) to remediate. [1][2][3]

Sources:

• Red Hat advisory RHSA-2025:1346 (gcc, fixes CVE-2020-11023; fixed version 11.5.0-5.el9_5). [1]
• AlmaLinux erratum ALSA-2025:1346 showing same fix/version. [2]
• Snyk / OSV listings referencing CVE-2020-11023 and the fixed RHEL/Alma packages. [3]

---

🌐 Web query:

binutils 2.35.2-63.el9 CVE vulnerabilities security advisories Red Hat

💡 Result:

I found no Red Hat security advisory page explicitly for binutils-2.35.2-63.el9 on the Red Hat Customer Portal, but vulnerability scanners and package feeds that reference that exact rpm version list several CVEs affecting binutils/binutils-gold 2.35.2-63.el9 (examples):

• CVE-2025-7546, CVE-2025-7545. [1]
• CVE-2025-11494, CVE-2025-11414, CVE-2025-11413, CVE-2025-11412, CVE-2025-11083. [2][3]
• CVE-2025-11839, CVE-2025-11840. [4]

Notes/sources:

• Red Hat errata pages for binutils (RHSA/RHBA) show security/bandage updates for other binutils releases but do not show an RHSA specifically for 2.35.2-63.el9. See RHSA/RHBA listings on access.redhat.com. [5][6]
• References showing binutils-2.35.2-63.el9 mapped to CVEs come from vulnerability scanning/registry entries (examples: Iron Bank / Anchore/Twistlock results and package lists). [1][2][3][4]

If you want, I can:

• search Red Hat’s CSAF/errata API for any newer RHSA that explicitly lists 2.35.2-63.el9 and the authoritative CVE mappings, or
• fetch the vendor advisories / CVE pages (NVD/CVE) for each CVE above and summarize impact and fixed versions.

Sources:

1. Iron Bank/Red Hat container scan entries referencing CVE-2025-7546 / CVE-2025-7545 for binutils-2.35.2-63.el9. (repo1.dso.mil entries).
2. Iron Bank / Anchore/Twistlock findings listing CVE-2025-11412..11494 and CVE-2025-11083 against binutils-2.35.2-63.el9. (repo1.dso.mil).
3. CERN / package lists showing binutils-gold 2.35.2-63.el9 in package feeds. (linux.web.cern.ch).
4. Additional scan entries listing CVE-2025-11839/11840 for binutils-2.35.2-63.el9. (repo1.dso.mil).
5. Red Hat errata RHSA/RHBA listings for binutils (example RHSA-2024:9689, RHSA-2023:6236). (access.redhat.com).
6. Red Hat security data / CSAF API (access.redhat.com hydra/securitydata).

Tell me if you want me to (A) pull authoritative Red Hat RHSA/CSAF entries for each CVE, or (B) retrieve full CVE details and recommended fixed package versions.

---

🌐 Web query:

Red Hat UBI9 package updates gcc binutils 2024 2025 security patches

💡 Result:

Short answer: Red Hat issued security updates for gcc and binutils affecting RHEL‑9 / UBI‑9 across late 2024 and into 2025 — you should update your UBI9 images/packages (dnf update or pull rebuilt UBI9 images) to pick up fixes. Key advisories include RHSA-2024:9689 (binutils, Nov 14, 2024) and multiple RHSA notices for gcc in Feb 2025 (e.g. RHSA-2025:1305 / RHSA-2025:1346 addressing CVE-2020-11023 and related fixes). See Red Hat errata and aggregated vulnerability records for details and affected package versions. [1][2][3]

If you want, I can:

• list exact fixed package versions for UBI‑9 (gcc, cpp, binutils, binutils‑ld, etc.), or
• produce the dnf commands and a minimal Dockerfile snippet to rebuild/pull an updated UBI9 image.

Sources

• Red Hat errata (binutils RHSA-2024:9689). [1]
• OSV / Red Hat RHSA imports for gcc (RHSA-2025:1305 / RHSA-2025:1346). [2]
• Tenable / security scanner advisory summaries referencing RHSA-2025 gcc updates. [3]

---

Review the binutils package version for known CVEs and update to the latest patched release.

The gcc-11.5.0-5.el9_5 version is current and secure—it is the fixed version released in RHSA-2025:1346 (Feb 12, 2025) that addresses CVE-2020-11023. However, binutils-2.35.2-63.el9 has multiple known CVEs (including CVE-2025-7546, CVE-2025-7545, CVE-2025-11494, and others) and does not have an explicit Red Hat security advisory patch for this specific build. Red Hat issued RHSA-2024:9689 (Nov 2024) for binutils updates affecting RHEL9/UBI9. Update to the latest patched binutils version available in UBI9 to remediate these vulnerabilities.

Also applies to: 184-355

🤖 Prompt for AI Agents

In rpms.lock.yaml around lines 5 to 183, the binutils entry (name: binutils,
evr: 2.35.2-63.el9) is vulnerable and must be updated to the UBI9 patched
release referenced by RHSA-2024:9689; replace the binutils package block with
the latest patched binutils RPM metadata (updated evr, url, repoid, size,
checksum, and sourcerpm) from the UBI9 repository, ensuring checksum and size
match the downloaded RPM; if multiple arches or entries exist (lines 184–355
also affected), update them similarly and run your lockfile generation script to
regenerate the file and verify no other dependent packages break.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

Containerfile (1)

25-36: Hermetic cachi2 install path looks solid; consider tightening uv venv target and arch assumptions

The new hermetic branch is well structured:

• Checks for /cachi2/cachi2.env and, when present, uses PIP_FIND_LINKS + PIP_NO_INDEX to drive a fully offline uv venv + pip install.
• Falls back to the original uv sync --locked --no-dev --group llslibdev when cachi2 isn’t present, preserving local/dev behavior.
• Aligns with the Tekton prefetch-input configuration and the new requirements.*.txt files being copied into the image.

A couple of small but important details to verify and potentially harden:

1. Make the venv path explicit

You’re assuming uv venv creates .venv by default, which is then:

• Activated inline (. .venv/bin/activate), and
• Relied on later via ENV PATH="/app-root/.venv/bin:$PATH" and uv pip uninstall ecdsa.

To avoid any surprises if uv’s defaults change, it’s safer to pass the target directory explicitly:

-RUN if [ -f /cachi2/cachi2.env ]; then \
-    . /cachi2/cachi2.env && uv venv --seed --no-index --find-links ${PIP_FIND_LINKS} && . .venv/bin/activate && pip install --no-index --find-links ${PIP_FIND_LINKS} -r requirements.$(uname -m).txt -r requirements.torch.txt; \
+RUN if [ -f /cachi2/cachi2.env ]; then \
+    . /cachi2/cachi2.env && uv venv .venv --seed --no-index --find-links "${PIP_FIND_LINKS}" && . .venv/bin/activate && pip install --no-index --find-links "${PIP_FIND_LINKS}" -r "requirements.$(uname -m).txt" -r requirements.torch.txt; \
     else \
     uv sync --locked --no-dev --group llslibdev; \
     fi

2. Confirm arch‑specific requirements naming

The hermetic install uses requirements.$(uname -m).txt. On UBI9 this should map to filenames like requirements.x86_64.txt and requirements.aarch64.txt. Please confirm that:

• Those filenames exactly match uname -m outputs on your target builders, and
• No other arch variants (e.g., arm64) are expected.

3. Hermeticity of uv bootstrap (optional tightening)

Even in hermetic runs, pip3.12 install "uv==0.8.15" (earlier in the Dockerfile) will still hit PyPI unless the base image or environment already provides uv or redirects pip through cachi2. If you need fully strict hermetic behavior, you might want to:

• Provide uv via an RPM in your rpm lock/repo, or
• Include uv in the pip prefetch set and run that install under the cachi2 environment as well.

If partial hermeticity (only for app deps) is acceptable, this can be left as‑is.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c4ead8a and aae4ac9.

⛔ Files ignored due to path filters (1)

• uv.lock is excluded by !**/*.lock

📒 Files selected for processing (5)

• .tekton/lightspeed-stack-pull-request.yaml (2 hunks)
• .tekton/lightspeed-stack-push.yaml (2 hunks)
• Containerfile (1 hunks)
• pyproject.toml (1 hunks)
• requirements.torch.txt (1 hunks)

✅ Files skipped from review due to trivial changes (1)

• requirements.torch.txt

🚧 Files skipped from review as they are similar to previous changes (2)

• .tekton/lightspeed-stack-push.yaml
• pyproject.toml

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2025-11-24T16:58:04.410Z

Learnt from: CR
Repo: lightspeed-core/lightspeed-stack PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:58:04.410Z
Learning: Use `uv sync --group dev --group llslibdev` to install development dependencies

Applied to files:

• Containerfile

⏰ 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). (4)

• GitHub Check: build-pr
• GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
• GitHub Check: e2e_tests (azure)
• GitHub Check: e2e_tests (ci)

🔇 Additional comments (2)

.tekton/lightspeed-stack-pull-request.yaml (2)

30-39: Hermetic/prefetch params look correctly wired; confirm requirements file usage intent

The added params look consistent with the pipeline spec and tasks:

• build-platforms now targets linux/x86_64 and linux-c6gd2xlarge/arm64, which will flow into the existing $(params.build-platforms) matrices.
• hermetic: 'true' and prefetch-input are correctly passed to prefetch-dependencies and the hermetic-aware tasks (build-images, sast-coverity-check, etc.).
• The pip prefetch config lists requirements.x86_64.txt, requirements.aarch64.txt, requirements.hermetic.txt, and requirements.torch.txt, which aligns with the Containerfile copying requirements.*.txt.

One behavioral detail to double‑check: in the Containerfile, the hermetic install path currently installs from requirements.$(uname -m).txt + requirements.torch.txt only, while requirements.hermetic.txt is used here for prefetching but not explicitly installed. If requirements.hermetic.txt contains any runtime deps that aren’t also in the arch‑specific files, they would be prefetched but never installed.

If that file is intentionally “prefetch‑only” (e.g., just to over‑approximate the wheel cache), this is fine; otherwise, consider either:

• Folding those deps into the arch‑specific requirements files, or
• Adding -r requirements.hermetic.txt to the hermetic install command in the Containerfile.

---

635-637: New 4h PipelineRun timeouts are reasonable; verify they cover worst‑case builds

Adding:

timeouts:
  pipeline: 4h
  tasks: 4h

at the PipelineRun level is structurally correct and will prevent runaway builds. Given the added ARM/CPU‑torch hermetic work, please sanity‑check that:

• 4h is sufficient for the slowest expected multi‑arch build (including cache cold starts), and
• You don’t need different limits for specific long‑running tasks (e.g., build vs. scans), which would require per‑task or pipeline‑level tuning elsewhere.

If current runs comfortably finish under this ceiling, this change looks good as‑is.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

scripts/remove_torch_deps.sh (1)

22-48: Verify indentation assumption and edge case handling for torch dependency section.

The AWK logic correctly detects and removes torch dependencies, but relies on a fixed 4-space indentation pattern (line 34: /^ /). While this matches pip-tools output convention, the script could fail silently or behave unexpectedly if:

1. Indentation uses tabs or different spacing (e.g., 2 spaces)
2. Blank or whitespace-only lines appear within the torch dependency block

Consider testing the script with requirements files generated from uv pip compile across different Python/platform versions to confirm robust handling.

Makefile (1)

104-109: Verify uv pip compile flags and add error handling.

The konflux-requirements target uses several flags that require verification: --torch-backend cpu, --emit-index-url, and --no-deps. These are not standard uv pip compile flags in common versions; confirm they are supported in your uv version.

Additionally, the Makefile lacks error handling at the target level. If line 105 or 106 fails (compilation errors), execution continues to lines 107-109, potentially generating incomplete or corrupted requirements files. Consider adding error handling (e.g., prefixing with set -e in a bash wrapper or using Makefile's .PHONY declarations with conditional checks).

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between aae4ac9 and d32d0b0.

⛔ Files ignored due to path filters (1)

• uv.lock is excluded by !**/*.lock

📒 Files selected for processing (7)

• .tekton/lightspeed-stack-pull-request.yaml (2 hunks)
• .tekton/lightspeed-stack-push.yaml (2 hunks)
• Containerfile (1 hunks)
• Makefile (2 hunks)
• pyproject.toml (1 hunks)
• requirements.torch.txt (1 hunks)
• scripts/remove_torch_deps.sh (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (4)

• .tekton/lightspeed-stack-push.yaml
• .tekton/lightspeed-stack-pull-request.yaml
• Containerfile
• requirements.torch.txt

🧰 Additional context used

📓 Path-based instructions (1)

pyproject.toml

📄 CodeRabbit inference engine (CLAUDE.md)

pyproject.toml: Configure pylint with source-roots = "src"
Exclude src/auth/k8s.py from pyright type checking

Files:

• pyproject.toml

🧠 Learnings (1)

📚 Learning: 2025-11-24T16:58:04.410Z

Learnt from: CR
Repo: lightspeed-core/lightspeed-stack PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:58:04.410Z
Learning: Use `uv sync --group dev --group llslibdev` to install development dependencies

Applied to files:

• pyproject.toml

⏰ 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). (4)

• GitHub Check: build-pr
• GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
• GitHub Check: e2e_tests (azure)
• GitHub Check: e2e_tests (ci)

🔇 Additional comments (5)

scripts/remove_torch_deps.sh (1)

1-19: LGTM on file structure and error handling.

Input validation, backup creation, and use of set -e for error propagation are all appropriate for a utility script. The diff output at line 55 using || true is a good pattern to allow review without blocking on diff exit codes.

pyproject.toml (2)

91-94: Verify uv support for group-scoped source configuration syntax.

The change introduces a list-based torch source configuration with a group = "llslibdev" field to associate torch with the llslibdev dependency group. While the TOML syntax is valid, confirm that your version of uv recognizes and correctly processes this group field in [tool.uv.sources] configurations.

The syntax represents a significant configuration change from the previous single-dict approach, and improper handling by uv could result in torch not being resolved or installed correctly during builds.

---

58-65: Coding guideline compliance verified.

Pyright exclusion and extraPaths configuration correctly align with coding guidelines: src/authentication/k8s.py is excluded, and ./src is added to extraPaths for source-root configuration.

Makefile (2)

104-109: Flag-specific verification needed for uv pip compile.

The command at line 109 uses stdin to pass torch version: echo "torch==${TORCH_VERSION}" | uv pip compile - .... Confirm that uv pip compile supports reading requirements from stdin (- argument). If not supported, this step will fail silently or with unclear error messages.

Additionally, line 109 uses --emit-index-url, which typically outputs index URLs to the compiled requirements file—verify this flag exists and produces the expected output format for the torch requirements file.

---

7-8: LGTM on TORCH_VERSION variable.

Clear, simple variable declaration aligned with the hermetic build versioning approach. Consistent with the PR objective of pinning PyTorch to 2.7.1 across build platforms.

[raptorsun]

/retest

[raptorsun]

/retest

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

README.md (1)

18-94: TOC structure looks good, minor formatting note.

The expanded table of contents appropriately reflects the new Konflux documentation sections. The markdownlint hints indicate indentation inconsistencies, but these are cosmetic issues that don't impact functionality.

If you'd like consistent markdown formatting, consider running a markdown formatter to align the indentation throughout the TOC.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d32d0b0 and baecbc8.

⛔ Files ignored due to path filters (1)

• uv.lock is excluded by !**/*.lock

📒 Files selected for processing (8)

• .tekton/lightspeed-stack-pull-request.yaml (2 hunks)
• .tekton/lightspeed-stack-push.yaml (2 hunks)
• Containerfile (1 hunks)
• Makefile (2 hunks)
• README.md (9 hunks)
• pyproject.toml (1 hunks)
• requirements.torch.txt (1 hunks)
• scripts/remove_torch_deps.sh (1 hunks)

✅ Files skipped from review due to trivial changes (1)

• requirements.torch.txt

🚧 Files skipped from review as they are similar to previous changes (2)

• .tekton/lightspeed-stack-push.yaml
• scripts/remove_torch_deps.sh

🧰 Additional context used

📓 Path-based instructions (1)

pyproject.toml

📄 CodeRabbit inference engine (CLAUDE.md)

pyproject.toml: Configure pylint with source-roots = "src"
Exclude src/auth/k8s.py from pyright type checking

Files:

• pyproject.toml

🧠 Learnings (2)

📚 Learning: 2025-11-24T16:58:04.410Z

Learnt from: CR
Repo: lightspeed-core/lightspeed-stack PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:58:04.410Z
Learning: Use `uv sync --group dev --group llslibdev` to install development dependencies

Applied to files:

• Containerfile
• pyproject.toml

📚 Learning: 2025-08-18T10:56:55.349Z

Learnt from: matysek
Repo: lightspeed-core/lightspeed-stack PR: 292
File: pyproject.toml:0-0
Timestamp: 2025-08-18T10:56:55.349Z
Learning: The lightspeed-stack project intentionally uses a "generic image" approach, bundling many dependencies directly in the base runtime image to work for everyone, rather than using lean base images with optional dependency groups.

Applied to files:

• README.md

🪛 markdownlint-cli2 (0.18.1)

README.md

19-19: Unordered list indentation
Expected: 2; Actual: 4

(MD007, ul-indent)

---

55-55: Unordered list indentation
Expected: 6; Actual: 12

(MD007, ul-indent)

---

56-56: Unordered list indentation
Expected: 4; Actual: 8

(MD007, ul-indent)

---

57-57: Unordered list indentation
Expected: 6; Actual: 12

(MD007, ul-indent)

---

90-90: Unordered list indentation
Expected: 2; Actual: 4

(MD007, ul-indent)

---

91-91: Unordered list indentation
Expected: 4; Actual: 8

(MD007, ul-indent)

---

92-92: Unordered list indentation
Expected: 4; Actual: 8

(MD007, ul-indent)

---

93-93: Unordered list indentation
Expected: 4; Actual: 8

(MD007, ul-indent)

⏰ 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). (4)

• GitHub Check: build-pr
• GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
• GitHub Check: e2e_tests (azure)
• GitHub Check: e2e_tests (ci)

🔇 Additional comments (9)

.tekton/lightspeed-stack-pull-request.yaml (3)

30-33: ARM64 platform support looks appropriate.

Adding linux-c6gd2xlarge/arm64 enables multi-architecture builds on AWS Graviton instances, aligning with the PR's hermetic multi-arch build objectives.

---

635-637: Question the 4-hour timeout duration.

The 4-hour timeout for both pipeline and tasks seems excessive, even for hermetic multi-arch builds. Typical CI/CD pipelines complete in 30 minutes to 2 hours.

Consider whether this timeout is necessary or if it indicates potential performance issues:

• Are you observing builds that actually take close to 4 hours?
• Is this a conservative upper bound that could be reduced (e.g., to 2 hours)?
• Does the prefetch step or multi-arch build step take unexpectedly long?

If builds consistently complete in under 2 hours, reducing the timeout helps catch hung builds faster and conserves resources.

---

34-39: Unable to complete verification — repository access unavailable.

The codebase cannot be accessed due to repository clone failures, preventing verification of:

• Whether the YAML file contains the configuration shown at lines 34-39
• Whether all four requirements files (x86_64, aarch64, hermetic, torch) exist
• Whether these files contain proper package hashes for hermetic builds

The original review comment's approval and verification requests cannot be validated without access to the repository.

Containerfile (2)

25-25: COPY correctly includes hermetic requirements files.

The glob pattern requirements.*.txt efficiently copies all platform-specific and shared requirements files needed for the hermetic build path.

---

27-36: Based on the web search results, I can confirm that the uv venv command does support the combination of --seed, --no-index, and --find-links flags together. These flags are designed specifically for hermetic builds where dependencies are pre-fetched (as with cachi2).

However, I'm unable to verify the requirements files due to repository access issues. Let me provide the rewritten review comment based on what I can confirm:

---

Conditional hermetic build path uses supported uv venv flags correctly.

The if/else logic properly handles both hermetic (Konflux) and non-hermetic (local dev) builds:

• Hermetic path: Sources cachi2 environment, creates an isolated venv with --seed --no-index --find-links, and installs from prefetched dependencies
• Non-hermetic path: Preserves the original developer workflow with uv sync

The architecture detection using $(uname -m) correctly resolves to x86_64 or aarch64 on Linux systems.

Remaining item: Verify that requirements.$(uname -m).txt and requirements.torch.txt exist in the repository for both supported architectures. These files are referenced in the build but could not be verified due to repository access limitations.

README.md (1)

940-985: Since the repository cannot be cloned in the sandbox environment, I cannot execute the verification script directly. However, I can still assess the review comment itself.

The original review comment requests verification of documented commands but this type of verification requires:

1. Executing make konflux-requirements in the actual repository
2. Checking that generated files exist and have correct content
3. Testing rpm-lockfile-prototype with the actual base image

These are legitimate verification requests that the developer/maintainer should perform before merging, as they involve build system execution and dependency management.

Rewritten Review Comment

Verify Konflux dependency update commands work end-to-end.

The new Konflux section provides clear guidance for updating dependencies in hermetic builds. However, the documented commands need verification:

1. Confirm make konflux-requirements generates all three requirements files:

   • requirements.x86_64.txt (x86_64 packages excluding torch)
   • requirements.aarch64.txt (ARM64 packages excluding torch)
   • requirements.torch.txt (CPU variant of torch)

2. Verify rpm-lockfile-prototype works with your base image and produces valid rpms.lock.yaml

3. Confirm torch version is correctly pinned in requirements.torch.txt

Makefile (2)

7-9: PyTorch 2.7.1 CPU wheels verified and available.

Centralizing TORCH_VERSION as a constant is good practice and simplifies version management. PyTorch 2.7.1 with CPU-only wheels is available on download.pytorch.org across multiple platforms (manylinux, Windows, macOS) and Python versions (3.10, 3.11, 3.13).

---

104-110: The uv flags are valid; script existence cannot be verified due to repository access limitation.

The web search confirms that uv pip compile supports all three flags used in the target:

• --emit-index-url: includes index URLs in compiled output
• --python-platform: targets alternate platforms during resolution
• --torch-backend: specifies PyTorch backend (cpu, cu126, etc.)

However, the repository could not be cloned to verify that scripts/remove_torch_deps.sh exists and is executable. The target's logic (removing torch dependencies from arch-specific files, then generating a separate torch file) is sound, but the script verification is incomplete.

pyproject.toml (1)

90-94: Torch source grouping with group attribute is supported by uv and correctly configured.

The change from a single object to an array with group = "llslibdev" is valid. This configuration makes the torch source conditional on the llslibdev dependency group, enabling selective installation via uv sync --group dev --group llslibdev.

The uv documentation confirms that sources in [tool.uv.sources] support the group key to condition sources on dependency groups. The installation command from learnings aligns with this behavior.

Caveat: A known issue exists where group-conditioned entries (editable and other fields) can behave unexpectedly in certain uv versions. Verify this configuration works with your target uv version before deployment.

[raptorsun]

/retest

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

README.md (1)

148-157: Polish quick-start “Run LCS locally” wording and typos

The new quick-start is helpful, but there are a few small text issues (grammar, capitalization, typo “shoud”) that are worth fixing since this is user-facing:

-To quickly get hands on LCS, we can run it using the default configurations provided in this repository:
+To quickly get hands-on with LCS, you can run it using the default configurations provided in this repository:

-1. check Llama stack settings in [run.yaml](run.yaml), make sure we can access the provider and the model, the server shoud listen to port 8321.
+1. Check Llama Stack settings in [run.yaml](run.yaml). Make sure you can access the provider and model, and that the server should listen on port 8321.
-2. export the LLM token env var that Llama stack requires. for OpenAI, we set the env var by `export OPENAI_API_KEY=sk-xxxxx`
+2. Export the LLM token environment variable that Llama Stack requires. For OpenAI, set it with `export OPENAI_API_KEY=sk-xxxxx`.
-3. start Llama stack server `uv run llama stack run run.yaml`
+3. Start the Llama Stack server: `uv run llama stack run run.yaml`
-5. check the LCS settings in [lightspeed-stack.yaml](lightspeed-stack.yaml). `llama_stack.url` should be `url: http://localhost:8321`
+5. Check the LCS settings in [lightspeed-stack.yaml](lightspeed-stack.yaml). `llama_stack.url` should be `url: http://localhost:8321`.
-6. start LCS server `make run`
+6. Start the LCS server: `make run`
-7. access LCS web UI at [http://localhost:8080/](http://localhost:8080/)
+7. Access the LCS web UI at [http://localhost:8080/](http://localhost:8080/).

🧹 Nitpick comments (2)

README.md (1)

18-19: Fix TOC list indentation to satisfy markdownlint MD007

markdownlint is flagging the new TOC entries for inconsistent indentation (MD007). The bullets added for lightspeed-stack, the macOS subsections, and the Konflux section use more spaces than expected for their nesting level.

Please normalize the indentation of these list items to match the rest of the generated TOC (typically 2 spaces per level), e.g.:

-* [lightspeed-stack](#lightspeed-stack)
-    * [About The Project](#about-the-project)
+* [lightspeed-stack](#lightspeed-stack)
+  * [About The Project](#about-the-project)

and similarly reduce indentation for the macOS and Konflux-related entries so markdownlint passes.

Also applies to: 55-57, 89-93

Containerfile (1)

25-36: Hermetic cachi2 branch looks good; consider small robustness tweaks

The new hermetic path is consistent with the Konflux docs and should work as intended:

• COPY ... requirements.*.txt plus requirements.$(uname -m).txt matches the documented requirements.x86_64.txt / requirements.aarch64.txt layout.
• Sourcing /cachi2/cachi2.env and using --no-index --find-links ${PIP_FIND_LINKS} ensures fully offline installs from the pre-fetched wheel cache, while the else branch preserves the original uv sync behavior.

A couple of minor hardening suggestions:

-RUN if [ -f /cachi2/cachi2.env ]; then \
-    . /cachi2/cachi2.env && uv venv --seed --no-index --find-links ${PIP_FIND_LINKS} && . .venv/bin/activate && pip install --no-index --find-links ${PIP_FIND_LINKS} -r requirements.$(uname -m).txt -r requirements.torch.txt; \
-    else \
-    uv sync --locked --no-dev --group llslibdev; \
-    fi
+RUN set -e; \
+    if [ -f /cachi2/cachi2.env ]; then \
+      . /cachi2/cachi2.env; \
+      uv venv --seed --no-index --find-links "${PIP_FIND_LINKS}"; \
+      . .venv/bin/activate; \
+      pip install --no-index --find-links "${PIP_FIND_LINKS}" \
+        -r "requirements.$(uname -m).txt" \
+        -r "requirements.torch.txt"; \
+    else \
+      uv sync --locked --no-dev --group llslibdev; \
+    fi

• set -e makes the step fail fast if any subcommand in the branch fails.
• Quoting ${PIP_FIND_LINKS} and the requirements filenames is a small safety improvement.
• It would also be worth double-checking that both requirements.x86_64.txt and requirements.aarch64.txt are always present in the build context so hermetic builds on each arch don’t hit a missing-file error.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between baecbc8 and 7e5de32.

⛔ Files ignored due to path filters (1)

• uv.lock is excluded by !**/*.lock

📒 Files selected for processing (8)

• .tekton/lightspeed-stack-pull-request.yaml (2 hunks)
• .tekton/lightspeed-stack-push.yaml (2 hunks)
• Containerfile (1 hunks)
• Makefile (2 hunks)
• README.md (9 hunks)
• pyproject.toml (1 hunks)
• requirements.torch.txt (1 hunks)
• scripts/remove_torch_deps.sh (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (6)

• .tekton/lightspeed-stack-pull-request.yaml
• pyproject.toml
• requirements.torch.txt
• .tekton/lightspeed-stack-push.yaml
• Makefile
• scripts/remove_torch_deps.sh

🧰 Additional context used

🧠 Learnings (2)

📚 Learning: 2025-08-18T10:56:55.349Z

Learnt from: matysek
Repo: lightspeed-core/lightspeed-stack PR: 292
File: pyproject.toml:0-0
Timestamp: 2025-08-18T10:56:55.349Z
Learning: The lightspeed-stack project intentionally uses a "generic image" approach, bundling many dependencies directly in the base runtime image to work for everyone, rather than using lean base images with optional dependency groups.

Applied to files:

• README.md

📚 Learning: 2025-11-24T16:58:04.410Z

Learnt from: CR
Repo: lightspeed-core/lightspeed-stack PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:58:04.410Z
Learning: Use `uv sync --group dev --group llslibdev` to install development dependencies

Applied to files:

• Containerfile

🪛 markdownlint-cli2 (0.18.1)

README.md

19-19: Unordered list indentation
Expected: 2; Actual: 4

(MD007, ul-indent)

---

55-55: Unordered list indentation
Expected: 6; Actual: 12

(MD007, ul-indent)

---

56-56: Unordered list indentation
Expected: 4; Actual: 8

(MD007, ul-indent)

---

57-57: Unordered list indentation
Expected: 6; Actual: 12

(MD007, ul-indent)

---

90-90: Unordered list indentation
Expected: 2; Actual: 4

(MD007, ul-indent)

---

91-91: Unordered list indentation
Expected: 4; Actual: 8

(MD007, ul-indent)

---

92-92: Unordered list indentation
Expected: 4; Actual: 8

(MD007, ul-indent)

---

93-93: Unordered list indentation
Expected: 4; Actual: 8

(MD007, ul-indent)

⏰ 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). (3)

• GitHub Check: build-pr
• GitHub Check: e2e_tests (azure)
• GitHub Check: e2e_tests (ci)

🔇 Additional comments (1)

README.md (1)

940-986: Konflux hermetic dependency docs align well with the build changes

The new Konflux section clearly explains when to regenerate dependency artifacts and how:

• make konflux-requirements producing requirements.x86_64.txt, requirements.aarch64.txt, and requirements.torch.txt matches the Containerfile’s requirements.$(uname -m).txt + requirements.torch.txt install path.
• The rpm-lockfile-prototype workflow (rpms.in.yaml → rpms.lock.yaml with --image $BASE_IMAGE and extracted ubi.repo) is consistent with typical hermetic RPM flows.

This looks coherent with the hermetic build strategy in the Containerfile; I don’t see issues here.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

README.md (1)

16-95: Address markdown list indentation issues flagged by linter.

The table of contents and list items have indentation inconsistencies flagged by markdownlint (MD007). Lines 19, 55–57, 90–93 need adjustment to use consistent 2-space indentation for top-level list items and 4-space for nested items. While this is optional in "chill" review mode, fixing these will improve consistency with markdown best practices.

Example fix for line 19:

-    * [About The Project](#about-the-project)
+  * [About The Project](#about-the-project)

Repeat similar fixes for other flagged lines.

scripts/remove_torch_deps.sh (1)

22-48: Consider adding validation that torch was actually found and removed.

The script silently succeeds even if the input file contains no torch entry. Adding a check to warn or report whether torch was found would improve operational observability:

# After awk processing, check if torch was removed
if diff -q "$INPUT_FILE" "$BACKUP_FILE" >/dev/null 2>&1; then
    echo "Warning: No changes made. Torch may not have been present in $INPUT_FILE"
fi

This is optional but would provide better diagnostics when troubleshooting build issues.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7e5de32 and c411ee5.

⛔ Files ignored due to path filters (1)

• uv.lock is excluded by !**/*.lock

📒 Files selected for processing (8)

• .tekton/lightspeed-stack-pull-request.yaml (2 hunks)
• .tekton/lightspeed-stack-push.yaml (2 hunks)
• Containerfile (1 hunks)
• Makefile (2 hunks)
• README.md (9 hunks)
• pyproject.toml (1 hunks)
• requirements.torch.txt (1 hunks)
• scripts/remove_torch_deps.sh (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (3)

• requirements.torch.txt
• .tekton/lightspeed-stack-push.yaml
• Containerfile

🧰 Additional context used

📓 Path-based instructions (1)

pyproject.toml

📄 CodeRabbit inference engine (CLAUDE.md)

pyproject.toml: Configure pylint with source-roots = "src"
Exclude src/auth/k8s.py from pyright type checking

Files:

• pyproject.toml

🧠 Learnings (2)

📚 Learning: 2025-11-24T16:58:04.410Z

Learnt from: CR
Repo: lightspeed-core/lightspeed-stack PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:58:04.410Z
Learning: Use `uv sync --group dev --group llslibdev` to install development dependencies

Applied to files:

• pyproject.toml

📚 Learning: 2025-08-18T10:56:55.349Z

Learnt from: matysek
Repo: lightspeed-core/lightspeed-stack PR: 292
File: pyproject.toml:0-0
Timestamp: 2025-08-18T10:56:55.349Z
Learning: The lightspeed-stack project intentionally uses a "generic image" approach, bundling many dependencies directly in the base runtime image to work for everyone, rather than using lean base images with optional dependency groups.

Applied to files:

• README.md

🪛 markdownlint-cli2 (0.18.1)

README.md

19-19: Unordered list indentation
Expected: 2; Actual: 4

(MD007, ul-indent)

---

55-55: Unordered list indentation
Expected: 6; Actual: 12

(MD007, ul-indent)

---

56-56: Unordered list indentation
Expected: 4; Actual: 8

(MD007, ul-indent)

---

57-57: Unordered list indentation
Expected: 6; Actual: 12

(MD007, ul-indent)

---

90-90: Unordered list indentation
Expected: 2; Actual: 4

(MD007, ul-indent)

---

91-91: Unordered list indentation
Expected: 4; Actual: 8

(MD007, ul-indent)

---

92-92: Unordered list indentation
Expected: 4; Actual: 8

(MD007, ul-indent)

---

93-93: Unordered list indentation
Expected: 4; Actual: 8

(MD007, ul-indent)

⏰ 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). (4)

• GitHub Check: build-pr
• GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
• GitHub Check: e2e_tests (ci)
• GitHub Check: e2e_tests (azure)

🔇 Additional comments (11)

.tekton/lightspeed-stack-pull-request.yaml (3)

33-33: Verify AWS instance type notation for multi-platform controller.

Line 33 uses linux-c6gd2xlarge/arm64 syntax, which mixes AWS instance type (c6gd2xlarge) with platform identifier. Confirm this is the intended format for your Konflux multi-platform-controller configuration and that the controller recognizes this notation.

---

36-37: Confirm prefetch-input requirements files are generated.

The prefetch-input references four requirement files: requirements.x86_64.txt, requirements.aarch64.txt, requirements.hermetic.txt, and requirements.torch.txt. Verify that these files exist in the repository or are generated before the pipeline runs (e.g., as part of the konflux-requirements Makefile target).

---

635-637: 4-hour pipeline timeout is reasonable for multi-platform hermetic builds.

The addition of timeouts.pipeline: 4h and timeouts.tasks: 4h provides sufficient headroom for prefetch operations and multi-platform builds with network isolation. Configuration looks appropriate.

pyproject.toml (2)

92-94: Verify uv version supports group attribute in [tool.uv.sources].

The torch entry now uses group = "llslibdev" within the sources configuration. Confirm that the version of uv used in your build process supports this syntax. If this is a recently-added feature or requires a minimum version, consider documenting the uv version requirement.

---

92-94: Torch version pinning aligns across pyproject.toml and Makefile.

Torch is consistently pinned to version 2.7.1 in both the llslibdev group (line 155) and the Makefile TORCH_VERSION variable (line 8 of Makefile). Grouping torch under llslibdev supports the hermetic build workflow where torch is prefetched and locked separately.

Makefile (2)

105-109: Verify --torch-backend cpu is a valid uv pip compile option.

Lines 105-106 use --torch-backend cpu flag when running uv pip compile. This flag may be a custom extension or require a specific uv version. Confirm that:

1. Your version of uv supports this flag
2. The flag is properly documented or tested in your CI/CD
3. The PyTorch CPU wheel resolution works as expected

If this is a non-standard option, consider adding a comment explaining its purpose or adding error handling.

---

104-109: Hermetic requirements generation pattern is sound, subject to uv option verification.

The konflux-requirements target implements a clear workflow: compile platform-specific deps → remove torch → separately pin torch to CPU index. This supports reproducible, hermetic builds. Structure and sequencing look correct, pending verification of uv command options (see separate comment on --torch-backend).

README.md (2)

940-985: Konflux section documentation is comprehensive and well-structured.

The new section clearly documents the hermetic build workflow, when to update dependencies, and step-by-step instructions for both Python and RPM dependency updates. Content aligns well with Makefile targets and build tool changes introduced in this PR. The explanation of hermetic mode and prefetching is appropriately detailed for users unfamiliar with Konflux.

---

128-128: Minor textual clarifications improve readability.

Small adjustments like "For example, if you choose to use OpenAI:" (line 128) and expanded LLM compatibility table improve the documentation flow and are appropriate refinements.

Also applies to: 148-148, 163-163, 184-184, 185-185

scripts/remove_torch_deps.sh (2)

1-55: Torch removal script is well-implemented with proper error handling.

The awk-based state machine correctly identifies and removes torch entries and their dependency lines (indented with 4 spaces). Error handling via set -e and file existence checks is appropriate. Backup mechanism and diff output provide good operational visibility.

---

28-42: State machine logic for torch removal is correct.

The awk state machine properly:

• Detects torch== entries (line 28)
• Enters removal state and skips subsequent indented lines (line 34–36)
• Exits removal state when encountering a non-indented line (line 39–42)
• Ensures only torch and its direct dependencies are removed

This prevents accidental removal of unrelated packages.

[gallettilance]

/lgtm

[radofuchs]

LGTM