Skip to content

Conversation

@cheshirekow
Copy link
Collaborator

@cheshirekow cheshirekow commented Nov 21, 2025

Description

This change adds two tests to help ensure that thirdparty C++ code is integrated according to the process descripted in
3rdparty/cpp-thirdparty.md. The desired process requires folks to use FetchContent_Declare in 3rdparty/CMakeLists.txt. The two tests added here search the following deviations of the desired process:

  1. uses of FetchContent_Declare or ExternalProject_Add outside of 3rdparty/CMakeLists.txt
  2. new git-submodules added to the repo

Both scripts have the ability to allow-list exemptions if there are any cases in the future where a deviation is warranted. The scripts live in 3rdparty/* where CODEOWNERS ensures that process reviewers will be required on any new exemptions added to the allowlists.

Summary by CodeRabbit

  • Tests
    • Added comprehensive validation suite for third-party dependency management
    • Includes automated checks for CMake configuration patterns and git submodule organization
    • Ensures adherence to project dependency policies

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

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

  • Update tava architecture diagram if there is a significant design change in PR.

  • 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.

@cheshirekow cheshirekow requested a review from a team as a code owner November 21, 2025 17:59
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Nov 21, 2025

📝 Walkthrough

Walkthrough

Two new test modules are introduced to enforce third-party dependency management policies: one scans CMake files for unauthorized third-party integrations outside the designated 3rdparty directory, and another validates git submodule declarations. Both tests are integrated into the repository's test suite.

Changes

Cohort / File(s) Summary
Third-party Policy Enforcement Tests
3rdparty/test_cmake_third_party.py, 3rdparty/test_git_modules.py
Added two new test modules enforcing third-party dependency management. The CMake test scans for FetchContent_Declare and ExternalProject_Add directives outside 3rdparty/; the Git submodules test validates .gitmodules entries against an allowlist and enforces 3rdparty/ path prefix. Both include CLI entry points and pytest test cases.
Test Suite Integration
tests/integration/test_lists/test-db/l0_a10.yml
Added entries for the two new third-party policy tests to the PyTorch test group list.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

  • Filter and ignore logic in test_cmake_third_party.py: Verify the DirectoryFilter and FileFilter implementations correctly exclude intended paths and select relevant CMake files
  • Violation detection patterns: Ensure FetchContent_Declare and ExternalProject_Add pattern matching is robust and captures intended violations
  • Config parsing in test_git_modules.py: Review configparser usage and path validation logic for correctness
  • Error handling and exit codes: Confirm both scripts properly aggregate violations, report to stderr, and return correct exit statuses
  • Test integration: Validate the test list entries are properly formatted and discoverable by the test harness

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 46.15% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and specifically describes the main change: adding tests to verify the thirdparty C++ integration process.
Description check ✅ Passed The description explains the purpose, the two test types, and how exemptions are managed through allowlists in CODEOWNERS, though Test Coverage section is empty.
✨ 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

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

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Nitpick comments (5)
3rdparty/test_git_modules.py (2)

1-5: Align documentation paths and fix minor typos

There are a few small consistency/clarity issues worth fixing:

  • The process doc is referred to as both cpp/3rdparty/cpp-thirdparty.md and 3rdparty/cpp-thirdparty.md. Please pick the canonical path (per the PR description it sounds like 3rdparty/cpp-thirdparty.md) and use it consistently in:
    • The module docstring (lines 1‑5).
    • The ALLOWLIST comment (lines 16‑20).
    • The logger error message (lines 69‑73, which currently mentions cpp/3rdparty/...).
  • Typo at line 17: sobmodulessubmodules.
  • Slight grammar improvement in the docstring would make it read better, e.g. “This script audits the .gitmodules file…” instead of “audit”.

These are all non‑functional but will reduce confusion for future contributors.

Also applies to: 16-20, 69-74


90-100: Use the actual module docstring in argparse.ArgumentParser

In main(), the parser is constructed with description="__doc__", which sets the description to the literal string "__doc__" instead of the module’s docstring. If you intended to reuse the top‑level docstring, this should be:

-def main():
-    parser = argparse.ArgumentParser(description="__doc__")
+def main():
+    parser = argparse.ArgumentParser(description=__doc__)

Same pattern also appears in 3rdparty/test_cmake_third_party.py, so it’s worth updating both for consistency.

3rdparty/test_cmake_third_party.py (3)

1-5: Make process doc references consistent

The module docstring points to 3rdparty/README.md, while the error log message points to 3rdparty/cpp-thirdparty.md. Since this script is specifically about third‑party C++ integration, consider standardizing on the single, canonical doc (likely 3rdparty/cpp-thirdparty.md, as mentioned in the PR description and the git‑modules test).

A small tweak like:

-This script searches for cmake function invocations that might indicate
-the addition of new third-party dependencies outside of the intended
-process (3rdparty/README.md).
+This script searches for CMake function invocations that might indicate
+the addition of new third-party dependencies outside of the intended
+process (see 3rdparty/cpp-thirdparty.md).

would make the link between the policy and this enforcement script clearer.

Also applies to: 130-135


89-107: Consider ignoring commented lines to reduce false positives

yield_potential_thirdparty flags any line containing FetchContent_Declare or ExternalProject_Add, regardless of whether it’s active code or a comment. That means just documenting the function names in comments will show up as violations.

If you want to avoid this kind of false positive while keeping the logic simple, you could skip lines that are clearly commented out:

-    with fullpath.open("r", encoding="utf-8") as infile:
-        for lineno, line in enumerate(infile):
+    with fullpath.open("r", encoding="utf-8") as infile:
+        for lineno, line in enumerate(infile):
             lineno += 1  # Make line numbers 1-based
-
-            if "FetchContent_Declare" in line:
+            stripped = line.lstrip()
+            if stripped.startswith("#"):
+                continue
+
+            if "FetchContent_Declare" in stripped:
@@
-            if "ExternalProject_Add" in line:
+            if "ExternalProject_Add" in stripped:

Not mandatory, but it may make the check friendlier in practice by only flagging actual build logic.


149-159: Reuse the module docstring in the CLI description (same as git‑modules test)

As in test_git_modules.py, main() here uses description="__doc__", which sets the parser description to the literal string instead of the module’s docstring.

Recommend changing to:

-def main():
-    parser = argparse.ArgumentParser(description="__doc__")
+def main():
+    parser = argparse.ArgumentParser(description=__doc__)

This keeps the CLI help text in sync with the module documentation and aligns both scripts.

📜 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 9b2abb8 and 76193b4.

📒 Files selected for processing (3)
  • 3rdparty/test_cmake_third_party.py (1 hunks)
  • 3rdparty/test_git_modules.py (1 hunks)
  • tests/integration/test_lists/test-db/l0_a10.yml (1 hunks)
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2025-09-09T09:40:45.658Z
Learnt from: fredricz-20070104
Repo: NVIDIA/TensorRT-LLM PR: 7645
File: tests/integration/test_lists/qa/llm_function_core.txt:648-648
Timestamp: 2025-09-09T09:40:45.658Z
Learning: In TensorRT-LLM test lists, it's common and intentional for the same test to appear in multiple test list files when they serve different purposes (e.g., llm_function_core.txt for comprehensive core functionality testing and llm_function_core_sanity.txt for quick sanity checks). This duplication allows tests to be run in different testing contexts.

Applied to files:

  • tests/integration/test_lists/test-db/l0_a10.yml
📚 Learning: 2025-09-17T02:48:52.732Z
Learnt from: tongyuantongyu
Repo: NVIDIA/TensorRT-LLM PR: 7781
File: tests/integration/test_lists/waives.txt:313-313
Timestamp: 2025-09-17T02:48:52.732Z
Learning: In TensorRT-LLM, `tests/integration/test_lists/waives.txt` is specifically for waiving/skipping tests, while other test list files like those in `test-db/` and `qa/` directories are for different test execution contexts (pre-merge, post-merge, QA tests). The same test appearing in both waives.txt and execution list files is intentional - the test is part of test suites but will be skipped due to the waiver.

Applied to files:

  • tests/integration/test_lists/test-db/l0_a10.yml
📚 Learning: 2025-08-06T13:58:07.506Z
Learnt from: galagam
Repo: NVIDIA/TensorRT-LLM PR: 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:

  • tests/integration/test_lists/test-db/l0_a10.yml
🧬 Code graph analysis (2)
3rdparty/test_git_modules.py (1)
3rdparty/test_cmake_third_party.py (1)
  • main (149-159)
3rdparty/test_cmake_third_party.py (1)
3rdparty/test_git_modules.py (1)
  • main (90-100)
🪛 Ruff (0.14.5)
3rdparty/test_git_modules.py

31-31: Avoid specifying long messages outside the exception class

(TRY003)


35-35: Avoid specifying long messages outside the exception class

(TRY003)

⏰ 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 (3)
tests/integration/test_lists/test-db/l0_a10.yml (1)

79-81: Third‑party policy checks correctly integrated into l0_a10 pre‑merge list

The new CPU‑only third‑party policy tests are wired into the existing PyTorch pre‑merge job cleanly, with clear commenting and consistent formatting. No issues from the test‑list perspective.

3rdparty/test_git_modules.py (1)

79-87: Pytest entrypoint for .gitmodules check looks solid

The pytest wrapper cleanly resolves the repo root via Path(__file__).parents[1] / ".gitmodules" and asserts on the checker’s return code. This aligns well with how check_modules_file is designed and should integrate smoothly into the test suite.

3rdparty/test_cmake_third_party.py (1)

139-147: Pytest wrapper for CMake third‑party violations looks good

The TestThirdPartyInCmake wrapper mirrors the git‑modules test pattern: it anchors on the repo root via Path(__file__).parents[1], calls check_sources, and asserts a zero exit code. This is a clean integration point for the policy check into the test suite.

@cheshirekow cheshirekow force-pushed the test-prevent-thirdparty-process branch from 76193b4 to 4f07f75 Compare November 24, 2025 18:09
This change adds two tests to help ensure that thirdparty C++ code is
integrated according to the process descripted in
3rdparty/cpp-thirdparty.md. The desired process requires folks to use
FetchContent_Declare in 3rdparty/CMakeLists.txt. The two tests added
here search the following deviations of the desired process:

1. uses of FetchContent_Declare or ExternalProject_Add outside of
   3rdparty/CMakeLists.txt
2. new git-submodules added to the repo

Both scripts have the ability to allow-list exemptions if there are any
cases in the future where a deviation is warranted. The scripts live in
3rdparty/* where CODEOWNERS ensures that process reviewers will be
required on any new exemptions added to the allowlists.

Signed-off-by: Josh Bialkowski <[email protected]>
@cheshirekow cheshirekow force-pushed the test-prevent-thirdparty-process branch from 4f07f75 to b9d7489 Compare November 24, 2025 18:10
@cheshirekow
Copy link
Collaborator Author

/bot run

@tensorrt-cicd
Copy link
Collaborator

PR_Github #25598 [ run ] triggered by Bot. Commit: b9d7489

@tensorrt-cicd
Copy link
Collaborator

PR_Github #25598 [ run ] completed with state FAILURE. Commit: b9d7489
/LLM/main/L0_MergeRequest_PR pipeline #19392 completed with status: 'FAILURE'

- unittest/llmapi/apps/test_tool_parsers.py
- unittest/llmapi/apps/test_harmony_channel_validation.py
# third-party policy checks CPU-only
- 3rdparty/test_cmake_third_party.py
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will the tests run properly in the pipeline? I think all our test defs are under root_dir/tests/.

The pipeline failed at the test list validation stage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants