[None][infra] Check in most recent lock file from nightly pipeline

[yuanjingx87]

Summary by CodeRabbit

• Chores
  • Added Poetry project configuration across many examples, model packs, docs, tests and tooling to standardize dependency declarations, Python compatibility (>=3.10,<3.13) and build-system settings (poetry-core).
  • Updated repository tooling configuration to exclude new paths from a codespell check.

Description

Test Coverage

PR Checklist

Please review the following before submitting your PR:

• PR description clearly explains what and why. If using CodeRabbit's summary, please make sure it makes sense.

• PR Follows TRT-LLM CODING GUIDELINES to the best of your knowledge.

• Test cases are provided for new code paths (see test instructions)

• Any new dependencies have been scanned for license and vulnerabilities

• CODEOWNERS updated if ownership changes

• Documentation updated as needed

• The reviewers assigned automatically/manually are appropriate for the PR.

• Please check this after reviewing the above items as appropriate for this PR.

GitHub Bot Help

/bot [-h] ['run', 'kill', 'skip', 'reuse-pipeline'] ...

Provide a user friendly way for developers to interact with a Jenkins server.

Run /bot [-h|--help] to print this help message.

See details below for each supported subcommand.

run [--reuse-test (optional)pipeline-id --disable-fail-fast --skip-test --stage-list "A10-PyTorch-1, xxx" --gpu-type "A30, H100_PCIe" --test-backend "pytorch, cpp" --add-multi-gpu-test --only-multi-gpu-test --disable-multi-gpu-test --post-merge --extra-stage "H100_PCIe-TensorRT-Post-Merge-1, xxx" --detailed-log --debug(experimental)]

Launch build/test pipelines. All previously running jobs will be killed.

--reuse-test (optional)pipeline-id (OPTIONAL) : Allow the new pipeline to reuse build artifacts and skip successful test stages from a specified pipeline or the last pipeline if no pipeline-id is indicated. If the Git commit ID has changed, this option will be always ignored. The DEFAULT behavior of the bot is to reuse build artifacts and successful test results from the last pipeline.

--disable-reuse-test (OPTIONAL) : Explicitly prevent the pipeline from reusing build artifacts and skipping successful test stages from a previous pipeline. Ensure that all builds and tests are run regardless of previous successes.

--disable-fail-fast (OPTIONAL) : Disable fail fast on build/tests/infra failures.

--skip-test (OPTIONAL) : Skip all test stages, but still run build stages, package stages and sanity check stages. Note: Does NOT update GitHub check status.

--stage-list "A10-PyTorch-1, xxx" (OPTIONAL) : Only run the specified test stages. Examples: "A10-PyTorch-1, xxx". Note: Does NOT update GitHub check status.

--gpu-type "A30, H100_PCIe" (OPTIONAL) : Only run the test stages on the specified GPU types. Examples: "A30, H100_PCIe". Note: Does NOT update GitHub check status.

--test-backend "pytorch, cpp" (OPTIONAL) : Skip test stages which don't match the specified backends. Only support [pytorch, cpp, tensorrt, triton]. Examples: "pytorch, cpp" (does not run test stages with tensorrt or triton backend). Note: Does NOT update GitHub pipeline status.

--only-multi-gpu-test (OPTIONAL) : Only run the multi-GPU tests. Note: Does NOT update GitHub check status.

--disable-multi-gpu-test (OPTIONAL) : Disable the multi-GPU tests. Note: Does NOT update GitHub check status.

--add-multi-gpu-test (OPTIONAL) : Force run the multi-GPU tests in addition to running L0 pre-merge pipeline.

--post-merge (OPTIONAL) : Run the L0 post-merge pipeline instead of the ordinary L0 pre-merge pipeline.

--extra-stage "H100_PCIe-TensorRT-Post-Merge-1, xxx" (OPTIONAL) : Run the ordinary L0 pre-merge pipeline and specified test stages. Examples: --extra-stage "H100_PCIe-TensorRT-Post-Merge-1, xxx".

--detailed-log (OPTIONAL) : Enable flushing out all logs to the Jenkins console. This will significantly increase the log volume and may slow down the job.

--debug (OPTIONAL) : Experimental feature. Enable access to the CI container for debugging purpose. Note: Specify exactly one stage in the stage-list parameter to access the appropriate container environment. Note: Does NOT update GitHub check status.

For guidance on mapping tests to stage names, see docs/source/reference/ci-overview.md
and the scripts/test_to_stage_mapping.py helper.

kill

kill

Kill all running builds associated with pull request.

skip

skip --comment COMMENT

Skip testing for latest commit on pull request. --comment "Reason for skipping build/test" is required. IMPORTANT NOTE: This is dangerous since lack of user care and validation can cause top of tree to break.

reuse-pipeline

reuse-pipeline

Reuse a previous pipeline to validate current commit. This action will also kill all currently running builds associated with the pull request. IMPORTANT NOTE: This is dangerous since lack of user care and validation can cause top of tree to break.

[coderabbitai]

Caution

Review failed

Failed to post review comments

📝 Walkthrough

Walkthrough

Adds ~56 new Poetry pyproject.toml manifest files across security_scanning (root, docs, examples, models, tests, triton backend, cpp kernels) and updates .pre-commit-config.yaml skip patterns.

Changes

Cohort / File(s)	Summary
Root & Backends security_scanning/pyproject.toml, security_scanning/triton_backend/pyproject.toml	New top-level Poetry manifests defining project metadata and root/back-end dependencies and build-system configuration.
Tests / Perf security_scanning/tests/integration/defs/perf/pyproject.toml	New Poetry manifest for integration/perf tests with pandas/numpy/matplotlib dependencies.
C++ Kernels & Docs security_scanning/cpp/kernels/fmha_v2/pyproject.toml, security_scanning/docs/pyproject.toml	New manifests for C++ kernel testing (pytest & plugins) and documentation (Sphinx & extensions).
Examples — Apps / Orchestrator / Serve / Auto-deploy security_scanning/examples/apps/pyproject.toml, security_scanning/examples/serve/pyproject.toml, security_scanning/examples/auto_deploy/pyproject.toml, security_scanning/examples/ray_orchestrator/pyproject.toml	New Poetry manifests for example application packages (colorama, openai, ai-edge-model-explorer, lm-eval, ray, etc.).
Examples — Evaluation & Benchmarks security_scanning/examples/llm-eval/lm-eval-harness/pyproject.toml, security_scanning/examples/trtllm-eval/pyproject.toml, security_scanning/examples/longbench/pyproject.toml, security_scanning/examples/ngram/pyproject.toml, security_scanning/examples/quantization/pyproject.toml	New manifests for evaluation/benchmark examples (lm-eval, datasets, rouge-score, longbench deps).
Examples — Optimization / Technique Examples security_scanning/examples/draft_target_model/pyproject.toml, security_scanning/examples/eagle/pyproject.toml, security_scanning/examples/lookahead/pyproject.toml, security_scanning/examples/medusa/pyproject.toml, security_scanning/examples/redrafter/pyproject.toml	New manifests sharing dataset/evaluation-related dependencies for optimization examples.
Examples — Model Contrib (grouped) security_scanning/examples/models/contrib/{baichuan,bloom,chatglm-6b,chatglm2-6b,chatglm3-6b-32k,dbrx,deepseek_v1,deepseek_v2,falcon,gptj,gptneox,grok,hyperclovax,internlm,jais,mmdit,mpt,opt,skywork,smaug,stdit}/pyproject.toml	New manifests for contributed model examples with varying ML dependencies (datasets, evaluate, rouge-score, sentencepiece, transformers, jaxlib, protobuf, tiktoken, cpm-kernels, etc.).
Examples — Model Core (grouped) security_scanning/examples/models/core/{commandr,gemma,glm-4-9b,gpt,internlm2,llama,mamba,mixtral,mllama,nemotron,phi,qwen,qwen2audio,qwenvl,recurrentgemma,whisper}/pyproject.toml	New manifests for core model examples with model-specific dependencies (transformers, datasets, evaluate, tiktoken, einops, protobuf, nvidia-modelopt, etc.).
Examples — Other / Scaffolding / Apps security_scanning/examples/longbench/pyproject.toml, security_scanning/examples/ngram/pyproject.toml, security_scanning/examples/scaffolding/contrib/Dynasor/pyproject.toml, security_scanning/examples/serve/pyproject.toml	Additional example manifests for benchmarking, ngram examples, Dynasor scaffolding, and serve examples.
CPP Kernel Tests security_scanning/cpp/kernels/fmha_v2/pyproject.toml	Manifest added for C++ kernel test environment (pytest, pytest-cpp, pytest-xdist).
Pre-commit .pre-commit-config.yaml	Updated codespell hook args: appended security_scanning/* to skip patterns.

Sequence Diagram(s)

(No sequence diagram generated — changes are configuration/manifest additions without new runtime control flow.)

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

• Rationale: Large number (~56) of homogeneous file additions (Poetry pyproject.toml) with consistent structure and repeated patterns.
• Areas to focus during review:
  • root security_scanning/pyproject.toml (comprehensive dependency list, git-based dependency entries)
  • consistency of Python version constraints across manifests (mostly >=3.10,<3.13)
  • any model-specific manifests that include platform- or GPU-specific extras (e.g., jaxlib, cuda extras)
  • .pre-commit-config.yaml change to ensure the updated skip pattern is intentional and scoped correctly.

Pre-merge checks and finishing touches

❌ Failed checks (3 warnings)

Check name	Status	Explanation	Resolution
Title Check	⚠️ Warning	The pull request title states "[None][infra] Check in most recent lock file from nightly pipeline," but the raw summary shows the actual changes consist of adding or modifying approximately 61 pyproject.toml configuration files across the security_scanning/ directory structure, along with an update to .pre-commit-config.yaml. The title specifically references checking in a "lock file," while the substantive changes are Poetry project configuration files (pyproject.toml), not lock files themselves. This represents a mismatch between the stated intent in the title and the actual file modifications present in the changeset.	The title should be revised to accurately reflect that the PR is checking in pyproject.toml configuration files rather than lock files, or clarify the relationship between these configuration files and any lock files generated by the nightly pipeline. A corrected title might be something like "[None][infra] Add Poetry configuration files (pyproject.toml) for security scanning modules" or similar, depending on the actual intent of the changes.
Description Check	⚠️ Warning	The pull request description consists entirely of the repository's PR template with all required sections unfilled. The Description section contains only an HTML comment placeholder with no explanation of what is being changed or why. The Test Coverage section is similarly empty with only a placeholder comment. The PR Checklist section has only a single checkbox marked [x] with the generic comment "Please check this after reviewing the above items as appropriate for this PR," rather than substantive review of the listed items. None of the critical information required by the template—what the change does, why it is needed, and what tests validate it—has been provided.	The author must fill in the Description section with a clear explanation of the changes being made and the rationale behind checking in these pyproject.toml files. The Test Coverage section should document relevant tests that validate the changes. Lastly, the PR Checklist items should be thoughtfully reviewed and addressed rather than marked as complete with a generic placeholder comment.
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✨ Finishing touches

🧪 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: 65

🧹 Nitpick comments (21)

security_scanning/examples/ngram/pyproject.toml (2)

1-6: Add meaningful description for package metadata.

The description field on line 4 is empty. Consider providing a brief description of what this example demonstrates (e.g., "N-gram language model examples and utilities").

-description = ""
+description = "N-gram model examples"

---

8-14: Clarify the dependency versioning strategy.

The dependencies use inconsistent version specification strategies:

• datasets = "3.1.0" — pinned to exact version
• rouge-score = "^0.1.2", evaluate = "^0.4.6", ordered-set = "^4.1.0" — caret ranges (allow patch/minor updates)
• sentencepiece = ">=0.1.99,<0.2.0" — range constraint

Pinning datasets to an exact version while allowing ranges for other packages suggests it may be critical for reproducibility. Clarify whether this intentional or if dependencies should be more consistently versioned. If reproducibility is important across environments, consider generating a poetry.lock file (which would align with the PR objective of checking in lock files).

security_scanning/examples/models/core/mamba/pyproject.toml (1)

10-14: Standardize dependency version constraints.

Dependencies use inconsistent versioning strategies: pinned (datasets), ranges (transformers), and caret operators (evaluate, rouge-score, sentencepiece). Choose a consistent strategy across all dependencies for predictability and maintainability.

security_scanning/examples/models/contrib/chatglm-6b/pyproject.toml (1)

9-15: Standardize dependency version pinning strategy.

The file mixes exact version pins (e.g., datasets = "3.1.0") with caret range specifiers (e.g., evaluate = "^0.4.6"). This inconsistency can lead to unexpected dependency updates. Adopt a consistent strategy across all dependencies—either pin all versions exactly for reproducibility, or use consistent caret/tilde ranges to allow patch updates.

security_scanning/examples/models/contrib/chatglm3-6b-32k/pyproject.toml (1)

10-15: Align dependency versioning strategy.

Dependencies use inconsistent version constraints: datasets is pinned to an exact version (3.1.0), while others use compatible release ranges (^). Exact pinning for datasets may cause unnecessary conflicts. Consider using a consistent strategy across all dependencies (either all pinned or all using ranges).

Apply this diff to harmonize versioning:

-datasets = "3.1.0"
+datasets = "^3.1.0"

security_scanning/examples/models/core/whisper/pyproject.toml (1)

8-18: Standardize dependency version constraints.

The dependencies use inconsistent version specification styles: some use caret ranges (e.g., tiktoken = "^0.12.0") while others use exact versions (e.g., datasets = "3.1.0"). Adopt a consistent strategy across all dependencies.

Additionally, verify that datasets = "3.1.0" is the intended exact pinning or should use a range like the other dependencies.

-datasets = "3.1.0"
+datasets = "^3.1.0"

security_scanning/examples/redrafter/pyproject.toml (1)

4-4: Add meaningful project description.

The description field is empty, reducing clarity about the project's purpose.

Apply this diff:

- description = ""
+ description = "Examples for the RedRafter project"

security_scanning/examples/quantization/pyproject.toml (2)

1-19: Inconsistent version pinning strategy across dependencies.

Caret requirements allow SemVer compatible updates—an update is allowed if the new version number does not modify the left-most non-zero digit. The file mixes exact pins (e.g., datasets = "3.1.0") with caret constraints (e.g., rouge-score = "^0.1.2"), which creates maintenance friction and potential resolution issues.

Additionally, Line 11 uses caret on rouge-score = "^0.1.2", which allows versions up to <1.0.0—be aware this may pull in significant changes between 0.1.2 and 0.1.x.

Consider standardizing on one versioning strategy across the project (e.g., adopt caret constraints consistently for all public APIs following semantic versioning, or pin versions more explicitly if reproducibility is critical). If reproducibility is essential, ensure corresponding poetry.lock files are checked in.

---

4-4: Empty description field should be populated.

An empty description reduces the package's usability if published to PyPI or used by others. Add a meaningful description of the quantization examples project.

security_scanning/examples/lookahead/pyproject.toml (2)

1-18: Inconsistent version pinning and unbounded constraints.

This file exhibits similar inconsistencies to the quantization example: exact pins (datasets = "3.1.0"), caret constraints (rouge-score = "^0.1.2", evaluate = "^0.4.6"), and floor-only constraints (sentencepiece = ">=0.1.99"). Additionally, sentencepiece lacks an upper bound, which could allow unbounded minor/major version jumps.

Committing poetry.lock to version control ensures reproducible builds and mitigates bugs affecting only some deployments.

Standardize versioning constraints and ensure poetry.lock is checked in for reproducibility.

---

4-4: Empty description should be populated.

security_scanning/triton_backend/pyproject.toml (2)

1-19: Inconsistent version pinning; verify regex version timeliness.

This file mixes exact pins (transformers = "4.56.0") with caret constraints (others), creating inconsistency. Notably, regex = "^2025.10.23" is an extremely recent version (calendar-based versioning, dated 2025-10-23) that may have been generated by a nightly pipeline. Verify that this is intentional and that the version resolves without conflicts.

Standardize versioning strategy and confirm that the recent regex version is stable and appropriate for production use. If this is indeed the "most recent lock file" referenced in the PR title, consider whether a corresponding poetry.lock file should also be committed.

---

4-4: Empty description should be populated.

security_scanning/examples/ray_orchestrator/pyproject.toml (1)

1-15: LGTM – well-structured with appropriate versioning.

The use of caret constraints on a single modern dependency with proper table notation for extras is clean. Project name "ray-orchestrator-examples" is descriptive.

Consider adding a description to the [tool.poetry] section for better metadata, though not critical for this minimal example.

security_scanning/examples/models/core/gemma/pyproject.toml (1)

1-19: Inconsistent version pinning across dependencies.

This file uses exact pins for some packages (datasets, safetensors as ranges), carets for others (rouge-score, nltk), and floor-only constraints (sentencepiece). Standardize the versioning strategy for maintainability.

security_scanning/examples/models/core/nemotron/pyproject.toml (1)

1-17: Standardize version constraints and add description.

Similar to other files, versioning is inconsistent (exact pin for datasets, carets for others). Additionally, the description is empty.

security_scanning/examples/longbench/pyproject.toml (1)

1-17: LGTM – clean and consistent versioning approach.

This file correctly uses caret constraints consistently across all dependencies and has a proper project name. The configuration follows Poetry best practices.

Add a brief description to the [tool.poetry] section for better package metadata.

security_scanning/examples/serve/pyproject.toml (1)

1-14: Clean structure, but add description.

The project metadata looks good with proper name alignment. Add a descriptive string in the description field (currently empty) to clarify the module's purpose.

  [tool.poetry]
  name = "serve-examples"
  version = "0.1.0"
- description = ""
+ description = "Serving examples for TensorRT-LLM"
  authors = ["TensorRT LLM [[email protected]]"]

security_scanning/examples/eagle/pyproject.toml (1)

1-18: Clarify dependency versioning strategy.

The project has mixed version constraints across dependencies (exact pin, caret, and range constraints). Standardize the versioning approach for maintainability. If these versions derive from a lock file, document this assumption clearly or use lock files consistently.

For example, if pinning is required, use exact versions for all:

  [tool.poetry.dependencies]
  python = ">=3.10,<3.13"
  datasets = "3.1.0"
  rouge-score = "^0.1.2"
- sentencepiece = ">=0.1.99,<0.2.0"
+ sentencepiece = "0.1.99"  # or use consistent constraint style
  evaluate = "^0.4.6"

Also add a description field to clarify the module's purpose.

security_scanning/examples/medusa/pyproject.toml (1)

1-18: Standardize dependency versioning.

While the project name is well-aligned, the dependency versioning is inconsistent: datasets is pinned (3.1.0), sentencepiece uses a range (>=0.1.99), and others use caret constraints. Adopt a single versioning strategy for clarity and maintainability.

  [tool.poetry.dependencies]
  python = ">=3.10,<3.13"
  datasets = "^3.1.0"  # or standardize all to exact versions
  rouge-score = "^0.1.2"
- sentencepiece = ">=0.1.99"
+ sentencepiece = "^0.1.99"
  evaluate = "^0.4.6"

Also add a description field for clarity.

security_scanning/examples/models/contrib/mmdit/pyproject.toml (1)

4-4: Empty description provides no package context.

Consider adding a brief description of what this package/module does.

📜 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 0ee71d9 and 0e62186.

⛔ Files ignored due to path filters (56)

• security_scanning/cpp/kernels/fmha_v2/poetry.lock is excluded by !**/*.lock
• security_scanning/docs/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/apps/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/auto_deploy/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/draft_target_model/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/eagle/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/llm-eval/lm-eval-harness/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/longbench/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/lookahead/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/medusa/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/baichuan/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/bloom/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/chatglm-6b/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/chatglm2-6b/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/chatglm3-6b-32k/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/dbrx/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/deepseek_v1/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/deepseek_v2/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/falcon/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/gptj/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/gptneox/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/grok/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/hyperclovax/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/internlm/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/jais/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/mmdit/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/mpt/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/opt/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/skywork/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/smaug/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/contrib/stdit/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/core/commandr/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/core/gemma/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/core/glm-4-9b/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/core/gpt/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/core/internlm2/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/core/llama/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/core/mamba/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/core/mixtral/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/core/mllama/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/core/nemotron/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/core/phi/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/core/qwen/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/core/qwen2audio/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/core/qwenvl/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/core/recurrentgemma/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/models/core/whisper/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/ngram/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/quantization/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/ray_orchestrator/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/redrafter/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/scaffolding/contrib/Dynasor/poetry.lock is excluded by !**/*.lock
• security_scanning/examples/trtllm-eval/poetry.lock is excluded by !**/*.lock
• security_scanning/poetry.lock is excluded by !**/*.lock
• security_scanning/tests/integration/defs/perf/poetry.lock is excluded by !**/*.lock
• security_scanning/triton_backend/poetry.lock is excluded by !**/*.lock

📒 Files selected for processing (57)

• security_scanning/cpp/kernels/fmha_v2/pyproject.toml (1 hunks)
• security_scanning/docs/pyproject.toml (1 hunks)
• security_scanning/examples/apps/pyproject.toml (1 hunks)
• security_scanning/examples/auto_deploy/pyproject.toml (1 hunks)
• security_scanning/examples/draft_target_model/pyproject.toml (1 hunks)
• security_scanning/examples/eagle/pyproject.toml (1 hunks)
• security_scanning/examples/llm-eval/lm-eval-harness/pyproject.toml (1 hunks)
• security_scanning/examples/longbench/pyproject.toml (1 hunks)
• security_scanning/examples/lookahead/pyproject.toml (1 hunks)
• security_scanning/examples/medusa/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/baichuan/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/bloom/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/chatglm-6b/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/chatglm2-6b/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/chatglm3-6b-32k/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/dbrx/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/deepseek_v1/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/deepseek_v2/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/falcon/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/gptj/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/gptneox/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/grok/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/hyperclovax/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/internlm/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/jais/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/mmdit/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/mpt/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/opt/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/skywork/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/smaug/pyproject.toml (1 hunks)
• security_scanning/examples/models/contrib/stdit/pyproject.toml (1 hunks)
• security_scanning/examples/models/core/commandr/pyproject.toml (1 hunks)
• security_scanning/examples/models/core/gemma/pyproject.toml (1 hunks)
• security_scanning/examples/models/core/glm-4-9b/pyproject.toml (1 hunks)
• security_scanning/examples/models/core/gpt/pyproject.toml (1 hunks)
• security_scanning/examples/models/core/internlm2/pyproject.toml (1 hunks)
• security_scanning/examples/models/core/llama/pyproject.toml (1 hunks)
• security_scanning/examples/models/core/mamba/pyproject.toml (1 hunks)
• security_scanning/examples/models/core/mixtral/pyproject.toml (1 hunks)
• security_scanning/examples/models/core/mllama/pyproject.toml (1 hunks)
• security_scanning/examples/models/core/nemotron/pyproject.toml (1 hunks)
• security_scanning/examples/models/core/phi/pyproject.toml (1 hunks)
• security_scanning/examples/models/core/qwen/pyproject.toml (1 hunks)
• security_scanning/examples/models/core/qwen2audio/pyproject.toml (1 hunks)
• security_scanning/examples/models/core/qwenvl/pyproject.toml (1 hunks)
• security_scanning/examples/models/core/recurrentgemma/pyproject.toml (1 hunks)
• security_scanning/examples/models/core/whisper/pyproject.toml (1 hunks)
• security_scanning/examples/ngram/pyproject.toml (1 hunks)
• security_scanning/examples/quantization/pyproject.toml (1 hunks)
• security_scanning/examples/ray_orchestrator/pyproject.toml (1 hunks)
• security_scanning/examples/redrafter/pyproject.toml (1 hunks)
• security_scanning/examples/scaffolding/contrib/Dynasor/pyproject.toml (1 hunks)
• security_scanning/examples/serve/pyproject.toml (1 hunks)
• security_scanning/examples/trtllm-eval/pyproject.toml (1 hunks)
• security_scanning/pyproject.toml (1 hunks)
• security_scanning/tests/integration/defs/perf/pyproject.toml (1 hunks)
• security_scanning/triton_backend/pyproject.toml (1 hunks)

🧰 Additional context used

🧠 Learnings (3)

📚 Learning: 2025-08-01T15:14:45.673Z

Learnt from: yibinl-nvidia
PR: NVIDIA/TensorRT-LLM#6506
File: examples/models/core/mixtral/requirements.txt:3-3
Timestamp: 2025-08-01T15:14:45.673Z
Learning: In TensorRT-LLM, examples directory can have different dependency versions than the root requirements.txt file. Version conflicts between root and examples dependencies are acceptable because examples are designed to be standalone and self-contained.

Applied to files:

• security_scanning/pyproject.toml
• security_scanning/examples/trtllm-eval/pyproject.toml

📚 Learning: 2025-08-06T13:58:07.506Z

Learnt from: galagam
PR: NVIDIA/TensorRT-LLM#6487
File: tests/unittest/_torch/auto_deploy/unit/singlegpu/test_ad_trtllm_bench.py:1-12
Timestamp: 2025-08-06T13:58:07.506Z
Learning: In TensorRT-LLM, test files (files under tests/ directories) do not require NVIDIA copyright headers, unlike production source code files. Test files typically start directly with imports, docstrings, or code.

Applied to files:

• security_scanning/pyproject.toml

📚 Learning: 2025-08-27T14:23:55.566Z

Learnt from: ixlmar
PR: NVIDIA/TensorRT-LLM#7294
File: tensorrt_llm/_torch/modules/rms_norm.py:17-17
Timestamp: 2025-08-27T14:23:55.566Z
Learning: The TensorRT-LLM project requires Python 3.10+ as evidenced by the use of TypeAlias from typing module, match/case statements, and union type | syntax throughout the codebase, despite some documentation still mentioning Python 3.8+.

Applied to files:

• security_scanning/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). (1)

• GitHub Check: Pre-commit Check

🔇 Additional comments (43)

security_scanning/examples/ngram/pyproject.toml (1)

9-9: Verify Python version upper bound.

The constraint >=3.10,<3.13 excludes Python 3.13 and beyond. Verify this is intentional, especially since Python 3.13 is now stable. Consider extending to <3.14 or <4.0 if these dependencies support newer Python versions.

security_scanning/examples/models/core/mamba/pyproject.toml (2)

6-6: Verify README exists and validate dependency versions.

Line 6 references README.md, and dependency versions (especially transformers>=4.56.0 and datasets=3.1.0) should be validated to ensure they exist and are compatible.

Also applies to: 10-14

---

1-19: Clarify PR intent: lock file vs. configuration file.

The PR objective states "check in most recent lock file from nightly pipeline," but the file provided is pyproject.toml (source configuration), not poetry.lock (lock file). Confirm whether this is the intended file or if poetry.lock should be provided instead.

security_scanning/examples/scaffolding/contrib/Dynasor/pyproject.toml (1)

1-16: Verify lock file alignment with PR objectives.

The PR objectives state the intent is to "check in the most recent lock file from nightly pipeline," but this file is a pyproject.toml configuration file, not a lock file. Ensure that a corresponding poetry.lock file is also being checked in alongside this configuration, as the lock file is what captures reproducible dependency versions from the nightly pipeline.

security_scanning/examples/models/contrib/deepseek_v1/pyproject.toml (3)

9-9: Verify Python version constraint.

The constraint >=3.10,<3.13 excludes Python 3.13. Confirm whether this exclusion is intentional due to known incompatibilities, or if it should be updated to >=3.10,<3.14 (or similar) to support newer Python versions.

---

15-17: Build system configuration is correct.

The build-system section correctly specifies poetry-core with appropriate backend configuration.

---

1-17: Clarify PR scope: pyproject.toml vs lock file.

The PR title states "Check in most recent lock file from nightly pipeline," but the file under review is a pyproject.toml configuration file, not a poetry.lock file. Verify whether:

1. This PR is intended to check in poetry.lock files (which should be included alongside this pyproject.toml)
2. The PR scope is limited to adding pyproject.toml files
3. Additional lock files should be part of this PR but are missing

If lock files are part of this PR, ensure they are included in the changeset.

security_scanning/examples/models/contrib/chatglm-6b/pyproject.toml (1)

1-20: Clarify PR scope and verify lock file integration.

The PR objectives state that this PR checks in "the most recent lock file from nightly pipeline", but only a pyproject.toml configuration file is provided. Typically, lock files are poetry.lock files that are generated from pyproject.toml. Clarify whether a poetry.lock file should also be included, and explain how this configuration integrates with the nightly pipeline's output.

security_scanning/examples/models/core/mixtral/pyproject.toml (1)

10-11: Remove incorrect premise; 4.56.0 is a valid released version.

The latest transformers release on PyPI is 4.57.1 (uploaded Oct 14, 2025). The pinned version 4.56.0 is not "beyond current release timelines"—it is a legitimate, recently released version. The original concern was based on faulty information and should be disregarded.

Strict version pinning is often intentional for reproducibility in production environments; relaxing constraints is a trade-off decision that depends on your project's maintenance strategy, not a requirement.

Likely an incorrect or invalid review comment.

security_scanning/examples/models/contrib/chatglm3-6b-32k/pyproject.toml (4)

9-9: Verify Python 3.13 exclusion is intentional.

The constraint python = ">=3.10,<3.13" explicitly excludes Python 3.13. For an example project, please verify whether this exclusion is necessary due to known incompatibilities with dependencies, or if the range should be widened to ">=3.10,<3.14" or similar.

---

6-6: Verify README.md file exists.

The readme field references README.md. Ensure this file exists in the same directory, otherwise Poetry package builds may fail.

---

18-20: Build system configuration looks good.

The Poetry build system configuration is standard and correct.

---

1-20: Verify lock file is also committed per PR objectives.

The PR objectives state this is about "checking in the most recent lock file from the nightly pipeline," but only a pyproject.toml file is provided. Please confirm whether a poetry.lock file has also been committed to satisfy the PR objectives, or clarify if the lock file is in a separate commit/PR.

security_scanning/examples/models/contrib/bloom/pyproject.toml (1)

1-18: The review comment is factually incorrect—poetry.lock was committed.

The git history confirms that poetry.lock was included in the same commit (0e62186) alongside pyproject.toml, with the commit message "[None][infra] Check in most recent lock file from nightly pipeline." The file contains 2,157 lines of valid Poetry metadata with proper package definitions and checksums. Both files are currently present in the repository and the PR objective has been satisfied.

Likely an incorrect or invalid review comment.

security_scanning/examples/models/core/qwen/pyproject.toml (2)

6-6: Verify README.md exists in this location.

The readme field references "README.md", but it's unclear whether this file exists at security_scanning/examples/models/core/qwen/README.md. If the README is located elsewhere or doesn't exist, this will cause build or installation warnings.

---

1-6: README.md is referenced but does not exist; consider whether it should be added or removed from pyproject.toml.

The package name "unknown-package" is intentional and consistent across all model example configurations in this repository (baichuan, chatglm-6b, falcon, etc.). Both pyproject.toml and poetry.lock coexisting is standard for Poetry projects. However, the pyproject.toml references a README.md file that does not exist in the directory, which may cause issues during packaging or deployment. Either add the README.md file or remove the reference from the configuration.

Likely an incorrect or invalid review comment.

security_scanning/examples/redrafter/pyproject.toml (2)

8-13: ****

This review misunderstands Poetry's versioning model. In Poetry projects, pyproject.toml defines version constraints (what's acceptable), while poetry.lock provides deterministic pinning (what actually installs). The presence of a poetry.lock file in this directory confirms the correct workflow is in place.

The mixed versioning strategy observed—fully pinned datasets, caret constraints for rouge-score and evaluate, and flexible bounds for sentencepiece—is intentional and standard practice. This exact same pattern appears across multiple similar projects in the repository (e.g., draft_target_model, lookahead, medusa), indicating a consistent, deliberate design choice.

No changes are needed. The code follows Poetry conventions correctly.

Likely an incorrect or invalid review comment.

---

1-18: The original review comment is incorrect.

The review assumes the PR only contains pyproject.toml and criticizes it for not being a lock file. However, verification shows the commit includes both security_scanning/examples/redrafter/poetry.lock and security_scanning/examples/redrafter/pyproject.toml. The PR objective—to check in the most recent lock file from the nightly pipeline—is being fulfilled: both lock files (poetry.lock) and their accompanying configuration files (pyproject.toml) are being checked in across all directories. This is the standard practice in Poetry-based projects where both files are committed together to track reproducible dependencies.

Likely an incorrect or invalid review comment.

security_scanning/examples/models/contrib/skywork/pyproject.toml (2)

1-18: Verify alignment with PR objectives: Missing lock file.

The PR objectives state the goal is to check in "the most recent lock file from the nightly pipeline." However, only pyproject.toml appears in this review—no poetry.lock file is present.

Clarify:

1. Should poetry.lock (if generated by the nightly pipeline) also be committed?
2. Is this pyproject.toml intended as a template for the lock file, or is the lock file missing from the review context?

---

8-13: Versioning inconsistency exists but poetry.lock already checked in.

The observation about mixed version constraints is accurate—datasets uses exact pinning, evaluate and rouge-score use caret, and sentencepiece uses >=. This pattern is consistent across multiple contrib models (baichuan, bloom).

However, poetry.lock already exists in the skywork directory and is checked in, which captures the resolved dependency state for reproducibility. The lock file satisfies the stated concern about reproducibility from nightly builds.

Decision needed: Determine whether standardizing the version constraints in pyproject.toml is still required for maintainability, or if the existing lock file is sufficient. If standardizing, align all dependencies to a consistent constraint strategy (recommend exact pinning for reproducibility, or document the chosen strategy inline).

security_scanning/examples/models/contrib/deepseek_v2/pyproject.toml (3)

6-6: Verify README.md exists in this directory.

Line 6 references readme = "README.md". Please confirm that security_scanning/examples/models/contrib/deepseek_v2/README.md exists to avoid missing-file warnings during packaging.

---

9-12: Clarify the rationale for mixed version-pinning strategies.

The dependencies use inconsistent version constraints: datasets is pinned to an exact version (3.1.0), while evaluate and rouge-score use ranges. If this file is auto-generated from a lock file, all dependencies should typically be exact-pinned or use consistent strategies. Verify that this mixed approach reflects the intended policy or is an artifact of the pipeline generation logic.

---

1-6: This appears to be an auto-generated lock file with standard template values—not a deepseek_v2-specific issue.

The "unknown-package" name and empty description are systematically applied across ~36 pyproject.toml files throughout the models/contrib/ and models/core/ directories. Additionally, all these files reference "README.md" but none of them contain such files. This consistent pattern—combined with identical author attribution and the PR's stated objective of checking in lock files from the nightly pipeline—indicates these are auto-generated artifacts with intentional template values, not files requiring manual intervention per deepseek_v2 specifically.

If this structure is unintended, the issue extends across the entire model examples suite and should be addressed at the pipeline/generation level rather than on individual files.

Likely an incorrect or invalid review comment.

security_scanning/examples/models/core/recurrentgemma/pyproject.toml (2)

6-6: Verify README.md exists and confirm build backend.

Line 6 references readme = "README.md", which must exist in the same directory for Poetry to build successfully. Ensure this file is present.

The build system (lines 21–23) correctly specifies poetry-core, which is the standard and recommended backend for Poetry projects.

Also applies to: 21-23

---

8-18: All concerns verified and resolved — no action required.

The verification confirms:

1. poetry.lock file IS committed (308KB with fully pinned versions for all transitive dependencies).

2. Mixed versioning constraints in pyproject.toml are standard and intentional: Poetry uses flexible constraints in pyproject.toml for development/compatibility while poetry.lock provides reproducible pinned versions. This dual approach ensures both flexibility during development and reproducibility in production.

3. All declared dependencies (flax, jax, transformers, datasets, evaluate, rouge-score, sentencepiece, jaxtyping) support Python 3.10–3.13.

The PR correctly implements the stated objective to "check in the most recent lock file from nightly pipeline" while maintaining appropriate development constraints in pyproject.toml.

security_scanning/examples/models/contrib/smaug/pyproject.toml (2)

16-18: Build-system configuration is consistent across all pyproject.toml files.

Verification confirms that the build-system configuration in security_scanning/examples/models/contrib/smaug/pyproject.toml aligns with all other pyproject.toml files in the security_scanning directory. All files uniformly specify poetry-core with build-backend = "poetry.core.masonry.api". No inconsistencies detected.

---

8-13: Remove review comment—it contains factual errors and misses existing lock file.

The review's concerns are unfounded:

1. poetry.lock exists: The review asks if a lock file accompanies this change, but security_scanning/examples/models/contrib/smaug/poetry.lock is already present (246 KB). This ensures reproducible builds as-is.

2. sentencepiece release date is incorrect: The review claims 0.1.99 was released "~2020," but version 0.1.99 was released on May 2, 2023. This is recent, not a decade-old dependency posing compatibility risks.

3. The suggested fix is flawed: Changing to ^0.1.2 would allow versions from 0.1.2 to <0.2.0—a downgrade from the pinned 0.1.99. For 0.y.z versions, ^0.1.99 allows SemVer-compatible updates >=0.1.99 and < 0.2.0, which is already appropriate for pre-1.0 libraries.

The inconsistency in versioning strategies (exact pin for datasets, ranges for others) is a minor style observation, but the justification in the review does not apply here.

Likely an incorrect or invalid review comment.

security_scanning/examples/models/core/internlm2/pyproject.toml (1)

1-15: No consistency issues found across pyproject.toml files.

Verification confirms all 37 pyproject.toml files in security_scanning/examples/models/ maintain consistent patterns:

• Package naming: All use "unknown-package"
• Author attribution: All use "TensorRT LLM [[email protected]]"
• Python version: All specify ">=3.10,<3.13"

Dependency variations across files (e.g., einops present in only 5 files) are appropriate and expected for model-specific requirements. The standardized template approach ensures maintainability.

security_scanning/examples/models/contrib/chatglm2-6b/pyproject.toml (1)

8-15: No action needed—mixed pinning strategy is correct as-is.

The pyproject.toml uses a legitimate mixed pinning approach: datasets is exact-pinned while others use caret ranges. This is standard practice in Poetry projects. When poetry.lock is present (which it is), all dependencies are locked to exact versions regardless of pyproject.toml ranges, ensuring reproducible installs across environments. Exact pinning is appropriately applied to packages requiring specific version testing, while ranges are used for stable dependencies. This pattern avoids the stated concern entirely.

Likely an incorrect or invalid review comment.

security_scanning/tests/integration/defs/perf/pyproject.toml (1)

11-11: Review comment is incorrect; no changes needed.

The constraint numpy = "<2" does not conflict with the dependencies. Pandas 2.3.3 requires numpy >= 1.22.4 for Python < 3.11, >= 1.23.2 for Python 3.11, and >= 1.26.0 for Python >= 3.12, none of which mandate numpy 2.0+. Matplotlib 3.10.7 requires NumPy >= 1.23. The existing constraint correctly allows numpy 1.x versions that satisfy both dependencies.

Likely an incorrect or invalid review comment.

security_scanning/examples/models/core/gemma/pyproject.toml (1)

10-12: This review comment is based on incorrect assumptions and mischaracterizes the dependency constraint.

The review references a non-existent "numpy 2.0.0" dependency in the library context; examining the actual pyproject.toml shows no such reference. More critically, the constraint numpy = "<2" is not overly broad—it is appropriately restrictive, correctly excluding NumPy 2.x which has known compatibility issues with Flax 0.8.0. NumPy 2.x removes/changes deprecated APIs (e.g. np.int/np.float) and compiled extensions built against NumPy 1.x must be rebuilt, and Flax 0.8.x predates broad NumPy 2.0 adoption, making the current constraint strategy sound.

Likely an incorrect or invalid review comment.

security_scanning/examples/models/contrib/internlm/pyproject.toml (1)

1-18: The "unknown-package" name is an intentional system-wide convention, not a placeholder.

The review comment assumes "unknown-package" is an error requiring correction. However, verification reveals this is a deliberate, consistent naming pattern applied across all 38+ pyproject.toml files in the repository—including both models/core/ and models/contrib/ directories (baichuan, bloom, chatglm variants, dbrx, deepseek_v1/v2, falcon, gptj, internlm, internlm2, llama, qwen, whisper, etc.). The presence of an auto-generated poetry.lock file confirms this is an intentional, maintained project structure, not a temporary state.

Renaming individual packages to model-specific identifiers (e.g., "internlm-examples") would violate this established template convention and should not be done.

Likely an incorrect or invalid review comment.

security_scanning/cpp/kernels/fmha_v2/pyproject.toml (1)

1-17: The review comment is incorrect; no issues require fixing.

The verification reveals the original concerns are unfounded:

1. "unknown-package" is standard: This naming pattern is used in 32+ other pyproject.toml files across the repo (e.g., security_scanning/examples/models/core/whisper/, security_scanning/examples/llm-eval/lm-eval-harness/, and many others). It is a systematic placeholder convention, not an anomaly.

2. poetry.lock file exists: The file security_scanning/cpp/kernels/fmha_v2/poetry.lock is present in the repository, contradicting the review note claiming lock files are missing from this PR.

3. Exact version pinning is not unique: Other pyproject.toml files in the repo also use exact pins (e.g., security_scanning/examples/lookahead/pyproject.toml pins datasets = "3.1.0"; triton_backend pins transformers = "4.56.0"). The exact pins in fmha_v2 are consistent with repo patterns.

4. Empty description is standard: Multiple packages in the repo have empty descriptions.

Likely an incorrect or invalid review comment.

security_scanning/examples/draft_target_model/pyproject.toml (2)

2-2: Better: meaningful package name.

This file uses "draft-target-model-examples" instead of "unknown-package", which is much clearer and aligns with the module directory. Other files in this PR should follow this pattern.

---

10-13: The original review comment is based on faulty assumptions and is incorrect.

The latest released version of rouge-score is 0.1.2 (released July 22, 2022), so the constraint rouge-score = "^0.1.2" is not pinning to an outdated version—it's pinning to the latest available. The caret operator allows compatible versions, but since no newer 0.x version exists, it effectively locks to the latest.

Additionally, pyproject.toml is a project manifest, not a lock file. poetry.lock serves as the lock file. Mixed versioning strategies in a manifest for an example/draft project are normal and acceptable practice.

The dependency versions shown are reasonable for this example project.

Likely an incorrect or invalid review comment.

security_scanning/examples/models/contrib/mmdit/pyproject.toml (1)

1-7: Package name "unknown-package" is consistent across all contrib modules, not unique to mmdit.

The verification shows that all 22 contrib modules (jais, opt, skywork, internlm, stdit, mmdit, smaug, gptj, hyperclovax, deepseek_v2, gptneox, grok, chatglm3-6b-32k, falcon, deepseek_v1, mpt, dbrx, chatglm2-6b, chatglm-6b, baichuan, bloom, etc.) use the identical generic package name. This appears to be an intentional or standard pattern across the contrib directory, not an anomaly specific to mmdit.

However, the referenced README.md on line 6 does not exist in the mmdit directory—only poetry.lock and pyproject.toml are present. This is a legitimate issue that should be addressed by either removing the reference or adding the missing file.

Likely an incorrect or invalid review comment.

security_scanning/examples/trtllm-eval/pyproject.toml (1)

1-15: Expand review scope: all three files have empty descriptions and version inconsistencies need clarification.

The claims in the review comment are accurate. All three pyproject.toml files have empty descriptions (not just trtllm-eval), and the lm-eval versions do differ across files (0.4.8, 0.4.7, and 0.4.5). Additionally, the second file (llm-eval-harness) has a generic package name "unknown-package" that should be corrected.

Without additional documentation in the PR, it cannot be determined whether these version differences are intentional. The developer should verify:

1. Whether the version differences are required by specific example dependencies or are an oversight
2. Add meaningful descriptions to all three packages
3. Correct the "unknown-package" name in the llm-eval-harness example

security_scanning/examples/auto_deploy/pyproject.toml (1)

1-16: The suggested diff to add a description contradicts the established codebase pattern.

All example projects in security_scanning/examples/ consistently use empty descriptions in their pyproject.toml files. Adding a description to only this file would create inconsistency rather than resolve it. While the observation about version differences across lm-eval (0.4.5 vs 0.4.7 vs 0.4.8) is accurate and worth clarifying, the suggested description fix should be ignored. If empty descriptions are problematic across the codebase, that requires a coordinated update across all examples, not a single-file change.

Likely an incorrect or invalid review comment.

security_scanning/examples/apps/pyproject.toml (1)

1-16: Fix openai version constraint only; remove description recommendation (follows codebase convention).

Analysis reveals that the description field should remain empty. The entire codebase (50+ pyproject.toml files) consistently uses description = "" as the standard pattern. Adding a description contradicts the established convention.

However, the openai version constraint issue is valid. The file uses >=1.57.2, which is inconsistent with other openai dependencies in the codebase that use the caret operator (e.g., security_scanning/pyproject.toml and security_scanning/examples/models/core/qwen/pyproject.toml both use ^2.6.1). Using ^1.57.2 would ensure compatibility within the <2.0.0 range while aligning with codebase conventions for dependency constraints.

Apply this diff instead:

 [tool.poetry.dependencies]
 python = ">=3.10,<3.13"
 colorama = "^0.4.6"
-openai = ">=1.57.2"
+openai = "^1.57.2"

Likely an incorrect or invalid review comment.

security_scanning/examples/models/contrib/opt/pyproject.toml (1)

8-12: Python constraint and dependencies look good.

The Python version constraint aligns with the project's minimum requirements, and the chosen dependencies (datasets, evaluate, rouge-score) are appropriate for model evaluation tasks.

security_scanning/pyproject.toml (3)

1-10: Verify PR intent: lock file vs. configuration file.

The PR title states "Check in most recent lock file from nightly pipeline," but the provided files are pyproject.toml configuration files, not poetry.lock lock files. Please clarify:

1. Are these hand-authored configuration files intended for the repository?
2. Should the actual poetry.lock file(s) also be included in this PR?
3. Are these files generated or manually maintained?

---

4-4: Comprehensive dependency management with intentional version pinning.

The dependency list is well-structured with a mix of hard-pinned versions (e.g., transformers = "4.56.0", torch = ">=2.8.0a0,<=2.8.0") and loose constraints. This suggests deliberate version management strategy. The Python constraint >=3.10,<3.13 aligns with the project's minimum requirements.

Consider populating the empty description field for better project documentation:

-description = ""
+description = "TensorRT-LLM: Efficient LLM Inference Engine"

Also applies to: 9-74

---

66-66: Git-based dependency pinned to specific commit.

The etcd3 dependency uses a pinned git commit hash, which is appropriate for external dependencies without stable releases. This ensures reproducibility.

[yuanjingx87]

/bot run

[tensorrt-cicd]

PR_Github #22805 [ run ] triggered by Bot. Commit: 4ffd8f1

[tensorrt-cicd]

PR_Github #22805 [ run ] completed with state SUCCESS. Commit: 4ffd8f1
/LLM/main/L0_MergeRequest_PR pipeline #17200 completed with status: 'FAILURE'

[chzblych]

/bot run

[tensorrt-cicd]

PR_Github #22891 [ run ] triggered by Bot. Commit: 4ffd8f1

[tensorrt-cicd]

PR_Github #22891 [ run ] completed with state FAILURE. Commit: 4ffd8f1
/LLM/main/L0_MergeRequest_PR pipeline #17263 completed with status: 'FAILURE'

[yuanjingx87]

/bot skip --comment "the ci can be triggered, so it is good to go"

[tensorrt-cicd]

PR_Github #22922 [ skip ] triggered by Bot. Commit: 4ffd8f1

[tensorrt-cicd]

PR_Github #22922 [ skip ] completed with state SUCCESS. Commit: 4ffd8f1
Skipping testing for commit 4ffd8f1