feat(cli): load plugin configs from plugin.toml#93
Conversation
… CLI Signed-off-by: GSD Agent <bbednarski@nvidia.com>
Signed-off-by: GSD Agent <bbednarski@nvidia.com>
github-actions
Bot
added
size:L
bbednarski9
added
Feature
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughAdds process-level plugin configuration to the CLI gateway: CLI/env input, discovery/precedence for plugin.toml and config.toml, parsing and conflict validation, server startup activation/teardown, tests, and documentation. ChangesPlugin Configuration Lifecycle for NeMo Flow Gateway
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
bbednarski9
added
size:M
bbednarski9
changed the title
github-actions
Bot
added
size:L
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@crates/cli/src/config.rs`:
- Around line 699-705: The plugin_config_paths function currently returns an
empty vec when explicit.as_ref().parent() is None, silently skipping discovery;
change the logic in plugin_config_paths so that when an explicit PathBuf has no
parent you default to the current directory (e.g., use "." or Path::new(".") as
the parent) and return a Vec with that parent joined to "plugin.toml" (i.e.,
always produce at least one path like "./plugin.toml" for the explicit case),
ensuring plugin.toml is checked for both ordinary and parent-less explicit
paths.
In `@crates/cli/src/server.rs`:
- Around line 68-84: The serve error currently takes precedence and the error
from plugin_activation.clear() is dropped; update the shutdown cleanup logic
around serve_result and clear_result (references: PluginActivation::clear,
serve_result, clear_result) to detect when both return Err and log or report the
clear error (e.g., with tracing::error! or eprintln!) alongside returning the
serve error; implement this by awaiting/collecting both results, returning the
serve_result error if present but emitting the clear_result error when it exists
so the clear failure is not silently lost.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 38007999-c71c-4cfe-a4e1-d46f967c30d3
📒 Files selected for processing (5)
crates/cli/src/config.rscrates/cli/src/server.rscrates/cli/tests/coverage/config_tests.rscrates/cli/tests/coverage/server_tests.rsdocs/export-observability-data/observability-plugin.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (26)
**/*.{md,rst,html,txt}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-brand-terminology.md)
**/*.{md,rst,html,txt}: Always spellNVIDIAin all caps. Do not useNvidia,nvidia,nVidia,nVIDIA, orNV.
Usean NVIDIAbefore a noun because the name starts with an 'en' sound.
Do not add a registered trademark symbol afterNVIDIAwhen referring to the company.
Use trademark symbols with product names only when the document type or legal guidance requires them.
Verify official capitalization, spacing, and hyphenation for product names.
Precede NVIDIA product names withNVIDIAon first mention when it is natural and accurate.
Do not rewrite product names for grammar or title-case rules.
Preserve third-party product names according to the owner's spelling.
Include the company name and full model qualifier on first use when it helps identify the model.
Preserve the official capitalization and punctuation of model names.
Use shorter family names only after the full name is established.
Spell out a term on first use and put the acronym in parentheses unless the acronym is widely understood by the intended audience.
Use the acronym on later mentions after it has been defined.
For long documents, reintroduce the full term if readers might lose context.
Form plurals of acronyms withs, not an apostrophe, such asGPUs.
In headings, common acronyms can remain abbreviated. Spell out the term in the first or second sentence of the body.
Common terms such asCPU,GPU,PC,API, andUIusually do not need to be spelled out for developer audiences.
Files:
docs/export-observability-data/observability-plugin.md
**/*.{md,rst,html}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-brand-terminology.md)
Link the first mention of a product name when the destination helps the reader.
Files:
docs/export-observability-data/observability-plugin.md
**/*.{md,rst,txt}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
**/*.{md,rst,txt}: SpellNVIDIAin all caps. Do not useNvidia,nvidia, orNV.
Format commands, code elements, expressions, package names, file names, and paths as inline code.
Use descriptive link text. Avoid raw URLs and weak anchors such as 'here' or 'read more.'
Use title case consistently for technical documentation headings.
Introduce code blocks, lists, tables, and images with complete sentences.
Write procedures as imperative steps. Keep steps parallel and split long procedures into smaller tasks.
Prefer active voice, present tense, short sentences, contractions, and plain English.
Usecanfor possibility and reservemayfor permission.
Useafterfor temporal relationships instead ofonce.
Preferrefer tooverseewhen the wording points readers to another resource.
Avoid culture-specific idioms, unnecessary Latinisms, jokes, and marketing exaggeration in technical documentation.
Spell out months in body text, avoid ordinal dates, and use clear time zones.
Spell out whole numbers from zero through nine unless they are technical values, parameters, versions, or UI values.
Use numerals for 10 or greater and include commas in thousands.
Do not add trademark symbols to learning-oriented documentation unless the source, platform, or legal guidance explicitly requires them.
Do not add trademark symbols to NeMo Flow learning documentation by default.
Do not rewrite API names, package names, command flags, or code literals for style reasons.
Files:
docs/export-observability-data/observability-plugin.md
**/*.{md,markdown,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-technical-docs.md)
**/*.{md,markdown,rst}: Use title case consistently in technical documentation headings
Avoid quotation marks, ampersands, and exclamation marks in headings
Keep product, event, research, and whitepaper names in their official title case
Use title case for table headers
Do not force social-media sentence case into technical docs
Use monospace formatting for code elements, commands, parameters, package names, and expressions
Use monospace formatting for directories, file names, and paths
Use angle brackets inside monospace for variables inside paths, such as/home/<username>/.login
Use quotation marks for error messages and strings in documentation
Use bold formatting for UI buttons, menus, fields, and labels in documentation
Use angle brackets between UI labels for menu paths, such as File > Save As
Use italics for new terms on first use in documentation
Use italics for publication titles in documentation
Use plain text formatting for keyboard shortcuts in documentation
Prefer[NVIDIA/NeMo](link)format for GitHub repository references over generic phrases like 'the GitHub repo'
Introduce every code block with a complete sentence
Do not make a code block complete the grammar of the previous sentence
Do not continue a sentence after a code block
Use syntax highlighting when the format supports it for code blocks
Avoid the word 'snippet' unless the surrounding docs already use it as a term of art
Keep inline method, function, and class references consistent with nearby docs, omitting empty parentheses for prose readability when no call is shown
Use descriptive anchor text that matches the destination title when possible for links
Avoid raw URLs in running text in documentation
Avoid generic link anchors such as 'here,' 'this page,' and 'read more' in documentation
Include the acronym in link text if a linked term includes an acronym
Do not link long sentences or multiple sentences in documentation
Avoid links that pull readers away from a procedure unles...
Files:
docs/export-observability-data/observability-plugin.md
**/*.{html,md}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Include SPDX license headers in HTML and Markdown files using HTML comment syntax
Files:
docs/export-observability-data/observability-plugin.md
docs/**/*.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Run
./scripts/build-docs.shfor documentation site changes
docs/**/*.md: Relevant getting-started or reference docs must be updated when examples change
Release-policy docs must point to GitHub Releases as the only release-history source of truth
docs/**/*.md: Use title case for headings in technical documentation
Introduce code blocks, tables, and lists with complete lead-in sentences in documentation
Files:
docs/export-observability-data/observability-plugin.md
**/*.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Run Markdown link checking via
lycheeforREADME.md,CONTRIBUTING.md, anddocs/through pre-commit hooks
Files:
docs/export-observability-data/observability-plugin.md
**/*.{md,markdown,py,sh,bash,js,ts,java,cpp,go,rust}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep package names, repo references, and build commands current in documentation
Files:
docs/export-observability-data/observability-plugin.md
{RELEASING.md,CHANGELOG.md,docs/**/*.md}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep release-process and release-notes guidance in repo-maintainer docs such as RELEASING.md, not as user-facing docs pages or CHANGELOG.md
Files:
docs/export-observability-data/observability-plugin.md
**/*.{md,markdown,py,sh,bash}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep stable user-facing wrappers at scripts/ root in docs and examples; only point at namespaced helper paths when documenting internal maintenance work
Files:
docs/export-observability-data/observability-plugin.md
**/*.{md,markdown,py,sh,bash,js,ts,example}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Example commands must match current package names and paths
Files:
docs/export-observability-data/observability-plugin.md
{scripts/*.sh,docs/**/*.md}
📄 CodeRabbit inference engine (.agents/skills/contribute-integration/SKILL.md)
Use root
./scripts/*.shcommands in docs and contributor guidance as documented, with implementations underscripts/third-party/
Files:
docs/export-observability-data/observability-plugin.md
{docs/**,examples/**,crates/adaptive/**,python/nemo_flow/**,go/nemo_flow/**,**/{example,component}.{ts,tsx,js,rs,py,go}}
📄 CodeRabbit inference engine (.agents/skills/maintain-optimizer/SKILL.md)
Any new adaptive component kind must have documentation, examples, and binding coverage across all supported languages
Files:
docs/export-observability-data/observability-plugin.md
{README*,CHANGELOG*,docs/**/*.{md,rst,txt},examples/**/*,*.md}
📄 CodeRabbit inference engine (.agents/skills/rename-surfaces/SKILL.md)
Update documentation, examples, and getting-started guides with new package/module/crate names after rename operations
Files:
docs/export-observability-data/observability-plugin.md
**/*.{md,txt,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
**/*.{md,txt,rst}: Ensure commands, package names, file paths, and APIs in documentation are correct and not stale; flag incorrect or outdated information as blocking issues
Ensure examples and procedures in documentation will execute successfully with current APIs and commands
Use consistent user-facing terminology throughout documentation that matches current repo terminology
Capitalize NVIDIA correctly in all documentation and public-facing text
Format code, commands, paths, and filenames as inline code (monospace) in documentation
Use descriptive anchor text for links instead of bare URLs or weak labels like 'here' in documentation
Prefer active voice, present tense, short sentences, and plain English in documentation
Structure documentation procedures as imperative steps that are easy to scan and not too long for a single sequence
Prefer 'after' instead of 'once' for temporal references in documentation
Use 'can' instead of 'may' when describing possibility (rather than permission) in documentation
Avoid ambiguous numeric dates and ordinal dates in documentation body text
Files:
docs/export-observability-data/observability-plugin.md
{README.md,docs/**/*.md,examples/**/*.{js,ts,py,go,rs}}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Keep documentation and examples synchronized with current install, import, and build commands
Files:
docs/export-observability-data/observability-plugin.md
**/*.{py,js,ts,tsx,go,rs,md}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
Format changed files with the language-native formatter before the final lint/test pass
Files:
docs/export-observability-data/observability-plugin.mdcrates/cli/src/server.rscrates/cli/tests/coverage/config_tests.rscrates/cli/tests/coverage/server_tests.rscrates/cli/src/config.rs
{README.md,CONTRIBUTING.md,docs/**/*.md}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
For docs-only changes, run targeted checks only if commands, package names, or examples changed. Use
just docsfor docs-site builds andjust docs-linkcheckwhen links changed
Files:
docs/export-observability-data/observability-plugin.md
{docs/**,README.md,CONTRIBUTING.md,RELEASING.md,SECURITY.md}
⚙️ CodeRabbit configuration file
{docs/**,README.md,CONTRIBUTING.md,RELEASING.md,SECURITY.md}: Review documentation for technical accuracy against the current API, command correctness, and consistency across language bindings.
Flag stale examples, missing SPDX headers where required, and instructions that no longer match CI or pre-commit behavior.
Files:
docs/export-observability-data/observability-plugin.md
**/*.rs
📄 CodeRabbit inference engine (.agents/skills/test-ffi-surface/SKILL.md)
**/*.rs: Runcargo fmt --allfor FFI work as it is Rust work
Runjust test-rustfor FFI validation
Runcargo clippy --workspace --all-targets -- -D warningsto enforce warnings-as-errors lintingWhen Rust files changed as part of Python work, run
cargo fmt --all,just test-rust, andcargo clippy --workspace --all-targets -- -D warnings
**/*.rs: Runcargo fmt --allfor Rust code formatting
Runcargo clippy --workspace --all-targets -- -D warningsto enforce Rust linting with no warnings
Runjust test-rustas the shared-runtime build/test wrapper for Rust changesUse Rust snake_case naming convention for Rust code
**/*.rs: Any Rust change must runjust test-rust
Any Rust change must runcargo fmt --all
Any Rust change must runcargo clippy --workspace --all-targets -- -D warnings
**/*.rs: Runcargo fmt --allfor Rust code formatting when Node changes touch Rust files
Runcargo clippy --workspace --all-targets -- -D warningsto enforce strict linting when Rust files changed as part of Node work
**/*.rs: Always runjust test-rustwhen any Rust code changes
Always runcargo fmt --allwhen any Rust code changes
Always runcargo clippy --workspace --all-targets -- -D warningswhen any Rust code changes
Files:
crates/cli/src/server.rscrates/cli/tests/coverage/config_tests.rscrates/cli/tests/coverage/server_tests.rscrates/cli/src/config.rs
**/*.{rs,go,js,ts,tsx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Include SPDX license headers in all Rust, Go, JavaScript, and TypeScript source files using C-style comment syntax
Files:
crates/cli/src/server.rscrates/cli/tests/coverage/config_tests.rscrates/cli/tests/coverage/server_tests.rscrates/cli/src/config.rs
**/*.{rs,py,go,js,ts,tsx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Use
SONAR_IGNORE_START/SONAR_IGNORE_ENDmarkers only for documented false positives that cannot be resolved in code; keep ignored blocks small, add explanatory comments, and require reviewer sign-off
Files:
crates/cli/src/server.rscrates/cli/tests/coverage/config_tests.rscrates/cli/tests/coverage/server_tests.rscrates/cli/src/config.rs
**/*.{js,ts,tsx,jsx,py,rs,go,java,c,cpp,h,cc,cxx,cs,rb,php,swift,kt}
📄 CodeRabbit inference engine (.agents/skills/prepare-pr/SKILL.md)
Changed files must be formatted with the language-native formatter
Files:
crates/cli/src/server.rscrates/cli/tests/coverage/config_tests.rscrates/cli/tests/coverage/server_tests.rscrates/cli/src/config.rs
**/*.{rs,py,js,ts,tsx,go}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
During iteration, prefer
uv run pre-commit run --files <changed files...>for targeted validation
Files:
crates/cli/src/server.rscrates/cli/tests/coverage/config_tests.rscrates/cli/tests/coverage/server_tests.rscrates/cli/src/config.rs
{crates/**/tests/**,python/tests/**,go/nemo_flow/**/*_test.go}
⚙️ CodeRabbit configuration file
{crates/**/tests/**,python/tests/**,go/nemo_flow/**/*_test.go}: Tests should cover the behavior promised by the changed API surface, including error paths and cross-request isolation where relevant.
Prefer assertions on lifecycle events, scope stacks, middleware ordering, and binding parity over shallow smoke tests.
Files:
crates/cli/tests/coverage/config_tests.rscrates/cli/tests/coverage/server_tests.rs
**/{config,schema,adaptive}.{yaml,yml,json,ts,tsx,py,go,rs}
📄 CodeRabbit inference engine (.agents/skills/maintain-optimizer/SKILL.md)
Ensure dynamic config shape matches the documented canonical model in docs/use-adaptive-optimization/configure.md
Files:
crates/cli/src/config.rs
🔇 Additional comments (17)
crates/cli/src/config.rs (5)
172-175: LGTM!The new
plugin_configCLI argument with environment variable fallback follows the established pattern for other server args.
183-192: LGTM!Including
plugin_configin daemon mode detection is consistent with the design that any explicit configuration flag signals intent to run the server.
632-655: LGTM!The conflict detection logic correctly tracks which
config.tomlfiles define[plugins].configand errors when multiple sources are found. The error message is actionable.
913-930: LGTM!The
apply_plugin_toml_configfunction correctly rejects configurations where bothconfig.toml's[plugins].configandplugin.tomlare present. The error message clearly identifies both conflicting sources.
932-940: LGTM!The CLI plugin config conflict check runs after file-based config is applied, so
config.plugin_config.is_some()correctly detects if either[plugins].configorplugin.tomlalready set the value.crates/cli/tests/coverage/config_tests.rs (5)
219-289: LGTM!Comprehensive test verifying
plugin.tomlis correctly parsed and mapped togateway.plugin_configas JSON. The TOML-to-JSON transformation is correctly tested with nested component config.
291-308: LGTM!Good coverage of plugin path resolution mechanics: verifies explicit config scopes plugin.toml to the same directory, and project-level discovery walks ancestors correctly.
310-333: LGTM!Tests the conflict error when both
plugin.tomland[plugins].configinconfig.tomlare present. Assertions verify the error message contains both source identifiers.
335-360: LGTM!Tests CLI
--plugin-configconflict with file-based plugin config. This validates theapply_cli_plugin_configguard works correctly.
535-546: LGTM!Extended malformed config test to cover invalid
plugin.tomlsyntax, verifying the error message includes "invalid plugin TOML".docs/export-observability-data/observability-plugin.md (1)
62-101: LGTM!Documentation accurately describes the plugin configuration sources, their discovery behavior, and the mutual exclusivity constraint. The example
plugin.tomlmatches the implementation and test fixtures.crates/cli/src/server.rs (1)
124-158: LGTM!The
PluginActivationlifecycle wrapper is well-designed:
activeflag prevents double-clearclear()consumes self and returns Result for explicit error handlingDropimpl ensures cleanup even on panic/early-return paths- JSON parsing error is mapped to
CliError::Configwith contextcrates/cli/tests/coverage/server_tests.rs (5)
29-63: LGTM!The test plugin implementation is minimal and correct:
- Uses atomics for thread-safe registration/deregistration counting
PLUGIN_TEST_LOCKensures test isolation for global plugin state- Plugin registration callback properly increments deregistration counter
140-220: LGTM!Comprehensive integration test covering the full plugin lifecycle:
- Activates plugin via
plugin_config- Verifies
active_plugin_report()is Some during server run- Submits hook requests to trigger observability events
- Verifies cleanup via
active_plugin_report()is None after shutdown- Validates ATOF/ATIF output artifacts
306-356: LGTM!Good test for plugin-kind agnosticism: registers a custom plugin, verifies it activates on server start and deregisters on shutdown. Cleanup of test plugin via
deregister_pluginin both setup and teardown prevents state leakage.
358-388: LGTM!Tests that invalid plugin config (invalid ATOF mode) is rejected before the server starts, and verifies no active plugin remains after the error.
698-709: LGTM!The
wait_for_gatewayhelper uses a reasonable polling strategy (50 attempts × 20ms = 1 second max) with clear panic message on timeout.
willkill07
changed the title
plugin.toml
There was a problem hiding this comment.
Hey, this is an awesome step in the right direction. I cooked with Codex with the checked out PR and noticed a few things. I think one feedback cycle can address these gaps. Great job overall!
The main things I think are worth tightening are the stacking semantics for discovered plugin.toml files, whether version = 1 is required or just recommended, and making the docs comprehensive enough that users can configure the full observability component shape from TOML.
Submitted by Codex
Signed-off-by: GSD Agent <bbednarski@nvidia.com>
Signed-off-by: GSD Agent <bbednarski@nvidia.com>
bbednarski9
force-pushed
the
bbednarski/validate-pr89-sidecar-plugin-bridge
branch
from
c3da386 to
abbfcae
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@crates/cli/src/config.rs`:
- Around line 547-550: The run-level --plugin-config is losing precedence
because inherited server overrides are applied before run overrides
(apply_server_overrides -> apply_cli_plugin_config) so a prior plugin_config
value blocks the run value; change the order or merge logic so run overrides
win: either call apply_run_overrides(&mut resolved.gateway, command) before
apply_server_overrides(&mut resolved.gateway, inherited) or update
apply_cli_plugin_config to accept a precedence flag so a later call can
overwrite existing plugin_config; update resolve_run_config accordingly and add
a regression test that constructs an inherited top-level plugin_config plus a
run-level plugin_config and asserts the resolved run config uses the run value.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: a13fcfcc-4f34-40a5-97cf-b55d9dae924b
📒 Files selected for processing (3)
crates/cli/src/config.rscrates/cli/tests/coverage/config_tests.rsdocs/export-observability-data/observability-plugin.md
📜 Review details
🧰 Additional context used
📓 Path-based instructions (26)
**/*.{md,rst,html,txt}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-brand-terminology.md)
**/*.{md,rst,html,txt}: Always spellNVIDIAin all caps. Do not useNvidia,nvidia,nVidia,nVIDIA, orNV.
Usean NVIDIAbefore a noun because the name starts with an 'en' sound.
Do not add a registered trademark symbol afterNVIDIAwhen referring to the company.
Use trademark symbols with product names only when the document type or legal guidance requires them.
Verify official capitalization, spacing, and hyphenation for product names.
Precede NVIDIA product names withNVIDIAon first mention when it is natural and accurate.
Do not rewrite product names for grammar or title-case rules.
Preserve third-party product names according to the owner's spelling.
Include the company name and full model qualifier on first use when it helps identify the model.
Preserve the official capitalization and punctuation of model names.
Use shorter family names only after the full name is established.
Spell out a term on first use and put the acronym in parentheses unless the acronym is widely understood by the intended audience.
Use the acronym on later mentions after it has been defined.
For long documents, reintroduce the full term if readers might lose context.
Form plurals of acronyms withs, not an apostrophe, such asGPUs.
In headings, common acronyms can remain abbreviated. Spell out the term in the first or second sentence of the body.
Common terms such asCPU,GPU,PC,API, andUIusually do not need to be spelled out for developer audiences.
Files:
docs/export-observability-data/observability-plugin.md
**/*.{md,rst,html}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-brand-terminology.md)
Link the first mention of a product name when the destination helps the reader.
Files:
docs/export-observability-data/observability-plugin.md
**/*.{md,rst,txt}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
**/*.{md,rst,txt}: SpellNVIDIAin all caps. Do not useNvidia,nvidia, orNV.
Format commands, code elements, expressions, package names, file names, and paths as inline code.
Use descriptive link text. Avoid raw URLs and weak anchors such as 'here' or 'read more.'
Use title case consistently for technical documentation headings.
Introduce code blocks, lists, tables, and images with complete sentences.
Write procedures as imperative steps. Keep steps parallel and split long procedures into smaller tasks.
Prefer active voice, present tense, short sentences, contractions, and plain English.
Usecanfor possibility and reservemayfor permission.
Useafterfor temporal relationships instead ofonce.
Preferrefer tooverseewhen the wording points readers to another resource.
Avoid culture-specific idioms, unnecessary Latinisms, jokes, and marketing exaggeration in technical documentation.
Spell out months in body text, avoid ordinal dates, and use clear time zones.
Spell out whole numbers from zero through nine unless they are technical values, parameters, versions, or UI values.
Use numerals for 10 or greater and include commas in thousands.
Do not add trademark symbols to learning-oriented documentation unless the source, platform, or legal guidance explicitly requires them.
Do not add trademark symbols to NeMo Flow learning documentation by default.
Do not rewrite API names, package names, command flags, or code literals for style reasons.
Files:
docs/export-observability-data/observability-plugin.md
**/*.{md,markdown,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-technical-docs.md)
**/*.{md,markdown,rst}: Use title case consistently in technical documentation headings
Avoid quotation marks, ampersands, and exclamation marks in headings
Keep product, event, research, and whitepaper names in their official title case
Use title case for table headers
Do not force social-media sentence case into technical docs
Use monospace formatting for code elements, commands, parameters, package names, and expressions
Use monospace formatting for directories, file names, and paths
Use angle brackets inside monospace for variables inside paths, such as/home/<username>/.login
Use quotation marks for error messages and strings in documentation
Use bold formatting for UI buttons, menus, fields, and labels in documentation
Use angle brackets between UI labels for menu paths, such as File > Save As
Use italics for new terms on first use in documentation
Use italics for publication titles in documentation
Use plain text formatting for keyboard shortcuts in documentation
Prefer[NVIDIA/NeMo](link)format for GitHub repository references over generic phrases like 'the GitHub repo'
Introduce every code block with a complete sentence
Do not make a code block complete the grammar of the previous sentence
Do not continue a sentence after a code block
Use syntax highlighting when the format supports it for code blocks
Avoid the word 'snippet' unless the surrounding docs already use it as a term of art
Keep inline method, function, and class references consistent with nearby docs, omitting empty parentheses for prose readability when no call is shown
Use descriptive anchor text that matches the destination title when possible for links
Avoid raw URLs in running text in documentation
Avoid generic link anchors such as 'here,' 'this page,' and 'read more' in documentation
Include the acronym in link text if a linked term includes an acronym
Do not link long sentences or multiple sentences in documentation
Avoid links that pull readers away from a procedure unles...
Files:
docs/export-observability-data/observability-plugin.md
**/*.{html,md}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Include SPDX license headers in HTML and Markdown files using HTML comment syntax
Files:
docs/export-observability-data/observability-plugin.md
docs/**/*.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Run
./scripts/build-docs.shfor documentation site changes
docs/**/*.md: Relevant getting-started or reference docs must be updated when examples change
Release-policy docs must point to GitHub Releases as the only release-history source of truth
docs/**/*.md: Use title case for headings in technical documentation
Introduce code blocks, tables, and lists with complete lead-in sentences in documentation
Files:
docs/export-observability-data/observability-plugin.md
**/*.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Run Markdown link checking via
lycheeforREADME.md,CONTRIBUTING.md, anddocs/through pre-commit hooks
Files:
docs/export-observability-data/observability-plugin.md
**/*.{md,markdown,py,sh,bash,js,ts,java,cpp,go,rust}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep package names, repo references, and build commands current in documentation
Files:
docs/export-observability-data/observability-plugin.md
{RELEASING.md,CHANGELOG.md,docs/**/*.md}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep release-process and release-notes guidance in repo-maintainer docs such as RELEASING.md, not as user-facing docs pages or CHANGELOG.md
Files:
docs/export-observability-data/observability-plugin.md
**/*.{md,markdown,py,sh,bash}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep stable user-facing wrappers at scripts/ root in docs and examples; only point at namespaced helper paths when documenting internal maintenance work
Files:
docs/export-observability-data/observability-plugin.md
**/*.{md,markdown,py,sh,bash,js,ts,example}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Example commands must match current package names and paths
Files:
docs/export-observability-data/observability-plugin.md
{scripts/*.sh,docs/**/*.md}
📄 CodeRabbit inference engine (.agents/skills/contribute-integration/SKILL.md)
Use root
./scripts/*.shcommands in docs and contributor guidance as documented, with implementations underscripts/third-party/
Files:
docs/export-observability-data/observability-plugin.md
{docs/**,examples/**,crates/adaptive/**,python/nemo_flow/**,go/nemo_flow/**,**/{example,component}.{ts,tsx,js,rs,py,go}}
📄 CodeRabbit inference engine (.agents/skills/maintain-optimizer/SKILL.md)
Any new adaptive component kind must have documentation, examples, and binding coverage across all supported languages
Files:
docs/export-observability-data/observability-plugin.md
{README*,CHANGELOG*,docs/**/*.{md,rst,txt},examples/**/*,*.md}
📄 CodeRabbit inference engine (.agents/skills/rename-surfaces/SKILL.md)
Update documentation, examples, and getting-started guides with new package/module/crate names after rename operations
Files:
docs/export-observability-data/observability-plugin.md
**/*.{md,txt,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
**/*.{md,txt,rst}: Ensure commands, package names, file paths, and APIs in documentation are correct and not stale; flag incorrect or outdated information as blocking issues
Ensure examples and procedures in documentation will execute successfully with current APIs and commands
Use consistent user-facing terminology throughout documentation that matches current repo terminology
Capitalize NVIDIA correctly in all documentation and public-facing text
Format code, commands, paths, and filenames as inline code (monospace) in documentation
Use descriptive anchor text for links instead of bare URLs or weak labels like 'here' in documentation
Prefer active voice, present tense, short sentences, and plain English in documentation
Structure documentation procedures as imperative steps that are easy to scan and not too long for a single sequence
Prefer 'after' instead of 'once' for temporal references in documentation
Use 'can' instead of 'may' when describing possibility (rather than permission) in documentation
Avoid ambiguous numeric dates and ordinal dates in documentation body text
Files:
docs/export-observability-data/observability-plugin.md
{README.md,docs/**/*.md,examples/**/*.{js,ts,py,go,rs}}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Keep documentation and examples synchronized with current install, import, and build commands
Files:
docs/export-observability-data/observability-plugin.md
**/*.{py,js,ts,tsx,go,rs,md}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
Format changed files with the language-native formatter before the final lint/test pass
Files:
docs/export-observability-data/observability-plugin.mdcrates/cli/tests/coverage/config_tests.rscrates/cli/src/config.rs
{README.md,CONTRIBUTING.md,docs/**/*.md}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
For docs-only changes, run targeted checks only if commands, package names, or examples changed. Use
just docsfor docs-site builds andjust docs-linkcheckwhen links changed
Files:
docs/export-observability-data/observability-plugin.md
{docs/**,README.md,CONTRIBUTING.md,RELEASING.md,SECURITY.md}
⚙️ CodeRabbit configuration file
{docs/**,README.md,CONTRIBUTING.md,RELEASING.md,SECURITY.md}: Review documentation for technical accuracy against the current API, command correctness, and consistency across language bindings.
Flag stale examples, missing SPDX headers where required, and instructions that no longer match CI or pre-commit behavior.
Files:
docs/export-observability-data/observability-plugin.md
**/*.rs
📄 CodeRabbit inference engine (.agents/skills/test-ffi-surface/SKILL.md)
**/*.rs: Runcargo fmt --allfor FFI work as it is Rust work
Runjust test-rustfor FFI validation
Runcargo clippy --workspace --all-targets -- -D warningsto enforce warnings-as-errors lintingWhen Rust files changed as part of Python work, run
cargo fmt --all,just test-rust, andcargo clippy --workspace --all-targets -- -D warnings
**/*.rs: Runcargo fmt --allfor Rust code formatting
Runcargo clippy --workspace --all-targets -- -D warningsto enforce Rust linting with no warnings
Runjust test-rustas the shared-runtime build/test wrapper for Rust changesUse Rust snake_case naming convention for Rust code
**/*.rs: Any Rust change must runjust test-rust
Any Rust change must runcargo fmt --all
Any Rust change must runcargo clippy --workspace --all-targets -- -D warnings
**/*.rs: Runcargo fmt --allfor Rust code formatting when Node changes touch Rust files
Runcargo clippy --workspace --all-targets -- -D warningsto enforce strict linting when Rust files changed as part of Node work
**/*.rs: Always runjust test-rustwhen any Rust code changes
Always runcargo fmt --allwhen any Rust code changes
Always runcargo clippy --workspace --all-targets -- -D warningswhen any Rust code changes
Files:
crates/cli/tests/coverage/config_tests.rscrates/cli/src/config.rs
**/*.{rs,go,js,ts,tsx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Include SPDX license headers in all Rust, Go, JavaScript, and TypeScript source files using C-style comment syntax
Files:
crates/cli/tests/coverage/config_tests.rscrates/cli/src/config.rs
**/*.{rs,py,go,js,ts,tsx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Use
SONAR_IGNORE_START/SONAR_IGNORE_ENDmarkers only for documented false positives that cannot be resolved in code; keep ignored blocks small, add explanatory comments, and require reviewer sign-off
Files:
crates/cli/tests/coverage/config_tests.rscrates/cli/src/config.rs
**/*.{js,ts,tsx,jsx,py,rs,go,java,c,cpp,h,cc,cxx,cs,rb,php,swift,kt}
📄 CodeRabbit inference engine (.agents/skills/prepare-pr/SKILL.md)
Changed files must be formatted with the language-native formatter
Files:
crates/cli/tests/coverage/config_tests.rscrates/cli/src/config.rs
**/*.{rs,py,js,ts,tsx,go}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
During iteration, prefer
uv run pre-commit run --files <changed files...>for targeted validation
Files:
crates/cli/tests/coverage/config_tests.rscrates/cli/src/config.rs
{crates/**/tests/**,python/tests/**,go/nemo_flow/**/*_test.go}
⚙️ CodeRabbit configuration file
{crates/**/tests/**,python/tests/**,go/nemo_flow/**/*_test.go}: Tests should cover the behavior promised by the changed API surface, including error paths and cross-request isolation where relevant.
Prefer assertions on lifecycle events, scope stacks, middleware ordering, and binding parity over shallow smoke tests.
Files:
crates/cli/tests/coverage/config_tests.rs
**/{config,schema,adaptive}.{yaml,yml,json,ts,tsx,py,go,rs}
📄 CodeRabbit inference engine (.agents/skills/maintain-optimizer/SKILL.md)
Ensure dynamic config shape matches the documented canonical model in docs/use-adaptive-optimization/configure.md
Files:
crates/cli/src/config.rs
🔇 Additional comments (2)
crates/cli/tests/coverage/config_tests.rs (1)
204-207: LGTM!Also applies to: 219-441, 533-553, 617-627
docs/export-observability-data/observability-plugin.md (1)
62-165: LGTM!
bbednarski9
force-pushed
the
bbednarski/validate-pr89-sidecar-plugin-bridge
branch
from
abbfcae to
24c1037
Compare
github-actions
Bot
added
size:XL
|
/ok to test f69c936 |
Signed-off-by: Bryan Bednarski <bbednarski@nvidia.com>
Signed-off-by: GSD Agent <bbednarski@nvidia.com>
Signed-off-by: GSD Agent <bbednarski@nvidia.com>
bbednarski9
force-pushed
the
bbednarski/validate-pr89-sidecar-plugin-bridge
branch
from
f69c936 to
831a856
Compare
|
/merge |
2 participants
Overview
Details
Summary
This PR wires the CLI gateway to the generic NeMo Flow plugin configuration path and adds a dedicated
plugin.tomlfile option for process-level plugin activation.The gateway now resolves a single
PluginConfigfrom supported configuration sources, activates it when the server starts, and clears it when the server shuts down. The implementation is generic over plugin kind; the tests exercise the observability plugin today while keeping the config path usable for future plugin kinds such as adaptive once those plugins are registered in the CLI process.Changes
--plugin-config/NEMO_FLOW_PLUGIN_CONFIGsupport.plugin.tomldiscovery and loading for root-level genericPluginConfigTOML.plugin.tomlalongside explicit--config path/to/config.toml.plugin.tomlfiles from system, nearest project, and user scopes.plugin.toml,[plugins].config, and--plugin-config.[plugins].configsupport inconfig.toml.plugin.tomlshape for observability plugin configuration.Validation
cargo fmt --check cargo test -p nemo-flow-cli cargo build -p nemo-flow-cliNotes
plugin.tomluses the generic plugin config shape at the file root:Where should the reviewer start?
Start with
crates/cli/src/config.rs. The key design decision is that the CLI still resolves exactly one genericPluginConfig, but that config may now come from--plugin-config,[plugins].config, orplugin.toml. The conflict checks in that file are the main behavior to review.Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Tests