feat: add verified CLI installers#354
Conversation
Signed-off-by: Bryan Bednarski <bbednarski@nvidia.com>
|
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 cross-platform installer scripts, installer-focused CI gating and tests, and updates release and user docs for the new installation flow. ChangesInstaller rollout and CI gating
Estimated code review effort: 4 (Complex) | ~60 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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 @.github/workflows/ci_check.yml:
- Around line 44-45: The Checkout step in the CI workflow is still using the
default actions/checkout behavior that persists git credentials, which is
unnecessary for this job. Update the checkout configuration in the workflow so
the Checkout step explicitly disables credential persistence by setting
persist-credentials to false on actions/checkout, keeping the rest of the
ci_check job unchanged.
In `@docs/getting-started/installation.mdx`:
- Around line 105-106: The rerun note in the installation guide hardcodes the
default binary path, which is inaccurate when a custom install directory is
chosen. Update the wording in the installation copy to refer to the binary in
the selected `--install-dir` destination, and make sure the sentence stays
consistent with the install flow described by the installer documentation.
In `@install.sh`:
- Around line 87-90: The installer’s curl-based network calls can hang
indefinitely because no timeout is set. Update the curl invocations used for the
latest release lookup, asset download, and checksum download in install.sh to
include both connection and overall timeout options, and make sure the existing
error handling still triggers through the release lookup and download helper
paths.
🪄 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: 9d038c9b-434c-41df-ac68-31ada5ac31bf
📒 Files selected for processing (9)
.github/workflows/ci_check.ymlREADME.mdRELEASING.mdcrates/cli/README.mddocs/getting-started/installation.mdxdocs/nemo-relay-cli/about.mdxinstall.shscripts/README.mdscripts/test-install.sh
📜 Review details
🧰 Additional context used
📓 Path-based instructions (29)
**/*.{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:
scripts/README.mdcrates/cli/README.mdREADME.mdRELEASING.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:
scripts/README.mdcrates/cli/README.mdREADME.mdRELEASING.md
**/*.md
📄 CodeRabbit inference engine (.agents/skills/contribute-integration/SKILL.md)
Documentation must be updated if activation or usage changed
**/*.md: 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
Format code elements, commands, parameters, package names, and expressions in monospace
Format directories, file names, and paths in monospace using backticks
Use angle brackets inside monospace for variables inside paths, such as/home/<username>/.login
Format error messages and strings in quotation marks, keeping literal code strings in code formatting when clearer
Format UI buttons, menus, fields, and labels in bold
Use angle brackets between UI labels for menu paths, such as File > Save As
Use italics for new terms on first use, sparingly and only when introducing the term
Use italics for publication titles
Format keyboard shortcuts in plain text, such as Press Ctrl+Alt+Delete
Use owner/repo link text for GitHub repositories, preferring[NVIDIA/NeMo](link)over prose references 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
Avoid generic anchor text such as 'here,' 'this page,' and 'read more'
Include acronyms in link text when a linked term includes an acronym
Do not link long sentences or multiple sentences
Avoid links ...
Files:
scripts/README.mdcrates/cli/README.mdREADME.mdRELEASING.md
**/{docs,examples,**/*.md,*.patch,*.diff,.github,*.sh,*.yaml,*.yml}
📄 CodeRabbit inference engine (.agents/skills/rename-surfaces/SKILL.md)
Update documentation, examples, CI configuration, and patch artifacts when performing rename operations
Files:
scripts/README.mdcrates/cli/README.mdREADME.mdRELEASING.mdinstall.shscripts/test-install.sh
**/*.{md,rst,txt}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
Spell
NVIDIAin all caps. Do not useNvidia,nvidia, orNV.
Files:
scripts/README.mdcrates/cli/README.mdREADME.mdRELEASING.md
**/*.{md,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
**/*.{md,rst}: 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 docs.
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 docs unless the source, platform, or legal guidance explicitly requires them.
Files:
scripts/README.mdcrates/cli/README.mdREADME.mdRELEASING.md
{scripts/**,third-party/**}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
{scripts/**,third-party/**}: For third-party integration or patch changes, run patch validation with./scripts/apply-patches.sh --checkand relevant integration tests. Keep root./scripts/*.shwrappers for third-party flows
Run third-party patch bootstrap with./scripts/bootstrap-third-party.sh
Run third-party patch validation with./scripts/apply-patches.sh --check
Files:
scripts/README.mdscripts/test-install.sh
{docs/**,README.md,CONTRIBUTING.md,**/*.md}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
Run docs link validation with
just docs-linkcheckwhen links change
Files:
scripts/README.mddocs/nemo-relay-cli/about.mdxcrates/cli/README.mdREADME.mdRELEASING.mddocs/getting-started/installation.mdx
{docs/**,README.md,**/Cargo.toml,**/package.json,**/*.md}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
Ensure renamed public surfaces are reflected consistently in manifests and docs for large or public-facing changes
Files:
scripts/README.mddocs/nemo-relay-cli/about.mdxcrates/cli/README.mdREADME.mdRELEASING.mddocs/getting-started/installation.mdx
**/*.{md,mdx,py,sh,yaml,yml,toml,json}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep package names, repo references, and build commands current
Files:
scripts/README.mddocs/nemo-relay-cli/about.mdxcrates/cli/README.mdREADME.mdRELEASING.mddocs/getting-started/installation.mdxinstall.shscripts/test-install.sh
**/*.{html,md,mdx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Include SPDX license header in HTML and Markdown files using HTML comment syntax
Files:
scripts/README.mddocs/nemo-relay-cli/about.mdxcrates/cli/README.mdREADME.mdRELEASING.mddocs/getting-started/installation.mdx
**/README.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Update relevant crate or package README when that surface changed
Files:
scripts/README.mdcrates/cli/README.mdREADME.md
**/*.{rs,py,js,ts,tsx,jsx,go,sh,toml,yaml,yml,md}
📄 CodeRabbit inference engine (AGENTS.md)
Keep SPDX headers on source, docs, scripts, and configuration files. The project is Apache-2.0.
Files:
scripts/README.mdcrates/cli/README.mdREADME.mdRELEASING.mdinstall.shscripts/test-install.sh
**
⚙️ CodeRabbit configuration file
**:AGENTS.md
This file provides guidance to agents, including Claude Code and OpenAI Codex, when working in this repository.
Project Overview
NeMo Relay is a multi-language agent runtime framework for execution scopes, lifecycle events, middleware, plugins, and observability around tool and LLM calls. The core runtime is Rust. Primary supported bindings are Rust, Python, and Node.js. Go and the raw C FFI are experimental and source-first.
The shared runtime model is:
- Scope stacks decide where work belongs and which scope-local behavior is visible.
- Middleware registries decide what guardrails and intercepts run around managed calls.
- Plugins install reusable runtime behavior from configuration.
- Events record runtime behavior in ATOF form.
- Subscribers and exporters consume events in-process or export them to ATIF, OpenTelemetry, OpenInference, or other backends.
Repository Structure
The repository layout separates the Rust runtime, language bindings,
documentation, integrations, and agent-facing skills.crates/ core/ # Rust core runtime crate, published as nemo-relay adaptive/ # Adaptive runtime primitives and plugin components python/ # PyO3 native extension for the Python package ffi/ # Raw C ABI layer used by downstream bindings such as Go node/ # NAPI Node.js binding and JavaScript/TypeScript entry points python/ nemo_relay/ # Python wrapper package: scopes, tools, LLM, middleware, typed helpers, plugins, adaptive helpers tests/ # Python tests go/ nemo_relay/ # Experimental Go CGo binding and tests fern/ # Fern documentation site scripts/ # Stable wrappers and helper scripts; build/test/docs entry points live in justfile skills/ # Published Codex/agent skills for NeMo Relay usage patternsPrerequisites
Insta...
Files:
scripts/README.mddocs/nemo-relay-cli/about.mdxcrates/cli/README.mdREADME.mdRELEASING.mddocs/getting-started/installation.mdxinstall.shscripts/test-install.sh
{.github/**,.gitlab-ci.yml,.pre-commit-config.yaml,justfile,scripts/**}
⚙️ CodeRabbit configuration file
{.github/**,.gitlab-ci.yml,.pre-commit-config.yaml,justfile,scripts/**}: Review automation changes for reproducibility, pinned versions where appropriate, secret handling, and consistency with the documented validation matrix.
Pay attention to commands that need generated native artifacts, FFI libraries, or platform-specific environment variables.
Files:
scripts/README.md.github/workflows/ci_check.ymlscripts/test-install.sh
.github/workflows/*.{yml,yaml}
📄 CodeRabbit inference engine (.agents/skills/maintain-ci/SKILL.md)
.github/workflows/*.{yml,yaml}: Putpermissions:on each job that needs token access in GitHub Actions workflows
Avoid workflow-level permissions unless the repository intentionally centralizes them and the inheritance tradeoff is documented
Keep third-party actions pinned to full commit SHAs and preserve the readable version comment after the SHA
Prefer action-native or ecosystem-native caching over genericactions/cache
Use lockfiles or dependency manifests to drive cache invalidation in GitHub Actions workflows
Keep deploy and publish permissions isolated to the jobs that need them in GitHub Actions
Read both caller and callee when a workflow usesworkflow_callin GitHub Actions
Put release-tag validation in the earliest practical caller job when the pipeline has tag-based publish behavior
Keep release-tag policy aligned withRELEASING.md: raw SemVer tags only, no leadingv
contents: readis the default minimum permission for checkout-based build, test, docs, and packaging jobs
pull-requests: readis required for PR metadata lookup jobs in GitHub Actions workflows
pages: writeandid-token: writeshould be limited to Pages deployment jobs and callers that invoke them through reusable workflows
For reusable workflows, the caller must grant every permission the called jobs require; the callee cannot elevate beyond what the caller provides
Preferastral-sh/setup-uvcache support withcache-dependency-globanchored touv.lock
PreferSwatinem/rust-cachewith explicitshared-keyandworkspacesinstead of ad hoc target-directory caching
Avoid caching generated outputs that can hide stale behavior unless the repo already relies on them deliberately
Files:
.github/workflows/ci_check.yml
.{github/workflows/*.{yml,yaml},gitlab-ci.yml}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Ensure CI workflows reference the same package names, install commands, and build commands as local development workflows
Files:
.github/workflows/ci_check.yml
{docs/**,README.md,CONTRIBUTING.md}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
{docs/**,README.md,CONTRIBUTING.md}: For docs-only changes, run targeted checks only if commands, package names, or examples changed. Usejust docsfor docs-site builds andjust docs-linkcheckwhen links changed
Run docs site build withjust docs
Files:
docs/nemo-relay-cli/about.mdxREADME.mddocs/getting-started/installation.mdx
{docs/**,README.md}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
Verify README and docs entry points still match current package names and paths for large or public-facing changes
Files:
docs/nemo-relay-cli/about.mdxREADME.mddocs/getting-started/installation.mdx
{docs/**,examples/**,README.md}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
Verify examples still run with documented commands for large or public-facing changes
Files:
docs/nemo-relay-cli/about.mdxREADME.mddocs/getting-started/installation.mdx
**/*.mdx
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
In MDX files, top-of-file comments must use JSX comment delimiters: {/* to open and */} to close. Do not use HTML comments for MDX SPDX headers.
MDX top-of-file SPDX comments must use {/* ... */} delimiters instead of HTML comment delimiters (Must-Fix)
Files:
docs/nemo-relay-cli/about.mdxdocs/getting-started/installation.mdx
docs/**/*.{md,mdx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Update embedded documentation snippets, patch docs, and binding-support notes if examples or supported bindings changed
Files:
docs/nemo-relay-cli/about.mdxdocs/getting-started/installation.mdx
docs/**
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Run
just docsor./scripts/build-docs.sh htmlto regenerate ignored Fern API reference pages before validation for documentation site changes
Files:
docs/nemo-relay-cli/about.mdxdocs/getting-started/installation.mdx
{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/nemo-relay-cli/about.mdxREADME.mdRELEASING.mddocs/getting-started/installation.mdx
{README.md,docs/getting-started/**/*.md}
📄 CodeRabbit inference engine (.agents/skills/add-binding-feature/SKILL.md)
Update
README.md,docs/getting-started/, or binding-level READMEs if behavior differs by language or usage changed
Files:
README.md
README.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Update
README.mdto reflect current workspace members and top-level documentation when workspace structure changes
Files:
README.md
{README.md,docs/**/*.{md,rst,txt},fern/**/*}
📄 CodeRabbit inference engine (.agents/skills/prepare-code-freeze/SKILL.md)
Search and update documentation source for references to the old version in
README.md,docs, andferndirectories, updating current-version install commands, package examples, and configuration examples to<next-version>
Files:
README.md
RELEASING.md
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Ensure public packaging changes are reflected in release-facing documentation and RELEASING.md
Files:
RELEASING.md
{CHANGELOG.md,RELEASING.md,docs/**/*.md}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Release history and release notes must reference GitHub Releases, not CHANGELOG.md or docs pages
Files:
RELEASING.md
🧠 Learnings (1)
📚 Learning: 2026-05-03T04:23:07.497Z
Learnt from: willkill07
Repo: NVIDIA/NeMo-Flow PR: 46
File: .github/workflows/ci_rust.yml:31-64
Timestamp: 2026-05-03T04:23:07.497Z
Learning: In GitHub Actions workflow YAML, it’s valid to conditionally disable a service container by setting the service container’s `image` to an empty string (`''`) via a matrix variable (e.g., `redis_service_image: ''`). This intentionally makes the runner skip service initialization for that matrix entry rather than failing the job. When reviewing workflows, don’t flag this as an error if the workflow uses an empty `image` to disable the service on specific matrix entries (e.g., OS-specific setups); verify the `image` is sourced from the matrix variable and that the service is only expected to be available when a non-empty image is provided.
Applied to files:
.github/workflows/ci_check.yml
🪛 Shellcheck (0.11.0)
scripts/test-install.sh
[warning] 7-7: Remove space after = if trying to assign a value (for empty string, use var='' ... ).
(SC1007)
🪛 zizmor (1.26.1)
.github/workflows/ci_check.yml
[warning] 44-45: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
🔇 Additional comments (11)
README.md (1)
54-67: LGTM!RELEASING.md (1)
323-326: LGTM!crates/cli/README.md (1)
54-97: LGTM!docs/getting-started/installation.mdx (2)
33-43: LGTM!
57-104: LGTM!Also applies to: 107-124
docs/nemo-relay-cli/about.mdx (1)
14-21: LGTM!scripts/test-install.sh (2)
39-42: 🎯 Functional CorrectnessConfirm
assert_no_temporary_filesbehavior — non-obvious but correct.
set -- "$1"/.nemo-relay.*reassigns positional parameters via glob expansion, then reuses$1. Traced through: with no matches the pattern remains literal (fails-e), and with any match(es)$1becomes an existing leftover file (glob results are typically sorted, so this catches leftovers regardless of which temp file remains). This works, but the reuse of$1afterset --is easy to misread on a future edit.
136-260: LGTM! Good coverage of version precedence, platform mapping, checksum failure paths, replacement safety, and cleanup.install.sh (1)
1-169: LGTM! Argument parsing, platform detection, checksum verification, and atomic install-via-mktemp+mvare all sound, and the version regex prevents any injection risk from user-suppliedVERSION..github/workflows/ci_check.yml (1)
36-52: LGTM! Job is scoped to minimumcontents: readpermission with a pinned checkout action, and runs the syntax check plus test harness as intended.scripts/README.md (1)
8-25: LGTM! Documentation accurately reflects the newtest-install.shscript and directory layout, and follows monospace formatting conventions for filenames.
mnajafian-nv
left a comment
mnajafian-nv
left a comment
There was a problem hiding this comment.
LGTM overall. Thanks for driving the installer path forward. Conditional approval pending review of the inline suggestions.
willkill07
left a comment
willkill07
left a comment
There was a problem hiding this comment.
- environment-variable only configuration
- support all platforms (example)
- documentation:
- clearly separate when to use install.sh vs cargo install vs cargo binstall
- testing:
- mock -> real testing
- easier than you think
- run command -> dump to text file
- analyze file
- should be done on all platforms
- should only be done if
install.shchanges
- mock -> real testing
Signed-off-by: Bryan Bednarski <bbednarski@nvidia.com>
Signed-off-by: Bryan Bednarski <bbednarski@nvidia.com>
Signed-off-by: Bryan Bednarski <bbednarski@nvidia.com>
Signed-off-by: Bryan Bednarski <bbednarski@nvidia.com>
Signed-off-by: Bryan Bednarski <bbednarski@nvidia.com>
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/getting-started/installation.mdx (1)
83-87: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winCall out the PATH requirement after
--install-dir.The custom-directory example installs
nemo-relayoutside the default location, but the guide does not tell readers to add that directory toPATHbefore running the command. That makes the example easy to copy into a setup that still cannot findnemo-relay.♻️ Proposed fix
Install into another directory: ```bash curl -fsSL https://raw.githubusercontent.com/NVIDIA/NeMo-Relay/main/install.sh | sh -s -- --install-dir "$HOME/bin"
+If that directory is not on
PATH, add it before runningnemo-relay.</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@docs/getting-started/installation.mdxaround lines 83 - 87, The custom
install example in the installation guide omits the PATH requirement, so readers
may installnemo-relayinto a non-default directory and still be unable to run
it. Update theInstall into another directorysection to explicitly note that
after using--install-dir(for example withnemo-relayin the install
command), the target directory such as$HOME/binmust be added toPATH
before invoking the CLI.</details> <!-- cr-comment:v1:a126c4e616be4c8723cdbd62 --> _Source: Path instructions_ </blockquote></details> </blockquote></details>🤖 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. Outside diff comments: In `@docs/getting-started/installation.mdx`: - Around line 83-87: The custom install example in the installation guide omits the PATH requirement, so readers may install `nemo-relay` into a non-default directory and still be unable to run it. Update the `Install into another directory` section to explicitly note that after using `--install-dir` (for example with `nemo-relay` in the install command), the target directory such as `$HOME/bin` must be added to `PATH` before invoking the CLI.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID:
e9d677dc-48ac-4b53-98ee-64143e3b6c82📒 Files selected for processing (4)
crates/cli/README.mddocs/getting-started/installation.mdxinstall.shscripts/test-install.sh📜 Review details
⏰ Context from checks skipped due to timeout. (21)
- GitHub Check: Rust / Test (linux-amd64)
- GitHub Check: Rust / Test (linux-arm64)
- GitHub Check: Go / Test (windows-arm64)
- GitHub Check: Rust / Test (macos-arm64)
- GitHub Check: Node.js / Test (macos-arm64)
- GitHub Check: Go / Test (linux-arm64)
- GitHub Check: Rust / Test (windows-arm64)
- GitHub Check: Rust / Test (windows-amd64)
- GitHub Check: Go / Test (macos-arm64)
- GitHub Check: Go / Test (windows-amd64)
- GitHub Check: Python / Test (macos-arm64)
- GitHub Check: Node.js / Test (linux-arm64)
- GitHub Check: Python / Test (windows-arm64)
- GitHub Check: Python / Test (linux-amd64)
- GitHub Check: Go / Test (linux-amd64)
- GitHub Check: Python / Test (linux-arm64)
- GitHub Check: Node.js / Test (linux-amd64)
- GitHub Check: Python / Test (windows-amd64)
- GitHub Check: Node.js / Test (windows-arm64)
- GitHub Check: Node.js / Test (windows-amd64)
- GitHub Check: Preview docs
🧰 Additional context used
📓 Path-based instructions (15)
**/*.{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:
crates/cli/README.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:
crates/cli/README.md**/*.{md,rst,txt}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
Spell
NVIDIAin all caps. Do not useNvidia,nvidia, orNV.Files:
crates/cli/README.md**/*.{md,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
**/*.{md,rst}: 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 docs.
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 docs unless the source, platform, or legal guidance explicitly requires them.Files:
crates/cli/README.md**/*.md
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-technical-docs.md)
**/*.md: 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
Format code elements, commands, parameters, package names, and expressions in monospace
Format directories, file names, and paths in monospace using backticks
Use angle brackets inside monospace for variables inside paths, such as/home/<username>/.login
Format error messages and strings in quotation marks, keeping literal code strings in code formatting when clearer
Format UI buttons, menus, fields, and labels in bold
Use angle brackets between UI labels for menu paths, such as File > Save As
Use italics for new terms on first use, sparingly and only when introducing the term
Use italics for publication titles
Format keyboard shortcuts in plain text, such as Press Ctrl+Alt+Delete
Use owner/repo link text for GitHub repositories, preferring[NVIDIA/NeMo](link)over prose references 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
Avoid generic anchor text such as 'here,' 'this page,' and 'read more'
Include acronyms in link text when a linked term includes an acronym
Do not link long sentences or multiple sentences
Avoid links that pull readers away from a procedure unless the link is a p...Files:
crates/cli/README.md**/*
📄 CodeRabbit inference engine (AGENTS.md)
Keep SPDX headers on source, docs, scripts, and configuration files.
Files:
crates/cli/README.mddocs/getting-started/installation.mdxinstall.shscripts/test-install.sh**/*.{rs,go,js,ts,py,html,md,mdx,toml,yml,yaml,c,h}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Include SPDX license headers in all source files using the correct comment syntax for the file type.
Files:
crates/cli/README.mddocs/getting-started/installation.mdx**/*.{md,mdx}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
**/*.{md,mdx}: Prefer the documented public API rather than internal shortcuts.
Keep package names, repository references, and build commands current.
Update entry-point docs when examples or reading paths change.
Keep release-process and release-notes guidance in repository-maintainer docs such asRELEASING.md, not in user-facing docs pages orCHANGELOG.md.
Keep stable user-facing wrappers at thescripts/root in docs and examples; only point at namespaced helper paths when documenting internal maintenance work.
When detailed dynamic plugin guides exist, keep Rust native plugin examples, Python worker plugin examples, andgrpc-v1protocol details on separate pages.
Dynamic plugin manifests in docs and examples should usecompat.relay = ">=0.5,<1.0"unless deliberately narrower.
Update relevant getting-started or reference docs when the associated behavior or examples change.
Ensure example commands still match current package names and paths.
Dynamic plugin entry pages should link to native, worker, Rust example, Python example, and protocol pages when those pages exist.
When the docs site changes, runjust docs;./scripts/build-docs.sh htmlremains the compatibility wrapper.
**/*.{md,mdx}: Document native and worker plugins as trusted extensions: native plugins are in-process and unsandboxed, while worker plugins provide process isolation but not a security sandbox.
When detailed dynamic plugin guides exist, keep Rust native, Python worker, andgrpc-v1protocol details on separate pages.Files:
crates/cli/README.mddocs/getting-started/installation.mdx**/README.md
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
**/README.md: UpdateREADME.mdwhen entry points change.
Update relevant package or crateREADME.mdfiles when examples or binding guidance changes.Files:
crates/cli/README.md**
⚙️ CodeRabbit configuration file
**:AGENTS.md
This file provides guidance to agents, including Claude Code and OpenAI Codex, when working in this repository.
Project Overview
NeMo Relay is a multi-language agent runtime framework for execution scopes, lifecycle events, middleware, plugins, and observability around tool and LLM calls. The core runtime is Rust. Primary supported bindings are Rust, Python, and Node.js. Go and the raw C FFI are experimental and source-first.
The shared runtime model is:
- Scope stacks decide where work belongs and which scope-local behavior is visible.
- Middleware registries decide what guardrails and intercepts run around managed calls.
- Plugins install reusable runtime behavior from configuration.
- Events record runtime behavior in ATOF form.
- Subscribers and exporters consume events in-process or export them to ATIF, OpenTelemetry, OpenInference, or other backends.
Repository Structure
The repository layout separates the Rust runtime, language bindings,
documentation, integrations, and agent-facing skills.crates/ core/ # Rust core runtime crate, published as nemo-relay adaptive/ # Adaptive runtime primitives and plugin components python/ # PyO3 native extension for the Python package ffi/ # Raw C ABI layer used by downstream bindings such as Go node/ # NAPI Node.js binding and JavaScript/TypeScript entry points python/ nemo_relay/ # Python wrapper package: scopes, tools, LLM, middleware, typed helpers, plugins, adaptive helpers tests/ # Python tests go/ nemo_relay/ # Experimental Go CGo binding and tests fern/ # Fern documentation site scripts/ # Stable wrappers and helper scripts; build/test/docs entry points live in justfile skills/ # Published Codex/agent skills for NeMo Relay usage patternsPrerequisites
Insta...
Files:
crates/cli/README.mddocs/getting-started/installation.mdxinstall.shscripts/test-install.sh**/*.mdx
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
MDX top-of-file SPDX comments must use {/* ... */} delimiters instead of HTML comment delimiters (Must-Fix)
**/*.mdx: In MDX files, top-of-file comments must use JSX comment delimiters:{/*to open and*/}to close; do not use HTML comments for MDX SPDX headers.
New or regenerated MDX files must use{/* ... */}for top-of-file SPDX comments.Files:
docs/getting-started/installation.mdxdocs/**/*.{md,mdx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
docs/**/*.{md,mdx}: Keep documentation underdocs/valid for Fern tooling and external links, including Markdown/MDX link checks where applicable.
Update relevant reference docs and embedded examples when public behavior, bindings, examples, or workspace structure change.Files:
docs/getting-started/installation.mdxdocs/**/*.mdx
📄 CodeRabbit inference engine (.agents/skills/contribute-integration/SKILL.md)
Update documentation if activation or usage changes
Files:
docs/getting-started/installation.mdx{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/getting-started/installation.mdx{.github/**,.gitlab-ci.yml,.pre-commit-config.yaml,justfile,scripts/**}
⚙️ CodeRabbit configuration file
{.github/**,.gitlab-ci.yml,.pre-commit-config.yaml,justfile,scripts/**}: Review automation changes for reproducibility, pinned versions where appropriate, secret handling, and consistency with the documented validation matrix.
Pay attention to commands that need generated native artifacts, FFI libraries, or platform-specific environment variables.Files:
scripts/test-install.sh🔇 Additional comments (5)
install.sh (1)
16-29: LGTM!Also applies to: 72-72
scripts/test-install.sh (2)
156-159: LGTM!Also applies to: 188-189, 213-214, 225-226, 246-247, 261-262, 274-275
301-306: 🎯 Functional CorrectnessNo change needed for the empty-
HOMEcase.install_diris derived with${HOME:+${HOME}/.local/bin}, soHOME=""leaves it empty and theinstall directory must not be emptyguard is the right failure path.crates/cli/README.md (1)
54-95: LGTM!docs/getting-started/installation.mdx (1)
30-82: LGTM!Also applies to: 89-114
Signed-off-by: Bryan Bednarski <bbednarski@nvidia.com>
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 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 @.github/workflows/ci_check.yml:
- Around line 74-75: The live installer test step is making unauthenticated
GitHub release/asset requests on every matrix runner, which can hit rate limits.
Update the installer test flow invoked by script/test-install.sh to pass an
authenticated GITHUB_TOKEN into the download logic so its curl calls use the
higher authenticated quota. If the shell script already supports headers or
env-based auth, wire that through in the CI workflow job and the installer
download path rather than leaving the Run live installer tests step
unauthenticated.
In `@install.ps1`:
- Around line 107-115: The Add-InstallDirectoryToPath function is reading and
rewriting the user PATH through Environment variables, which can flatten
expandable %VAR% segments; update this flow to preserve the original registry
value kind instead of round-tripping through
[Environment]::GetEnvironmentVariable and [Environment]::SetEnvironmentVariable.
Use the registry APIs directly for the user PATH entry in
Add-InstallDirectoryToPath, and keep the Add-ToPath logic for merging the
install directory while maintaining any existing REG_EXPAND_SZ segments.
In `@scripts/test-install.ps1`:
- Around line 70-88: The captured installer output is being wrapped by
Out-String at the default host width, which breaks long download-failure
assertions in CI. Update the two capture paths in test-install.ps1 that build
$script:RunOutput so the PowerShell output is collected with an explicit large
width, keeping long URLs and error text on one line. Use the existing
$PowerShell invocation and the shared $script:RunOutput capture logic to make
the Scenario 5 download assertion deterministic.
In `@scripts/test-install.sh`:
- Around line 72-98: `test_live_asset_404_preserves_existing_binary` should also
verify cleanup after the failed download path, since this is where
`download_file` and `checksum_file` are created before the 404 occurs; add the
same `assert_no_temporary_files` check used in
`test_live_latest_and_pinned_replacement` to confirm the trap removes temp
files. Also document that this test depends on
`test_live_latest_and_pinned_replacement` having already installed `nemo-relay
0.3.0` into `live_install_dir`, so its `preserved_version` assertion is not
relied on in isolation and future reordering/parallelization does not break it.
🪄 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: 739b8181-1b99-43fe-a1e7-69e44c645d33
📒 Files selected for processing (14)
.github/ci-path-filters.yml.github/workflows/ci.yaml.github/workflows/ci_changes.yml.github/workflows/ci_check.ymlREADME.mdRELEASING.mdcrates/cli/README.mddocs/getting-started/installation.mdxinstall.ps1install.shscripts/README.mdscripts/test-install-mocks.shscripts/test-install.ps1scripts/test-install.sh
📜 Review details
⏰ Context from checks skipped due to timeout. (1)
- GitHub Check: Preview docs
⚠️ CI failures not shown inline (5)
GitHub Actions: Build pull request / Check _ Run: fix: complete installer validation
Conclusion: failure
##[group]Run bail() {
�[36;1mbail() {�[0m
�[36;1m printf '::error::install-action: %s\n' "$*"�[0m
GitHub Actions: Build pull request / CI Pipeline: fix: complete installer validation
Conclusion: failure
##[group]Run set -euo pipefail
�[36;1mset -euo pipefail�[0m
�[36;1mfailed=false�[0m
�[36;1m�[0m
�[36;1mrequire_success() {�[0m
�[36;1m local name="$1"�[0m
�[36;1m local result="$2"�[0m
�[36;1m if [[ "$result" != "success" ]]; then�[0m
�[36;1m echo "Error: ${name} finished with result '${result}', expected success" >&2�[0m
�[36;1m failed=true�[0m
�[36;1m fi�[0m
�[36;1m}�[0m
�[36;1m�[0m
�[36;1mallow_success_or_skipped() {�[0m
�[36;1m local name="$1"�[0m
�[36;1m local result="$2"�[0m
�[36;1m if [[ "$result" != "success" && "$result" != "skipped" ]]; then�[0m
�[36;1m echo "Error: ${name} finished with result '${result}', expected success or skipped" >&2�[0m
�[36;1m failed=true�[0m
�[36;1m fi�[0m
�[36;1m}�[0m
�[36;1m�[0m
�[36;1mrequire_success "Changes" "$CHANGES_RESULT"�[0m
�[36;1mrequire_success "Check" "$CHECK_RESULT"�[0m
�[36;1m�[0m
�[36;1mif [[ "$publish_packages" == "true" ]]; then�[0m
�[36;1m require_success "Rust" "$RUST_RESULT"�[0m
�[36;1m require_success "Node.js" "$NODE_RESULT"�[0m
�[36;1m require_success "Python" "$PYTHON_RESULT"�[0m
�[36;1melse�[0m
�[36;1m allow_success_or_skipped "Rust" "$RUST_RESULT"�[0m
�[36;1m allow_success_or_skipped "Node.js" "$NODE_RESULT"�[0m
�[36;1m allow_success_or_skipped "Python" "$PYTHON_RESULT"�[0m
�[36;1mfi�[0m
�[36;1m�[0m
�[36;1mallow_success_or_skipped "Go" "$GO_RESULT"�[0m
�[36;1m�[0m
�[36;1mif [[ "$failed" == "true" ]]; then�[0m
�[36;1m exit 1�[0m
�[36;1mfi�[0m
shell: /usr/bin/bash -e {0}
env:
CHANGES_RESULT: success
CHECK_RESULT: failure
RUST_RESULT: skipped
GO_RESULT: skipped
NODE_RESULT: skipped
PYTHON_RESULT: skipped
publish_packages: false
##[endgroup]
Error: Check finished with result 'failure', expected success
##[error]Process completed with exit code 1.
GitHub Actions: Build pull request / 5_CI Pipeline.txt: fix: complete installer validation
Conclusion: failure
##[group]Run set -euo pipefail
�[36;1mset -euo pipefail�[0m
�[36;1mfailed=false�[0m
�[36;1m�[0m
�[36;1mrequire_success() {�[0m
�[36;1m local name="$1"�[0m
�[36;1m local result="$2"�[0m
�[36;1m if [[ "$result" != "success" ]]; then�[0m
�[36;1m echo "Error: ${name} finished with result '${result}', expected success" >&2�[0m
�[36;1m failed=true�[0m
�[36;1m fi�[0m
�[36;1m}�[0m
�[36;1m�[0m
�[36;1mallow_success_or_skipped() {�[0m
�[36;1m local name="$1"�[0m
�[36;1m local result="$2"�[0m
�[36;1m if [[ "$result" != "success" && "$result" != "skipped" ]]; then�[0m
�[36;1m echo "Error: ${name} finished with result '${result}', expected success or skipped" >&2�[0m
�[36;1m failed=true�[0m
�[36;1m fi�[0m
�[36;1m}�[0m
�[36;1m�[0m
�[36;1mrequire_success "Changes" "$CHANGES_RESULT"�[0m
�[36;1mrequire_success "Check" "$CHECK_RESULT"�[0m
�[36;1m�[0m
�[36;1mif [[ "$publish_packages" == "true" ]]; then�[0m
�[36;1m require_success "Rust" "$RUST_RESULT"�[0m
�[36;1m require_success "Node.js" "$NODE_RESULT"�[0m
�[36;1m require_success "Python" "$PYTHON_RESULT"�[0m
�[36;1melse�[0m
�[36;1m allow_success_or_skipped "Rust" "$RUST_RESULT"�[0m
�[36;1m allow_success_or_skipped "Node.js" "$NODE_RESULT"�[0m
�[36;1m allow_success_or_skipped "Python" "$PYTHON_RESULT"�[0m
�[36;1mfi�[0m
�[36;1m�[0m
�[36;1mallow_success_or_skipped "Go" "$GO_RESULT"�[0m
�[36;1m�[0m
�[36;1mif [[ "$failed" == "true" ]]; then�[0m
�[36;1m exit 1�[0m
�[36;1mfi�[0m
shell: /usr/bin/bash -e {0}
env:
CHANGES_RESULT: success
CHECK_RESULT: failure
RUST_RESULT: skipped
GO_RESULT: skipped
NODE_RESULT: skipped
PYTHON_RESULT: skipped
publish_packages: false
##[endgroup]
Error: Check finished with result 'failure', expected success
##[error]Process completed with exit code 1.
GitHub Actions: Build pull request / Check _ Run: fix: complete installer validation
Conclusion: failure
##[group]Run bail() {
�[36;1mbail() {�[0m
�[36;1m printf '::error::install-action: %s\n' "$*"�[0m
GitHub Actions: Build pull request / 11_Check _ Run.txt: fix: complete installer validation
Conclusion: failure
##[group]Run bail() {
�[36;1mbail() {�[0m
�[36;1m printf '::error::install-action: %s\n' "$*"�[0m
🧰 Additional context used
📓 Path-based instructions (21)
.github/workflows/*.{yml,yaml}
📄 CodeRabbit inference engine (.agents/skills/maintain-ci/SKILL.md)
.github/workflows/*.{yml,yaml}: In GitHub Actions workflow files, put apermissions:block on each job that needs token access.
In GitHub Actions workflow files, avoid workflow-levelpermissions:unless the repository intentionally centralizes them and the inheritance tradeoff is documented.
In GitHub Actions workflow files, pin third-party actions to full commit SHAs and keep the readable version comment after the SHA.
In GitHub Actions workflow files, prefer action-native or ecosystem-native caching over genericactions/cache.
In GitHub Actions workflow files, drive cache invalidation from lockfiles or dependency manifests.
In GitHub Actions workflow files, keep deploy and publish permissions isolated to the jobs that need them.
When a workflow usesworkflow_call, read both the caller and callee workflow files before changing or reviewing it.
When a pipeline has tag-based publish behavior, put release-tag validation in the earliest practical caller job.
In release-tag workflows, enforce repo policy that tags are raw SemVer only and do not start withv.
Keep Codecov component paths aligned with new crates, packages, and generated outputs; place dynamic plugin SDK/protocol paths in the plugin component.
For pure-Python plugin SDK packaging, produce a single wheel artifact instead of duplicating it across every platform matrix entry.
Usecontents: readas the default minimum permission for checkout-based build, test, docs, and packaging jobs.
Usepull-requests: readfor jobs that look up PR metadata.
Limitpages: writeandid-token: writeto Pages deployment jobs and any caller that invokes them through a reusable workflow.
For reusable workflows, the caller must grant every permission the called jobs require, because the callee cannot elevate beyond what the caller provides.
Preferastral-sh/setup-uvcache support withcache-dependency-globanchored touv.lock.
PreferSwatinem/rust-cachewith explicitshared-keyandworkspacesinstead...
Files:
.github/workflows/ci_changes.yml.github/workflows/ci.yaml.github/workflows/ci_check.yml
.github/**/*.{yml,yaml}
📄 CodeRabbit inference engine (.agents/skills/maintain-dynamic-plugins/SKILL.md)
justfile, Codecov, and CI package/test workflows must include new plugin crates and packages.
Files:
.github/workflows/ci_changes.yml.github/workflows/ci.yaml.github/ci-path-filters.yml.github/workflows/ci_check.yml
.github/workflows/*.yml
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Ensure CI workflows use the same package names, install commands, and example commands as local workflows and documented usage.
Files:
.github/workflows/ci_changes.yml.github/workflows/ci_check.yml
{.github/**,.gitlab-ci.yml,.pre-commit-config.yaml,justfile,scripts/**}
⚙️ CodeRabbit configuration file
{.github/**,.gitlab-ci.yml,.pre-commit-config.yaml,justfile,scripts/**}: Review automation changes for reproducibility, pinned versions where appropriate, secret handling, and consistency with the documented validation matrix.
Pay attention to commands that need generated native artifacts, FFI libraries, or platform-specific environment variables.
Files:
.github/workflows/ci_changes.yml.github/workflows/ci.yamlscripts/test-install-mocks.sh.github/ci-path-filters.yml.github/workflows/ci_check.ymlscripts/test-install.ps1scripts/test-install.shscripts/README.md
**/*.{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:
crates/cli/README.mdRELEASING.mdscripts/README.mdREADME.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:
crates/cli/README.mdRELEASING.mdscripts/README.mdREADME.md
**/*.{md,rst,txt}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
Spell
NVIDIAin all caps. Do not useNvidia,nvidia, orNV.
Files:
crates/cli/README.mdRELEASING.mdscripts/README.mdREADME.md
**/*.{md,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
**/*.{md,rst}: 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 docs.
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 docs unless the source, platform, or legal guidance explicitly requires them.
Files:
crates/cli/README.mdRELEASING.mdscripts/README.mdREADME.md
**/*.md
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-technical-docs.md)
**/*.md: 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
Format code elements, commands, parameters, package names, and expressions in monospace
Format directories, file names, and paths in monospace using backticks
Use angle brackets inside monospace for variables inside paths, such as/home/<username>/.login
Format error messages and strings in quotation marks, keeping literal code strings in code formatting when clearer
Format UI buttons, menus, fields, and labels in bold
Use angle brackets between UI labels for menu paths, such as File > Save As
Use italics for new terms on first use, sparingly and only when introducing the term
Use italics for publication titles
Format keyboard shortcuts in plain text, such as Press Ctrl+Alt+Delete
Use owner/repo link text for GitHub repositories, preferring[NVIDIA/NeMo](link)over prose references 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
Avoid generic anchor text such as 'here,' 'this page,' and 'read more'
Include acronyms in link text when a linked term includes an acronym
Do not link long sentences or multiple sentences
Avoid links that pull readers away from a procedure unless the link is a p...
Files:
crates/cli/README.mdRELEASING.mdscripts/README.mdREADME.md
**/*
📄 CodeRabbit inference engine (AGENTS.md)
Keep SPDX headers on source, docs, scripts, and configuration files.
Files:
crates/cli/README.mdscripts/test-install-mocks.shRELEASING.mddocs/getting-started/installation.mdxinstall.ps1scripts/test-install.ps1scripts/test-install.shscripts/README.mdREADME.mdinstall.sh
**/*.{rs,go,js,ts,py,html,md,mdx,toml,yml,yaml,c,h}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Include SPDX license headers in all source files using the correct comment syntax for the file type.
Files:
crates/cli/README.mdRELEASING.mddocs/getting-started/installation.mdxscripts/README.mdREADME.md
**/*.{md,mdx}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
**/*.{md,mdx}: Prefer the documented public API rather than internal shortcuts.
Keep package names, repository references, and build commands current.
Update entry-point docs when examples or reading paths change.
Keep release-process and release-notes guidance in repository-maintainer docs such asRELEASING.md, not in user-facing docs pages orCHANGELOG.md.
Keep stable user-facing wrappers at thescripts/root in docs and examples; only point at namespaced helper paths when documenting internal maintenance work.
When detailed dynamic plugin guides exist, keep Rust native plugin examples, Python worker plugin examples, andgrpc-v1protocol details on separate pages.
Dynamic plugin manifests in docs and examples should usecompat.relay = ">=0.5,<1.0"unless deliberately narrower.
Update relevant getting-started or reference docs when the associated behavior or examples change.
Ensure example commands still match current package names and paths.
Dynamic plugin entry pages should link to native, worker, Rust example, Python example, and protocol pages when those pages exist.
When the docs site changes, runjust docs;./scripts/build-docs.sh htmlremains the compatibility wrapper.
**/*.{md,mdx}: Document native and worker plugins as trusted extensions: native plugins are in-process and unsandboxed, while worker plugins provide process isolation but not a security sandbox.
When detailed dynamic plugin guides exist, keep Rust native, Python worker, andgrpc-v1protocol details on separate pages.
Files:
crates/cli/README.mdRELEASING.mddocs/getting-started/installation.mdxscripts/README.mdREADME.md
**/README.md
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
**/README.md: UpdateREADME.mdwhen entry points change.
Update relevant package or crateREADME.mdfiles when examples or binding guidance changes.
Files:
crates/cli/README.mdscripts/README.mdREADME.md
**
⚙️ CodeRabbit configuration file
**:AGENTS.md
This file provides guidance to agents, including Claude Code and OpenAI Codex, when working in this repository.
Project Overview
NeMo Relay is a multi-language agent runtime framework for execution scopes, lifecycle events, middleware, plugins, and observability around tool and LLM calls. The core runtime is Rust. Primary supported bindings are Rust, Python, and Node.js. Go and the raw C FFI are experimental and source-first.
The shared runtime model is:
- Scope stacks decide where work belongs and which scope-local behavior is visible.
- Middleware registries decide what guardrails and intercepts run around managed calls.
- Plugins install reusable runtime behavior from configuration.
- Events record runtime behavior in ATOF form.
- Subscribers and exporters consume events in-process or export them to ATIF, OpenTelemetry, OpenInference, or other backends.
Repository Structure
The repository layout separates the Rust runtime, language bindings,
documentation, integrations, and agent-facing skills.crates/ core/ # Rust core runtime crate, published as nemo-relay adaptive/ # Adaptive runtime primitives and plugin components python/ # PyO3 native extension for the Python package ffi/ # Raw C ABI layer used by downstream bindings such as Go node/ # NAPI Node.js binding and JavaScript/TypeScript entry points python/ nemo_relay/ # Python wrapper package: scopes, tools, LLM, middleware, typed helpers, plugins, adaptive helpers tests/ # Python tests go/ nemo_relay/ # Experimental Go CGo binding and tests fern/ # Fern documentation site scripts/ # Stable wrappers and helper scripts; build/test/docs entry points live in justfile skills/ # Published Codex/agent skills for NeMo Relay usage patternsPrerequisites
Insta...
Files:
crates/cli/README.mdscripts/test-install-mocks.shRELEASING.mddocs/getting-started/installation.mdxinstall.ps1scripts/test-install.ps1scripts/test-install.shscripts/README.mdREADME.mdinstall.sh
RELEASING.md
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Release-policy documentation should point to GitHub Releases as the only release-history source of truth.
Document release tags, release-note surfaces, and registry-facing version translation accurately in
RELEASING.md.
Files:
RELEASING.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:
RELEASING.mddocs/getting-started/installation.mdxREADME.md
**/*.mdx
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
MDX top-of-file SPDX comments must use {/* ... */} delimiters instead of HTML comment delimiters (Must-Fix)
**/*.mdx: In MDX files, top-of-file comments must use JSX comment delimiters:{/*to open and*/}to close; do not use HTML comments for MDX SPDX headers.
New or regenerated MDX files must use{/* ... */}for top-of-file SPDX comments.
Files:
docs/getting-started/installation.mdx
docs/**/*.{md,mdx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
docs/**/*.{md,mdx}: Keep documentation underdocs/valid for Fern tooling and external links, including Markdown/MDX link checks where applicable.
Update relevant reference docs and embedded examples when public behavior, bindings, examples, or workspace structure change.
Files:
docs/getting-started/installation.mdx
docs/**/*.mdx
📄 CodeRabbit inference engine (.agents/skills/contribute-integration/SKILL.md)
Update documentation if activation or usage changes
Files:
docs/getting-started/installation.mdx
{README.md,docs/**/*.{md,rst,txt},fern/**/*}
📄 CodeRabbit inference engine (.agents/skills/prepare-code-freeze/SKILL.md)
Search and update documentation source for references to the old version in
README.md,docs, andferndirectories, updating current-version install commands, package examples, and configuration examples to<next-version>
Files:
README.md
README.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Keep
README.mdcurrent with the workspace members and top-level documentation.
Files:
README.md
🧠 Learnings (1)
📚 Learning: 2026-05-03T04:23:07.497Z
Learnt from: willkill07
Repo: NVIDIA/NeMo-Flow PR: 46
File: .github/workflows/ci_rust.yml:31-64
Timestamp: 2026-05-03T04:23:07.497Z
Learning: In GitHub Actions workflow YAML, it’s valid to conditionally disable a service container by setting the service container’s `image` to an empty string (`''`) via a matrix variable (e.g., `redis_service_image: ''`). This intentionally makes the runner skip service initialization for that matrix entry rather than failing the job. When reviewing workflows, don’t flag this as an error if the workflow uses an empty `image` to disable the service on specific matrix entries (e.g., OS-specific setups); verify the `image` is sourced from the matrix variable and that the service is only expected to be available when a non-empty image is provided.
Applied to files:
.github/workflows/ci_changes.yml.github/workflows/ci_check.yml
🪛 GitHub Actions: Build pull request / 12_Check _ Install script (Windows ARM64).txt
install.ps1
[error] 20-20: test-install.ps1 failed: FAIL: expected 'could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/' in: Downloading NeMo Relay CLI 999.999.999 for aarch64-pc-windows-msvc... Exception: nemo-relay installer: could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/nemo-relay-cli-aarch64-pc-windows-msvc-999.999.999.exe
[error] 179-179: nemo-relay installer: could not download the expected CLI binary from the GitHub releases URL.
scripts/test-install.ps1
[error] 20-20: test-install.ps1 failed: FAIL: expected 'could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/' in: Downloading NeMo Relay CLI 999.999.999 for aarch64-pc-windows-msvc... Exception: nemo-relay installer: could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/nemo-relay-cli-aarch64-pc-windows-msvc-999.999.999.exe
[error] 179-179: nemo-relay installer: could not download the expected CLI binary from the GitHub releases URL.
🪛 GitHub Actions: Build pull request / 14_Check _ Install script (macos-arm64).txt
scripts/test-install.sh
[error] 1-1: test-install.sh failed: nemo-relay installer could not resolve the latest stable release. curl failed with exit code 56: requested URL returned error 403.
install.sh
[error] 1-1: test-install.sh failed: nemo-relay installer could not resolve the latest stable release. curl failed with exit code 56: requested URL returned error 403.
🪛 GitHub Actions: Build pull request / 15_Check _ Install script (Windows x86_64).txt
install.ps1
[error] 20-20: FAIL: expected 'could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/' in: Downloading NeMo Relay CLI 999.999.999 for x86_64-pc-windows-msvc... Exception: nemo-relay installer: could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/nemo-relay-cli-x86_64-pc-windows-msvc-999.999.999.exe
scripts/test-install.ps1
[error] 20-20: FAIL: expected 'could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/' in: Downloading NeMo Relay CLI 999.999.999 for x86_64-pc-windows-msvc... Exception: nemo-relay installer: could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/nemo-relay-cli-x86_64-pc-windows-msvc-999.999.999.exe
🪛 GitHub Actions: Build pull request / Check _ Install script (macos-arm64)
scripts/test-install.sh
[error] 1-1: Install script failed while resolving the latest stable NeMo Relay release. curl returned (56) HTTP 403 when fetching the latest release URL. nemo-relay installer: could not resolve the latest stable release.
install.sh
[error] 1-1: Install script failed while resolving the latest stable NeMo Relay release. curl returned (56) HTTP 403 when fetching the latest release URL. nemo-relay installer: could not resolve the latest stable release.
🪛 GitHub Actions: Build pull request / Check _ Install script (Windows ARM64)
install.ps1
[error] 20-20: Command step failed: test-install.ps1 threw "FAIL: expected 'could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/' in: Downloading NeMo Relay CLI 999.999.999 for aarch64-pc-windows-msvc... Exception: nemo-relay installer: could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/nemo-relay-cli-aarch64-pc-windows-msvc-999.999.999.exe"
[error] 179-179: nemo-relay installer failed to download the CLI executable: https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/nemo-relay-cli-aarch64-pc-windows-msvc-999.999.999.exe
scripts/test-install.ps1
[error] 20-20: Command step failed: test-install.ps1 threw "FAIL: expected 'could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/' in: Downloading NeMo Relay CLI 999.999.999 for aarch64-pc-windows-msvc... Exception: nemo-relay installer: could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/nemo-relay-cli-aarch64-pc-windows-msvc-999.999.999.exe"
[error] 179-179: nemo-relay installer failed to download the CLI executable: https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/nemo-relay-cli-aarch64-pc-windows-msvc-999.999.999.exe
🪛 GitHub Actions: Build pull request / Check _ Install script (Windows x86_64)
install.ps1
[error] 20-20: FAIL: expected 'could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/' in: Downloading NeMo Relay CLI 999.999.999 for x86_64-pc-windows-msvc... Exception: nemo-relay installer: could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/nemo-relay-cli-x86_64-pc-windows-msvc-999.999.999.exe
[error] 179-179: nemo-relay installer: could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/nemo-relay-cli-x86_64-pc-windows-msvc-999.999.999.exe
scripts/test-install.ps1
[error] 20-20: FAIL: expected 'could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/' in: Downloading NeMo Relay CLI 999.999.999 for x86_64-pc-windows-msvc... Exception: nemo-relay installer: could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/nemo-relay-cli-x86_64-pc-windows-msvc-999.999.999.exe
[error] 179-179: nemo-relay installer: could not download https://github.com/NVIDIA/NeMo-Relay/releases/download/999.999.999/nemo-relay-cli-x86_64-pc-windows-msvc-999.999.999.exe
🪛 PSScriptAnalyzer (1.25.0)
install.ps1
[warning] 86-86: The cmdlet 'Download-File' uses an unapproved verb.
(PSUseApprovedVerbs)
scripts/test-install.ps1
[warning] 29-29: The cmdlet 'Assert-Contains' uses a plural noun. A singular noun should be used instead.
Suggested fix: Singularized correction of 'Assert-Contains'
(PSUseSingularNouns)
[warning] 33-33: The cmdlet 'Assert-PathContains' uses a plural noun. A singular noun should be used instead.
Suggested fix: Singularized correction of 'Assert-PathContains'
(PSUseSingularNouns)
[warning] 43-43: The cmdlet 'Assert-NoTemporaryFiles' uses a plural noun. A singular noun should be used instead.
Suggested fix: Singularized correction of 'Assert-NoTemporaryFiles'
(PSUseSingularNouns)
🪛 Shellcheck (0.11.0)
scripts/test-install-mocks.sh
[warning] 7-7: Remove space after = if trying to assign a value (for empty string, use var='' ... ).
(SC1007)
[warning] 129-129: Quotes/backslashes will be treated literally. Rewrite using set/"$@" or functions.
(SC2089)
[warning] 138-138: Quotes/backslashes in this variable will not be respected.
(SC2090)
[warning] 210-210: Quotes/backslashes will be treated literally. Rewrite using set/"$@" or functions.
(SC2089)
[warning] 211-211: Quotes/backslashes in this variable will not be respected.
(SC2090)
install.sh
[info] 211-227: Expressions don't expand in single quotes, use double quotes for that.
(SC2016)
🔇 Additional comments (16)
README.md (1)
53-69: LGTM!RELEASING.md (1)
323-326: LGTM!crates/cli/README.md (1)
6-27: LGTM!docs/getting-started/installation.mdx (1)
33-158: LGTM!install.sh (3)
11-33: LGTM!Also applies to: 47-79, 81-105, 107-120, 121-152, 154-160, 161-172, 181-193, 194-198, 238-245
173-180: Timeout fix from the earlier review is in place.
curl_with_timeoutsis now used for both the asset and checksum downloads, and the mocked test suite (scripts/test-install-mocks.sh) verifies--connect-timeout/--max-timeare actually passed through. This addresses the previously raised concern aboutcurlcalls hanging indefinitely.
199-237: Windows PATH update logic looks correct; shellcheck SC2016 is a false positive.The single-quoted
-Commandblock intentionally avoids shell expansion —$installDir/$env:*are PowerShell variables populated via theNEMO_RELAY_INSTALL_DIRenvironment variable, not shell variables.Add-ToPathcorrectly de-dupes case-insensitively and trims trailing backslashes before comparing/appending. No changes needed here.scripts/test-install.sh (1)
1-16: LGTM!Also applies to: 18-47, 48-70, 100-122
scripts/test-install-mocks.sh (1)
1-252: LGTM! Mock coverage for platform mapping, unsupported platform, malformed release response, missing checksum, and checksum mismatch is thorough and each scenario asserts the expected fail-closed behavior (no partial install, existing binary preserved, temp files cleaned up).The shellcheck SC1007/SC2089/SC2090 hints on lines 7, 129, 138, 210, 211 are false positives here — the
CDPATH=idiom is intentional, and the flagged variables hold literal data strings printed by mocks, not values passed toeval/exec..github/workflows/ci_check.yml (3)
46-58: 📐 Maintainability & Code QualityMock-only tests restricted to a single matrix entry.
run_mock_testsistrueonly forlinux-x86_64;linux-arm64andmacos-arm64skipscripts/test-install-mocks.shentirely. This mirrors an earlier open review comment ("Testing should be validated on the complete matrix") that doesn't appear to have a resolution marker. Since the mocks simulate other platforms via mockeduname/curloutput (host-agnostic), running them once is likely intentional, but worth confirming this scoping is deliberate rather than an oversight from trimming CI time.Also applies to: 72-79
24-28: LGTM!
81-121: LGTM!.github/ci-path-filters.yml (1)
10-20: LGTM!.github/workflows/ci_changes.yml (1)
39-41: LGTM!Also applies to: 79-79
.github/workflows/ci.yaml (1)
123-123: LGTM!scripts/README.md (1)
17-19: LGTM!
Signed-off-by: Bryan Bednarski <bbednarski@nvidia.com>
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 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/README.md`:
- Line 138: The README currently uses a raw URL in running text; update the NeMo
Relay documentation reference to use descriptive link text instead of a bare
link. Edit the Markdown in the relevant README section so the displayed text
describes the destination while pointing to the same NeMo Relay documentation
URL.
- Around line 58-62: Update the installation wording in the CLI README so it
matches the actual command: the current `cargo install nemo-relay-cli` in the
“To build the CLI from source” section refers to installing the published crate,
not building from the local source tree. Either rename the section to “To
install the CLI from crates.io” or replace the command with a true source-build
flow, and keep the wording aligned with the package name and build command used
in this README.
- Around line 6-17: The README starts with the badge row instead of the main
heading, which triggers the Markdown heading rule and hurts readability. Move
the `# NeMo Relay` heading to the top of the document, then place the badge
block directly underneath it in `crates/cli/README.md`. While editing, keep the
heading text in title case to match the documentation style guidelines.
In `@install.sh`:
- Around line 48-54: The github_api_curl() helper is expanding GH_TOKEN directly
into curl arguments, which exposes the token in argv. Update github_api_curl()
to pass the Authorization header through a non-argv mechanism such as curl
config/stdin or another safe transport, while preserving the existing Accept and
User-Agent headers. Also adjust the mock parser used by the install script tests
so it can recognize the new header-passing path and still validate authenticated
requests.
🪄 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: 0a1e5ed5-96e0-424f-a406-c3a0f2f87afb
📒 Files selected for processing (5)
crates/cli/README.mdinstall.ps1install.shscripts/test-install-mocks.shscripts/test-install.ps1
📜 Review details
⏰ Context from checks skipped due to timeout. (2)
- GitHub Check: Check / Run
- GitHub Check: Preview docs
🧰 Additional context used
📓 Path-based instructions (11)
**/*.{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:
crates/cli/README.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:
crates/cli/README.md
**/*.{md,rst,txt}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
Spell
NVIDIAin all caps. Do not useNvidia,nvidia, orNV.
Files:
crates/cli/README.md
**/*.{md,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
**/*.{md,rst}: 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 docs.
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 docs unless the source, platform, or legal guidance explicitly requires them.
Files:
crates/cli/README.md
**/*.md
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-technical-docs.md)
**/*.md: 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
Format code elements, commands, parameters, package names, and expressions in monospace
Format directories, file names, and paths in monospace using backticks
Use angle brackets inside monospace for variables inside paths, such as/home/<username>/.login
Format error messages and strings in quotation marks, keeping literal code strings in code formatting when clearer
Format UI buttons, menus, fields, and labels in bold
Use angle brackets between UI labels for menu paths, such as File > Save As
Use italics for new terms on first use, sparingly and only when introducing the term
Use italics for publication titles
Format keyboard shortcuts in plain text, such as Press Ctrl+Alt+Delete
Use owner/repo link text for GitHub repositories, preferring[NVIDIA/NeMo](link)over prose references 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
Avoid generic anchor text such as 'here,' 'this page,' and 'read more'
Include acronyms in link text when a linked term includes an acronym
Do not link long sentences or multiple sentences
Avoid links that pull readers away from a procedure unless the link is a p...
Files:
crates/cli/README.md
**/*
📄 CodeRabbit inference engine (AGENTS.md)
Keep SPDX headers on source, docs, scripts, and configuration files.
Files:
crates/cli/README.mdinstall.ps1scripts/test-install-mocks.shscripts/test-install.ps1install.sh
**/*.{rs,go,js,ts,py,html,md,mdx,toml,yml,yaml,c,h}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Include SPDX license headers in all source files using the correct comment syntax for the file type.
Files:
crates/cli/README.md
**/*.{md,mdx}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
**/*.{md,mdx}: Prefer the documented public API rather than internal shortcuts.
Keep package names, repository references, and build commands current.
Update entry-point docs when examples or reading paths change.
Keep release-process and release-notes guidance in repository-maintainer docs such asRELEASING.md, not in user-facing docs pages orCHANGELOG.md.
Keep stable user-facing wrappers at thescripts/root in docs and examples; only point at namespaced helper paths when documenting internal maintenance work.
When detailed dynamic plugin guides exist, keep Rust native plugin examples, Python worker plugin examples, andgrpc-v1protocol details on separate pages.
Dynamic plugin manifests in docs and examples should usecompat.relay = ">=0.5,<1.0"unless deliberately narrower.
Update relevant getting-started or reference docs when the associated behavior or examples change.
Ensure example commands still match current package names and paths.
Dynamic plugin entry pages should link to native, worker, Rust example, Python example, and protocol pages when those pages exist.
When the docs site changes, runjust docs;./scripts/build-docs.sh htmlremains the compatibility wrapper.
**/*.{md,mdx}: Document native and worker plugins as trusted extensions: native plugins are in-process and unsandboxed, while worker plugins provide process isolation but not a security sandbox.
When detailed dynamic plugin guides exist, keep Rust native, Python worker, andgrpc-v1protocol details on separate pages.
Files:
crates/cli/README.md
**/README.md
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
**/README.md: UpdateREADME.mdwhen entry points change.
Update relevant package or crateREADME.mdfiles when examples or binding guidance changes.
Files:
crates/cli/README.md
**
⚙️ CodeRabbit configuration file
**:AGENTS.md
This file provides guidance to agents, including Claude Code and OpenAI Codex, when working in this repository.
Project Overview
NeMo Relay is a multi-language agent runtime framework for execution scopes, lifecycle events, middleware, plugins, and observability around tool and LLM calls. The core runtime is Rust. Primary supported bindings are Rust, Python, and Node.js. Go and the raw C FFI are experimental and source-first.
The shared runtime model is:
- Scope stacks decide where work belongs and which scope-local behavior is visible.
- Middleware registries decide what guardrails and intercepts run around managed calls.
- Plugins install reusable runtime behavior from configuration.
- Events record runtime behavior in ATOF form.
- Subscribers and exporters consume events in-process or export them to ATIF, OpenTelemetry, OpenInference, or other backends.
Repository Structure
The repository layout separates the Rust runtime, language bindings,
documentation, integrations, and agent-facing skills.crates/ core/ # Rust core runtime crate, published as nemo-relay adaptive/ # Adaptive runtime primitives and plugin components python/ # PyO3 native extension for the Python package ffi/ # Raw C ABI layer used by downstream bindings such as Go node/ # NAPI Node.js binding and JavaScript/TypeScript entry points python/ nemo_relay/ # Python wrapper package: scopes, tools, LLM, middleware, typed helpers, plugins, adaptive helpers tests/ # Python tests go/ nemo_relay/ # Experimental Go CGo binding and tests fern/ # Fern documentation site scripts/ # Stable wrappers and helper scripts; build/test/docs entry points live in justfile skills/ # Published Codex/agent skills for NeMo Relay usage patternsPrerequisites
Insta...
Files:
crates/cli/README.mdinstall.ps1scripts/test-install-mocks.shscripts/test-install.ps1install.sh
{.github/**,.gitlab-ci.yml,.pre-commit-config.yaml,justfile,scripts/**}
⚙️ CodeRabbit configuration file
{.github/**,.gitlab-ci.yml,.pre-commit-config.yaml,justfile,scripts/**}: Review automation changes for reproducibility, pinned versions where appropriate, secret handling, and consistency with the documented validation matrix.
Pay attention to commands that need generated native artifacts, FFI libraries, or platform-specific environment variables.
Files:
scripts/test-install-mocks.shscripts/test-install.ps1
🪛 markdownlint-cli2 (0.22.1)
crates/cli/README.md
[warning] 6-6: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
🪛 Shellcheck (0.11.0)
scripts/test-install-mocks.sh
[warning] 145-145: Quotes/backslashes in this variable will not be respected.
(SC2090)
🔇 Additional comments (6)
install.sh (1)
124-124: LGTM!scripts/test-install-mocks.sh (1)
63-69: LGTM!Also applies to: 83-83, 138-147
install.ps1 (2)
111-119: Duplicate: preserve expandable userPATHentries.This still round-trips the user
Paththrough[Environment]::GetEnvironmentVariableand[Environment]::SetEnvironmentVariable, which can flatten existing expandable registry entries. The prior review already covers using registry APIs instead.
1-110: LGTM!Also applies to: 121-185
scripts/test-install.ps1 (2)
77-85: Duplicate: make captured output width deterministic.Both capture paths still pipe to
Out-Stringwithout-Width, so long installer error lines can wrap and breakAssert-Containschecks in CI. The prior review already proposed adding a large explicit width.Source: Pipeline failures
1-62: LGTM!Also applies to: 90-151
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 4
🤖 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/README.md`:
- Line 138: The README currently uses a raw URL in running text; update the NeMo
Relay documentation reference to use descriptive link text instead of a bare
link. Edit the Markdown in the relevant README section so the displayed text
describes the destination while pointing to the same NeMo Relay documentation
URL.
- Around line 58-62: Update the installation wording in the CLI README so it
matches the actual command: the current `cargo install nemo-relay-cli` in the
“To build the CLI from source” section refers to installing the published crate,
not building from the local source tree. Either rename the section to “To
install the CLI from crates.io” or replace the command with a true source-build
flow, and keep the wording aligned with the package name and build command used
in this README.
- Around line 6-17: The README starts with the badge row instead of the main
heading, which triggers the Markdown heading rule and hurts readability. Move
the `# NeMo Relay` heading to the top of the document, then place the badge
block directly underneath it in `crates/cli/README.md`. While editing, keep the
heading text in title case to match the documentation style guidelines.
In `@install.sh`:
- Around line 48-54: The github_api_curl() helper is expanding GH_TOKEN directly
into curl arguments, which exposes the token in argv. Update github_api_curl()
to pass the Authorization header through a non-argv mechanism such as curl
config/stdin or another safe transport, while preserving the existing Accept and
User-Agent headers. Also adjust the mock parser used by the install script tests
so it can recognize the new header-passing path and still validate authenticated
requests.
🪄 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: 0a1e5ed5-96e0-424f-a406-c3a0f2f87afb
📒 Files selected for processing (5)
crates/cli/README.mdinstall.ps1install.shscripts/test-install-mocks.shscripts/test-install.ps1
📜 Review details
🔇 Additional comments (6)
install.sh (1)
124-124: LGTM!scripts/test-install-mocks.sh (1)
63-69: LGTM!Also applies to: 83-83, 138-147
install.ps1 (2)
111-119: Duplicate: preserve expandable userPATHentries.This still round-trips the user
Paththrough[Environment]::GetEnvironmentVariableand[Environment]::SetEnvironmentVariable, which can flatten existing expandable registry entries. The prior review already covers using registry APIs instead.
1-110: LGTM!Also applies to: 121-185
scripts/test-install.ps1 (2)
77-85: Duplicate: make captured output width deterministic.Both capture paths still pipe to
Out-Stringwithout-Width, so long installer error lines can wrap and breakAssert-Containschecks in CI. The prior review already proposed adding a large explicit width.Source: Pipeline failures
1-62: LGTM!Also applies to: 90-151
🛑 Comments failed to post (4)
crates/cli/README.md (3)
6-17: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Move the H1 above the badge row.
The file now starts with badges, which trips MD041 and makes the README harder to scan. Put
# NeMo Relayfirst, then keep the badge block underneath.As per coding guidelines,
**/*.md: Use title case consistently in technical documentation headings.Suggested fix
- [badge row] - # NeMo Relay + +[badge row]📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.# NeMo Relay [](https://github.com/NVIDIA/NeMo-Relay/blob/main/LICENSE) [](https://github.com/NVIDIA/NeMo-Relay/) [](https://github.com/NVIDIA/NeMo-Relay/releases) [](https://app.codecov.io/gh/NVIDIA/NeMo-Relay) [](https://pypi.org/project/nemo-relay/) [](https://www.npmjs.com/package/nemo-relay-node) [](https://crates.io/crates/nemo-relay) [](https://crates.io/crates/nemo-relay-adaptive) [](https://crates.io/crates/nemo-relay-cli) [](https://deepwiki.com/NVIDIA/NeMo-Relay)🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 6-6: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
🤖 Prompt for 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. In `@crates/cli/README.md` around lines 6 - 17, The README starts with the badge row instead of the main heading, which triggers the Markdown heading rule and hurts readability. Move the `# NeMo Relay` heading to the top of the document, then place the badge block directly underneath it in `crates/cli/README.md`. While editing, keep the heading text in title case to match the documentation style guidelines.Sources: Coding guidelines, Linters/SAST tools
58-62: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Fix the installation wording.
cargo install nemo-relay-cliinstalls the published crate from crates.io; it does not build from the local source tree. Rename this to "To install the CLI from crates.io" or switch to a true source-build command so the text matches the command.As per coding guidelines,
**/*.md: Keep package names, repository references, and build commands current.Suggested fix
-To build the CLI from source: +To install the CLI from crates.io:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.To install the CLI from crates.io:🤖 Prompt for 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. In `@crates/cli/README.md` around lines 58 - 62, Update the installation wording in the CLI README so it matches the actual command: the current `cargo install nemo-relay-cli` in the “To build the CLI from source” section refers to installing the published crate, not building from the local source tree. Either rename the section to “To install the CLI from crates.io” or replace the command with a true source-build flow, and keep the wording aligned with the package name and build command used in this README.Source: Coding guidelines
138-138: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Replace the bare URL with link text.
The final line uses a raw URL in running text. Use descriptive link text instead.
As per coding guidelines,
**/*.md: Avoid raw URLs in running text.Suggested fix
-NeMo Relay Documentation: https://docs.nvidia.com/nemo/relay +[NeMo Relay Documentation](https://docs.nvidia.com/nemo/relay)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.[NeMo Relay Documentation](https://docs.nvidia.com/nemo/relay)🤖 Prompt for 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. In `@crates/cli/README.md` at line 138, The README currently uses a raw URL in running text; update the NeMo Relay documentation reference to use descriptive link text instead of a bare link. Edit the Markdown in the relevant README section so the displayed text describes the destination while pointing to the same NeMo Relay documentation URL.Source: Coding guidelines
install.sh (1)
48-54: 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Avoid putting
GH_TOKENincurlargv.Line 53 expands the bearer token into a command-line argument, which can expose it through process inspection. Pass the header through stdin/config or another non-argv path, and update the mock parser accordingly.
Proposed direction
github_api_curl() { if [ -n "${GH_TOKEN:-}" ]; then - curl_with_timeouts \ - -H 'Accept: application/vnd.github+json' \ - -H 'User-Agent: nemo-relay-install-script' \ - -H "Authorization: Bearer ${GH_TOKEN}" \ - "$@" + curl_with_timeouts --config - "$@" <<EOF +header = "Accept: application/vnd.github+json" +header = "User-Agent: nemo-relay-install-script" +header = "Authorization: Bearer ${GH_TOKEN}" +EOF📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.github_api_curl() { if [ -n "${GH_TOKEN:-}" ]; then curl_with_timeouts --config - "$@" <<EOF header = "Accept: application/vnd.github+json" header = "User-Agent: nemo-relay-install-script" header = "Authorization: Bearer ${GH_TOKEN}" EOF🤖 Prompt for 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. In `@install.sh` around lines 48 - 54, The github_api_curl() helper is expanding GH_TOKEN directly into curl arguments, which exposes the token in argv. Update github_api_curl() to pass the Authorization header through a non-argv mechanism such as curl config/stdin or another safe transport, while preserving the existing Accept and User-Agent headers. Also adjust the mock parser used by the install script tests so it can recognize the new header-passing path and still validate authenticated requests.
Signed-off-by: Bryan Bednarski <bbednarski@nvidia.com>
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/README.md`:
- Around line 60-75: The install section in the README needs formatting and
wording cleanup: add the missing blank line before the Unix curl code fence to
satisfy MD031, and update the transition near the install commands to use the
post-install verification step rather than describing the binary install result.
Adjust the surrounding text in the README section around the curl/PowerShell
snippets and the `nemo-relay --version` lead-in so it clearly introduces
verification after installation.
🪄 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: 3f4f5216-bea8-4b37-8fb0-40e398caa4bb
📒 Files selected for processing (1)
crates/cli/README.md
📜 Review details
⏰ Context from checks skipped due to timeout. (4)
- GitHub Check: Check / Run
- GitHub Check: Check / Install script (Windows x86_64)
- GitHub Check: Check / Install script (Windows ARM64)
- GitHub Check: Preview docs
🧰 Additional context used
📓 Path-based instructions (10)
**/*.{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:
crates/cli/README.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:
crates/cli/README.md
**/*.{md,rst,txt}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
Spell
NVIDIAin all caps. Do not useNvidia,nvidia, orNV.
Files:
crates/cli/README.md
**/*.{md,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
**/*.{md,rst}: 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 docs.
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 docs unless the source, platform, or legal guidance explicitly requires them.
Files:
crates/cli/README.md
**/*.md
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-technical-docs.md)
**/*.md: 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
Format code elements, commands, parameters, package names, and expressions in monospace
Format directories, file names, and paths in monospace using backticks
Use angle brackets inside monospace for variables inside paths, such as/home/<username>/.login
Format error messages and strings in quotation marks, keeping literal code strings in code formatting when clearer
Format UI buttons, menus, fields, and labels in bold
Use angle brackets between UI labels for menu paths, such as File > Save As
Use italics for new terms on first use, sparingly and only when introducing the term
Use italics for publication titles
Format keyboard shortcuts in plain text, such as Press Ctrl+Alt+Delete
Use owner/repo link text for GitHub repositories, preferring[NVIDIA/NeMo](link)over prose references 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
Avoid generic anchor text such as 'here,' 'this page,' and 'read more'
Include acronyms in link text when a linked term includes an acronym
Do not link long sentences or multiple sentences
Avoid links that pull readers away from a procedure unless the link is a p...
Files:
crates/cli/README.md
**/*
📄 CodeRabbit inference engine (AGENTS.md)
Keep SPDX headers on source, docs, scripts, and configuration files.
Files:
crates/cli/README.md
**/*.{rs,go,js,ts,py,html,md,mdx,toml,yml,yaml,c,h}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Include SPDX license headers in all source files using the correct comment syntax for the file type.
Files:
crates/cli/README.md
**/*.{md,mdx}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
**/*.{md,mdx}: Prefer the documented public API rather than internal shortcuts.
Keep package names, repository references, and build commands current.
Update entry-point docs when examples or reading paths change.
Keep release-process and release-notes guidance in repository-maintainer docs such asRELEASING.md, not in user-facing docs pages orCHANGELOG.md.
Keep stable user-facing wrappers at thescripts/root in docs and examples; only point at namespaced helper paths when documenting internal maintenance work.
When detailed dynamic plugin guides exist, keep Rust native plugin examples, Python worker plugin examples, andgrpc-v1protocol details on separate pages.
Dynamic plugin manifests in docs and examples should usecompat.relay = ">=0.5,<1.0"unless deliberately narrower.
Update relevant getting-started or reference docs when the associated behavior or examples change.
Ensure example commands still match current package names and paths.
Dynamic plugin entry pages should link to native, worker, Rust example, Python example, and protocol pages when those pages exist.
When the docs site changes, runjust docs;./scripts/build-docs.sh htmlremains the compatibility wrapper.
**/*.{md,mdx}: Document native and worker plugins as trusted extensions: native plugins are in-process and unsandboxed, while worker plugins provide process isolation but not a security sandbox.
When detailed dynamic plugin guides exist, keep Rust native, Python worker, andgrpc-v1protocol details on separate pages.
Files:
crates/cli/README.md
**/README.md
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
**/README.md: UpdateREADME.mdwhen entry points change.
Update relevant package or crateREADME.mdfiles when examples or binding guidance changes.
Files:
crates/cli/README.md
**
⚙️ CodeRabbit configuration file
**:AGENTS.md
This file provides guidance to agents, including Claude Code and OpenAI Codex, when working in this repository.
Project Overview
NeMo Relay is a multi-language agent runtime framework for execution scopes, lifecycle events, middleware, plugins, and observability around tool and LLM calls. The core runtime is Rust. Primary supported bindings are Rust, Python, and Node.js. Go and the raw C FFI are experimental and source-first.
The shared runtime model is:
- Scope stacks decide where work belongs and which scope-local behavior is visible.
- Middleware registries decide what guardrails and intercepts run around managed calls.
- Plugins install reusable runtime behavior from configuration.
- Events record runtime behavior in ATOF form.
- Subscribers and exporters consume events in-process or export them to ATIF, OpenTelemetry, OpenInference, or other backends.
Repository Structure
The repository layout separates the Rust runtime, language bindings,
documentation, integrations, and agent-facing skills.crates/ core/ # Rust core runtime crate, published as nemo-relay adaptive/ # Adaptive runtime primitives and plugin components python/ # PyO3 native extension for the Python package ffi/ # Raw C ABI layer used by downstream bindings such as Go node/ # NAPI Node.js binding and JavaScript/TypeScript entry points python/ nemo_relay/ # Python wrapper package: scopes, tools, LLM, middleware, typed helpers, plugins, adaptive helpers tests/ # Python tests go/ nemo_relay/ # Experimental Go CGo binding and tests fern/ # Fern documentation site scripts/ # Stable wrappers and helper scripts; build/test/docs entry points live in justfile skills/ # Published Codex/agent skills for NeMo Relay usage patternsPrerequisites
Insta...
Files:
crates/cli/README.md
🪛 markdownlint-cli2 (0.22.1)
crates/cli/README.md
[warning] 61-61: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
🔇 Additional comments (1)
crates/cli/README.md (1)
128-132: LGTM!
Signed-off-by: Bryan Bednarski <bbednarski@nvidia.com>
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/getting-started/installation.mdx (1)
82-94: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winTable headers should use title case.
"Operating system" and "Release target" are sentence case; guidelines require title case for table headers.
✏️ Proposed fix
-| Operating system | Architecture | Release target | +| Operating System | Architecture | Release Target |As per coding guidelines, "Use title case for table headers."
🤖 Prompt for 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. In `@docs/getting-started/installation.mdx` around lines 82 - 94, The Supported Platforms table in installation.mdx uses sentence case for headers that should be title case. Update the table header labels in the supported platforms section so they follow the project’s table header convention, keeping the rest of the content unchanged and preserving the existing release target values and platform entries.Source: Coding guidelines
🤖 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 `@docs/getting-started/installation.mdx`:
- Around line 168-169: The installation docs link in the getting-started page
points to a stale CLI README anchor, so update the reference from the old
installation section to the current `Installation Options` anchor in the `CLI
README` link. Use the existing installation guidance text in `installation.mdx`
and the `crates/cli/README.md` section name to locate the link, and replace the
outdated fragment so the source-installation and unsupported-platform guidance
resolves correctly.
---
Outside diff comments:
In `@docs/getting-started/installation.mdx`:
- Around line 82-94: The Supported Platforms table in installation.mdx uses
sentence case for headers that should be title case. Update the table header
labels in the supported platforms section so they follow the project’s table
header convention, keeping the rest of the content unchanged and preserving the
existing release target values and platform entries.
🪄 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: 4d2faba8-ea65-4a85-a5c8-906a110a2d33
📒 Files selected for processing (7)
README.mdcrates/cli/README.mddocs/getting-started/installation.mdxinstall.ps1scripts/README.mdscripts/test-install.ps1scripts/test-install.sh
📜 Review details
⏰ Context from checks skipped due to timeout. (21)
- GitHub Check: Rust / Test (linux-arm64)
- GitHub Check: Go / Test (windows-arm64)
- GitHub Check: Rust / Test (windows-arm64)
- GitHub Check: Rust / Test (linux-amd64)
- GitHub Check: Rust / Test (macos-arm64)
- GitHub Check: Rust / Test (windows-amd64)
- GitHub Check: Go / Test (linux-amd64)
- GitHub Check: Go / Test (windows-amd64)
- GitHub Check: Go / Test (linux-arm64)
- GitHub Check: Node.js / Test (linux-amd64)
- GitHub Check: Python / Test (linux-arm64)
- GitHub Check: Python / Test (windows-arm64)
- GitHub Check: Python / Test (macos-arm64)
- GitHub Check: Node.js / Test (windows-amd64)
- GitHub Check: Node.js / Test (macos-arm64)
- GitHub Check: Go / Test (macos-arm64)
- GitHub Check: Python / Test (windows-amd64)
- GitHub Check: Python / Test (linux-amd64)
- GitHub Check: Node.js / Test (linux-arm64)
- GitHub Check: Node.js / Test (windows-arm64)
- GitHub Check: Preview docs
🧰 Additional context used
📓 Path-based instructions (17)
**/*.{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:
README.mdscripts/README.mdcrates/cli/README.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:
README.mdscripts/README.mdcrates/cli/README.md
**/*.{md,rst,txt}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
Spell
NVIDIAin all caps. Do not useNvidia,nvidia, orNV.
Files:
README.mdscripts/README.mdcrates/cli/README.md
**/*.{md,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
**/*.{md,rst}: 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 docs.
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 docs unless the source, platform, or legal guidance explicitly requires them.
Files:
README.mdscripts/README.mdcrates/cli/README.md
**/*.md
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-technical-docs.md)
**/*.md: 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
Format code elements, commands, parameters, package names, and expressions in monospace
Format directories, file names, and paths in monospace using backticks
Use angle brackets inside monospace for variables inside paths, such as/home/<username>/.login
Format error messages and strings in quotation marks, keeping literal code strings in code formatting when clearer
Format UI buttons, menus, fields, and labels in bold
Use angle brackets between UI labels for menu paths, such as File > Save As
Use italics for new terms on first use, sparingly and only when introducing the term
Use italics for publication titles
Format keyboard shortcuts in plain text, such as Press Ctrl+Alt+Delete
Use owner/repo link text for GitHub repositories, preferring[NVIDIA/NeMo](link)over prose references 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
Avoid generic anchor text such as 'here,' 'this page,' and 'read more'
Include acronyms in link text when a linked term includes an acronym
Do not link long sentences or multiple sentences
Avoid links that pull readers away from a procedure unless the link is a p...
Files:
README.mdscripts/README.mdcrates/cli/README.md
{README.md,docs/**/*.{md,rst,txt},fern/**/*}
📄 CodeRabbit inference engine (.agents/skills/prepare-code-freeze/SKILL.md)
Search and update documentation source for references to the old version in
README.md,docs, andferndirectories, updating current-version install commands, package examples, and configuration examples to<next-version>
Files:
README.md
**/*
📄 CodeRabbit inference engine (AGENTS.md)
Keep SPDX headers on source, docs, scripts, and configuration files.
Files:
README.mdscripts/README.mddocs/getting-started/installation.mdxscripts/test-install.shcrates/cli/README.mdscripts/test-install.ps1install.ps1
README.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Keep
README.mdcurrent with the workspace members and top-level documentation.
Files:
README.md
**/*.{rs,go,js,ts,py,html,md,mdx,toml,yml,yaml,c,h}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Include SPDX license headers in all source files using the correct comment syntax for the file type.
Files:
README.mdscripts/README.mddocs/getting-started/installation.mdxcrates/cli/README.md
**/*.{md,mdx}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
**/*.{md,mdx}: Prefer the documented public API rather than internal shortcuts.
Keep package names, repository references, and build commands current.
Update entry-point docs when examples or reading paths change.
Keep release-process and release-notes guidance in repository-maintainer docs such asRELEASING.md, not in user-facing docs pages orCHANGELOG.md.
Keep stable user-facing wrappers at thescripts/root in docs and examples; only point at namespaced helper paths when documenting internal maintenance work.
When detailed dynamic plugin guides exist, keep Rust native plugin examples, Python worker plugin examples, andgrpc-v1protocol details on separate pages.
Dynamic plugin manifests in docs and examples should usecompat.relay = ">=0.5,<1.0"unless deliberately narrower.
Update relevant getting-started or reference docs when the associated behavior or examples change.
Ensure example commands still match current package names and paths.
Dynamic plugin entry pages should link to native, worker, Rust example, Python example, and protocol pages when those pages exist.
When the docs site changes, runjust docs;./scripts/build-docs.sh htmlremains the compatibility wrapper.
**/*.{md,mdx}: Document native and worker plugins as trusted extensions: native plugins are in-process and unsandboxed, while worker plugins provide process isolation but not a security sandbox.
When detailed dynamic plugin guides exist, keep Rust native, Python worker, andgrpc-v1protocol details on separate pages.
Files:
README.mdscripts/README.mddocs/getting-started/installation.mdxcrates/cli/README.md
**/README.md
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
**/README.md: UpdateREADME.mdwhen entry points change.
Update relevant package or crateREADME.mdfiles when examples or binding guidance changes.
Files:
README.mdscripts/README.mdcrates/cli/README.md
**
⚙️ CodeRabbit configuration file
**:AGENTS.md
This file provides guidance to agents, including Claude Code and OpenAI Codex, when working in this repository.
Project Overview
NeMo Relay is a multi-language agent runtime framework for execution scopes, lifecycle events, middleware, plugins, and observability around tool and LLM calls. The core runtime is Rust. Primary supported bindings are Rust, Python, and Node.js. Go and the raw C FFI are experimental and source-first.
The shared runtime model is:
- Scope stacks decide where work belongs and which scope-local behavior is visible.
- Middleware registries decide what guardrails and intercepts run around managed calls.
- Plugins install reusable runtime behavior from configuration.
- Events record runtime behavior in ATOF form.
- Subscribers and exporters consume events in-process or export them to ATIF, OpenTelemetry, OpenInference, or other backends.
Repository Structure
The repository layout separates the Rust runtime, language bindings,
documentation, integrations, and agent-facing skills.crates/ core/ # Rust core runtime crate, published as nemo-relay adaptive/ # Adaptive runtime primitives and plugin components python/ # PyO3 native extension for the Python package ffi/ # Raw C ABI layer used by downstream bindings such as Go node/ # NAPI Node.js binding and JavaScript/TypeScript entry points python/ nemo_relay/ # Python wrapper package: scopes, tools, LLM, middleware, typed helpers, plugins, adaptive helpers tests/ # Python tests go/ nemo_relay/ # Experimental Go CGo binding and tests fern/ # Fern documentation site scripts/ # Stable wrappers and helper scripts; build/test/docs entry points live in justfile skills/ # Published Codex/agent skills for NeMo Relay usage patternsPrerequisites
Insta...
Files:
README.mdscripts/README.mddocs/getting-started/installation.mdxscripts/test-install.shcrates/cli/README.mdscripts/test-install.ps1install.ps1
{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:
README.mddocs/getting-started/installation.mdx
{.github/**,.gitlab-ci.yml,.pre-commit-config.yaml,justfile,scripts/**}
⚙️ CodeRabbit configuration file
{.github/**,.gitlab-ci.yml,.pre-commit-config.yaml,justfile,scripts/**}: Review automation changes for reproducibility, pinned versions where appropriate, secret handling, and consistency with the documented validation matrix.
Pay attention to commands that need generated native artifacts, FFI libraries, or platform-specific environment variables.
Files:
scripts/README.mdscripts/test-install.shscripts/test-install.ps1
**/*.mdx
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
MDX top-of-file SPDX comments must use {/* ... */} delimiters instead of HTML comment delimiters (Must-Fix)
**/*.mdx: In MDX files, top-of-file comments must use JSX comment delimiters:{/*to open and*/}to close; do not use HTML comments for MDX SPDX headers.
New or regenerated MDX files must use{/* ... */}for top-of-file SPDX comments.
Files:
docs/getting-started/installation.mdx
docs/**/*.{md,mdx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
docs/**/*.{md,mdx}: Keep documentation underdocs/valid for Fern tooling and external links, including Markdown/MDX link checks where applicable.
Update relevant reference docs and embedded examples when public behavior, bindings, examples, or workspace structure change.
Files:
docs/getting-started/installation.mdx
docs/**/*.mdx
📄 CodeRabbit inference engine (.agents/skills/contribute-integration/SKILL.md)
Update documentation if activation or usage changes
Files:
docs/getting-started/installation.mdx
🔇 Additional comments (13)
scripts/test-install.sh (1)
92-98: LGTM!scripts/README.md (1)
17-19: LGTM!README.md (3)
67-69: 📐 Maintainability & Code QualityUnaddressed: use "Refer to" instead of "See".
This wording matches a prior reviewer suggestion (lvojtku) that hasn't been applied yet. Coding guidelines prefer
refer tooverseewhen pointing readers to another resource.✏️ Proposed fix
-The installer supports Linux x86_64/ARM64, macOS Apple Silicon, and Windows -x86_64/ARM64. See the [installation guide](https://docs.nvidia.com/nemo/relay/getting-started/installation) -for version pinning, custom directories, and source-based installation. +The installer supports Linux x86_64/ARM64, macOS Apple Silicon, and Windows +x86_64/ARM64. Refer to the [installation guide](https://docs.nvidia.com/nemo/relay/getting-started/installation) +for version pinning, custom directories, and source-based installation.Source: Coding guidelines
51-65: LGTM! Split curl/PowerShell blocks and verification step address prior review feedback.
81-96: LGTM!crates/cli/README.md (2)
52-80: LGTM! Addresses prior MD031 blank-line and verification-wording feedback.
129-132: LGTM!docs/getting-started/installation.mdx (2)
33-49: LGTM! Addresses prior review feedback on<Tabs>usage, docs-version/CLI-version contract, and custom install-dir PATH guidance.Also applies to: 50-52, 54-58, 75-80, 96-133, 140-149, 151-166
135-138: 🗄️ Data Integrity & IntegrationRemove this warning; the Windows POSIX-shell path already uses PowerShell to persist the user
PATH.> Likely an incorrect or invalid review comment.scripts/test-install.ps1 (2)
83-84: Capture output with a fixed width.The prior CI finding still applies: both capture paths pipe to
Out-Stringwithout-Width, so long failure messages or URLs can wrap and breakAssert-Contains. As per path instructions, review automation changes for reproducibility.Also applies to: 92-92
Sources: Path instructions, Pipeline failures
1-68: LGTM!Also applies to: 97-212
install.ps1 (2)
1-112: LGTM!Also applies to: 143-199, 203-207
132-135: 🎯 Functional CorrectnessNotify Windows after updating the user
PATH.The registry write is durable, but shells launched from an already-running Explorer or terminal may not observe it until a
WM_SETTINGCHANGEbroadcast or a new logon. That makes Line 202 overpromise immediate inheritance. Add the broadcast afterSetValue, or soften the message to require restarting the session.Also applies to: 200-202
Signed-off-by: Bryan Bednarski <bbednarski@nvidia.com>
Signed-off-by: Bryan Bednarski <bbednarski@nvidia.com>
|
/merge |
4 participants
Overview
Add verified GitHub Release installation paths for the NeMo Relay CLI across every currently published Unix and Windows asset, without requiring Rust or
cargo-binstall.Details
install.ps1for Windows PowerShell 5.1 and PowerShell 7: latest orNEMO_RELAY_VERSIONselection, Windows x86_64/ARM64 detection, SHA-256 verification, atomic replacement, and idempotent user/current-process PATH updates that preserve expandable user-PATH values.install.shfor Git Bash, MSYS, Cygwin, and MINGW Windows targets while preserving the existing Unix installation flow.Validation:
sh -n install.sh,sh -n scripts/test-install.sh, andsh -n scripts/test-install-mocks.shsh scripts/test-install-mocks.sh— 8 scenarios passedhermes-agentandnemo-relayresolvednemo-relay==0.4.0;hermes plugins enable observability/nemo_relaysucceededjust docspre-commitchecks passed. The full pre-commit run passed its non-attribution hooks, but the local Python attribution generator was interrupted after prolonged network-bound metadata retrieval.Breaking changes: none.
Where should the reviewer start?
Start with
install.ps1for native Windows behavior, then review the full target matrix in.github/workflows/ci_check.ymland Fern’s installation page for the cross-platform commands, interface reference, and Hermes plugin setup.Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)
Summary by CodeRabbit