ci: publish Python plugin wheel

[willkill07]

Overview

Make the nemo-relay-plugin Python wheel an explicit release artifact so tag releases publish it to PyPI alongside nemo-relay.

• I confirm this contribution is my own work, or I have the right to submit it under this project's license.
• I searched existing issues and open pull requests, and this does not duplicate existing work.

Details

• Rename the plugin wheel artifact to plugin-wheel so it is not hidden by the general platform-wheel glob.
• Download the plugin wheel explicitly in the top-level PyPI publish job.
• Include the plugin wheel in the mirrored GitLab Artifactory collection.
• Document nemo-relay-plugin as a published PyPI surface.

Where should the reviewer start?

Start with .github/workflows/ci.yaml, where the release job explicitly downloads the plugin wheel before invoking trusted PyPI publishing.

Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)

• Relates to: none

Summary by CodeRabbit

• New Features

  • PyPI releases now include the plugin package alongside the main package.
  • CI release steps now collect and publish both wheel artifacts together.

• Documentation

  • Updated release docs to reflect the expanded Python packaging and publishing flow.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: bfd63c04-34c2-4c3b-9efb-2f757be1798c

📥 Commits

Reviewing files that changed from the base of the PR and between 8dfa2fe and 3143ff2.

📒 Files selected for processing (4)

• .github/workflows/ci.yaml
• .github/workflows/ci_python.yml
• .gitlab-ci.yml
• RELEASING.md

📜 Recent review details

⏰ Context from checks skipped due to timeout. (1)

• GitHub Check: Check / Run

🧰 Additional context used

📓 Path-based instructions (16)

.gitlab-ci.yml

📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)

Ensure GitLab CI references the same package names, install commands, and example commands as local workflows and documented usage.

Files:

• .gitlab-ci.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:

• .gitlab-ci.yml
• .github/workflows/ci_python.yml
• .github/workflows/ci.yaml

.github/workflows/*.{yml,yaml}

📄 CodeRabbit inference engine (.agents/skills/maintain-ci/SKILL.md)

.github/workflows/*.{yml,yaml}: In GitHub Actions workflow files, put a permissions: block on each job that needs token access.
In GitHub Actions workflow files, avoid workflow-level permissions: 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 generic actions/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 uses workflow_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 with v.
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.
Use contents: read as the default minimum permission for checkout-based build, test, docs, and packaging jobs.
Use pull-requests: read for jobs that look up PR metadata.
Limit pages: write and id-token: write to 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.
Prefer astral-sh/setup-uv cache support with cache-dependency-glob anchored to uv.lock.
Prefer Swatinem/rust-cache with explicit shared-key and workspaces instead...

Files:

• .github/workflows/ci_python.yml
• .github/workflows/ci.yaml

.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_python.yml
• .github/workflows/ci.yaml

.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_python.yml

**/*.{md,rst,html,txt}

📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-brand-terminology.md)

**/*.{md,rst,html,txt}: Always spell NVIDIA in all caps. Do not use Nvidia, nvidia, nVidia, nVIDIA, or NV.
Use an NVIDIA before a noun because the name starts with an 'en' sound.
Do not add a registered trademark symbol after NVIDIA when 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 with NVIDIA on 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 with s, not an apostrophe, such as GPUs.
In headings, common acronyms can remain abbreviated. Spell out the term in the first or second sentence of the body.
Common terms such as CPU, GPU, PC, API, and UI usually do not need to be spelled out for developer audiences.

Files:

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

• RELEASING.md

**/*.{md,rst,txt}

📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)

Spell NVIDIA in all caps. Do not use Nvidia, nvidia, or NV.

Files:

• RELEASING.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.
Use can for possibility and reserve may for permission.
Use after for temporal relationships instead of once.
Prefer refer to over see when 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:

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

• RELEASING.md

**/*

📄 CodeRabbit inference engine (AGENTS.md)

Keep SPDX headers on source, docs, scripts, and configuration files.

Files:

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

• RELEASING.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 as RELEASING.md, not in user-facing docs pages or CHANGELOG.md.
Keep stable user-facing wrappers at the scripts/ 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, and grpc-v1 protocol details on separate pages.
Dynamic plugin manifests in docs and examples should use compat.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, run just docs; ./scripts/build-docs.sh html remains 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, and grpc-v1 protocol details on separate pages.

Files:

• RELEASING.md

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

**

⚙️ 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:

1. Scope stacks decide where work belongs and which scope-local behavior is visible.
2. Middleware registries decide what guardrails and intercepts run around managed calls.
3. Plugins install reusable runtime behavior from configuration.
4. Events record runtime behavior in ATOF form.
5. 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 patterns

Prerequisites

Insta...

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

🧠 Learnings (3)

📚 Learning: 2026-04-15T18:16:52.951Z

Learnt from: bbednarski9
Repo: NVIDIA/NeMo-Flow PR: 1
File: docs/atof-event-format.md:381-381
Timestamp: 2026-04-15T18:16:52.951Z
Learning: In docs/atof-event-format.md (and when reviewing references to this format across the NeMo-Flow repo), treat `AtifExporter.events_to_steps()` as the intended public/API method name. Do not flag it as inconsistent with internal Rust symbol names (e.g., `event_to_steps` in `crates/core/src/atif.rs`)—the documentation’s public-facing naming may differ intentionally from internal implementation details.

Applied to files:

• .gitlab-ci.yml

📚 Learning: 2026-05-01T13:41:07.485Z

Learnt from: willkill07
Repo: NVIDIA/NeMo-Flow PR: 34
File: .gitlab-ci.yml:95-103
Timestamp: 2026-05-01T13:41:07.485Z
Learning: In NVIDIA/NeMo-Flow’s .gitlab-ci.yml, when listing GitHub Actions runs for a tag-triggered workflow, use `gh run list --branch "$tag"` to filter runs by the tag name. For annotated tag pushes in this repo, GitHub sets `headBranch` to the tag (e.g., `0.1.0-rc.5`), so `--branch "$tag"` returns only the tag-triggered run. Prefer this over `--commit <sha>`, which can be less precise because it may include both the tag run and a main-branch run that share the same commit SHA.

Applied to files:

• .gitlab-ci.yml

📚 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_python.yml

🔇 Additional comments (4)

.github/workflows/ci_python.yml (1)

289-295: LGTM!

.github/workflows/ci.yaml (1)

395-400: LGTM! Single-artifact-by-name download extracts directly into dist/ without a nested subdirectory, so this coexists cleanly with the pattern-based wheel-* download above.

.gitlab-ci.yml (1)

133-133: LGTM!

RELEASING.md (1)

34-34: LGTM! Docs accurately match the ci_python.yml/ci.yaml implementation.

Also applies to: 241-242, 253-255

---

Walkthrough

This PR renames the plugin SDK wheel artifact from python-plugin-wheel to plugin-wheel in the CI packaging job, adds corresponding download steps in GitHub Actions publish and GitLab CI collection jobs, and updates RELEASING.md to document the new nemo-relay-plugin package build and publish process.

Changes

Plugin wheel artifact renaming and propagation

Layer / File(s)	Summary
Rename plugin wheel artifact .github/workflows/ci_python.yml	Upload-artifact step renamed from python-plugin-wheel to plugin-wheel.
Download renamed artifact in CI pipelines .github/workflows/ci.yaml, .gitlab-ci.yml	Publish-python job downloads plugin-wheel into dist/; GitLab collect job fetches plugin-wheel into downloaded/wheels.
Update release documentation RELEASING.md	Documents nemo-relay-plugin as a published PyPI surface, adds package-python-plugin build step, and updates publish-python step to reference both wheels.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Sequence Diagram(s)

sequenceDiagram
  participant CIPython as ci_python.yml Package job
  participant CIYaml as ci.yaml publish-python job
  participant GitLabCI as .gitlab-ci.yml collect job
  participant PyPI

  CIPython->>CIPython: Upload artifact as "plugin-wheel"
  CIYaml->>CIPython: Download "plugin-wheel" into dist/
  CIYaml->>PyPI: Publish wheels from dist/
  GitLabCI->>CIPython: Download "plugin-wheel" into downloaded/wheels

Loading

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title follows Conventional Commits and accurately summarizes the CI change to publish the Python plugin wheel.
Description check	✅ Passed	The description matches the template with overview, details, review start point, and issue section, and is sufficiently complete.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

[willkill07]

/merge