ci: publish Python source distributions [release/0.6]

[willkill07]

Overview

Publish a nemo-relay source distribution to PyPI and NVIDIA Artifactory as a source-build fallback for platforms without a prebuilt wheel. Explicitly include the repository license in both source distributions and wheels so the published artifacts satisfy their License-File metadata.

• 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

• Add a package-python-sdist recipe that stamps the release version and builds a Maturin source distribution.
• Build and upload one source distribution from the Linux AMD64 Python packaging job.
• Download, validate, and publish the source distribution alongside wheels through PyPI trusted publishing.
• Collect and publish the same artifact to NVIDIA Artifactory through GitLab CI.
• Include LICENSE explicitly in both sdist and wheel contents.
• Document the new release artifact and local packaging command.

Validation:

• Built nemo_relay-0.6.0.tar.gz and confirmed it contains nemo_relay-0.6.0/LICENSE, matching License-File: LICENSE in PKG-INFO.
• Built the 0.6 wheel and confirmed it contains both LICENSE and the standard .dist-info/licenses/LICENSE entry.
• twine check passed for both the sdist and wheel.
• Targeted pre-commit hooks passed for all changed files.
• The full pre-commit run passed all code, workflow, Rust, Go, Node, and package checks; the documentation link checker encountered two external shields.io timeouts, and the existing Rust attribution generator produced unrelated md-5 drift that was restored.

Where should the reviewer start?

Start with .github/workflows/ci_python.yml for artifact creation, then .github/workflows/ci.yaml, .gitlab-ci.yml, and the Maturin configuration in pyproject.toml for publication and license inclusion.

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

• Relates to: RELAY-639

Summary by CodeRabbit

• New Features

  • Python releases now include source distribution packages alongside wheels.
  • Source distributions are published to PyPI and Artifactory.
  • Release packages now include the project license.

• Documentation

  • Updated release guidance with source distribution packaging, validation, and publishing steps.

[coderabbitai]

Walkthrough

The release pipeline now builds a Python source distribution, validates its presence, publishes it to PyPI, and mirrors it to Artifactory. Maturin also includes LICENSE in source distributions and wheels.

Changes

Python source distribution release

Layer / File(s)	Summary
Source distribution packaging justfile, pyproject.toml, RELEASING.md	Adds package-python-sdist, includes LICENSE in artifacts, and documents local validation.
GitHub Actions build and PyPI publication .github/workflows/ci_python.yml, .github/workflows/ci.yaml, RELEASING.md	Builds the source distribution on Linux AMD64, uploads it as python-sdist, validates one archive, and publishes it to PyPI with wheels.
GitLab collection and Artifactory publication .gitlab-ci.yml, RELEASING.md	Collects and validates the source distribution, stores it as a GitLab artifact, and publishes it to Artifactory with wheels.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant PackageJob
  participant PythonSdistArtifact
  participant PublishPython
  participant PyPI
  PackageJob->>PythonSdistArtifact: upload nemo_relay-*.tar.gz
  PublishPython->>PythonSdistArtifact: download python-sdist
  PublishPython->>PublishPython: validate exactly one archive
  PublishPython->>PyPI: publish wheels and source distribution

Loading

sequenceDiagram
  participant GitLabCollector
  participant GitHubArtifacts
  participant GitLabArtifacts
  participant Artifactory
  GitLabCollector->>GitHubArtifacts: download python-sdist
  GitLabCollector->>GitLabCollector: validate and collect source distribution
  GitLabCollector->>GitLabArtifacts: store source distribution
  GitLabCollector->>Artifactory: publish wheels and source distribution

Loading

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
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.
Title check	✅ Passed	The title uses the ci type, an imperative summary, valid length, and no trailing period; it accurately describes the CI publishing changes.
Description check	✅ Passed	The description includes all required sections, clear implementation details, reviewer guidance, validation results, and a valid related-issue action.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@justfile`:
- Around line 1662-1667: Update prepare_package_dir to require exactly one
nemo_relay-*.tar.gz match after maturin sdist, rejecting both zero and multiple
archives before downstream publication; alternatively, clear stale archives
before building so the existing match check can guarantee a single artifact.

In `@RELEASING.md`:
- Line 34: Update the post-release checklist in RELEASING.md to verify the
published nemo-relay source distribution in addition to the existing wheel
check, matching the PyPI artifacts listed in the published-surface table and the
behavior of the CI release checks.

🪄 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: 3ea90cf0-df1d-43c0-b42a-555d613820d6

📥 Commits

Reviewing files that changed from the base of the PR and between 0f95310 and 14a89b8.

📒 Files selected for processing (6)

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

📜 Review details

🧰 Additional context used

📓 Path-based instructions (18)

**/*.toml

📄 CodeRabbit inference engine (CONTRIBUTING.md)

Add the SPDX license header to all TOML files using the # comment form.

Files:

• pyproject.toml

pyproject.toml

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

Keep Python packaging metadata in the root pyproject.toml consistent with the package’s published name, imports, and build behavior.

Files:

• pyproject.toml

**/*

📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)

**/*: Format changed files with the language-native formatter before the final lint/test pass.
If dynamic plugin behavior changed, use maintain-dynamic-plugins and include the native SDK, worker protocol, Python SDK, docs, packaging, and Codecov surfaces in the validation plan.
If code changes alter APIs, bindings, commands, paths, packaging behavior, observability/adaptive semantics, or documented best practices, update any dependent maintainer or consumer skills in the same branch.
During iteration, prefer uv run pre-commit run --files <changed files...>.
Before review or handoff, run uv run pre-commit run --all-files.

Files:

• pyproject.toml
• justfile
• RELEASING.md

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

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

.github/workflows/*.{yml,yaml}: Put permissions: on each job that needs token access.
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 generic actions/cache.
Use lockfiles or dependency manifests to drive cache invalidation.
Keep deploy and publish permissions isolated to the jobs that need them.
Read both caller and callee when a workflow uses workflow_call.
Put release-tag validation in the earliest practical caller job when the pipeline has tag-based publish behavior.
Keep pure-Python plugin SDK packaging as a single wheel artifact instead of duplicating it across every platform matrix entry.
contents: read is the default minimum for checkout-based build, test, docs, and packaging jobs.
pull-requests: read is required for PR metadata lookup jobs.
pages: write and id-token: write should be limited 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; 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 of ad hoc target-directory caching.
Avoid caching generated outputs that can hide stale behavior unless the repo already relies on them deliberately.

Keep CI workflow commands and package references in GitHub Actions workflows aligned with the current install, build, and example commands.

Files:

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

{justfile,codecov.yml,codecov.yaml,.github/workflows/**/*.yml,.github/workflows/**/*.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
• justfile
• .github/workflows/ci.yaml

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

justfile

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

Keep justfile build, test, clean, version, and package recipes for plugin crates and packages aligned with the current packaging layout.

Files:

• justfile

.gitlab-ci.yml

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

Keep CI workflow commands and package references in .gitlab-ci.yml aligned with the current install, build, and example commands.

Files:

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

**/*.{md,mdx}

📄 CodeRabbit inference engine (AGENTS.md)

Update README.md, fern/, package READMEs, and binding-support notes when public behavior, package names, examples, or supported bindings change.

**/*.{md,mdx}: Prefer the documented public API, not internal shortcuts
Keep package names, repo references, and build commands current
Keep release-process and release-notes guidance in repo-maintainer docs such as RELEASING.md, not as user-facing docs pages or CHANGELOG.md
Keep stable user-facing wrappers at 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

If links in documentation change, run just docs-linkcheck.

Files:

• RELEASING.md

**/*.{md,markdown,mdx}

📄 CodeRabbit inference engine (CONTRIBUTING.md)

Add the SPDX license header to all Markdown/MDX documentation files using the HTML comment block form.

Files:

• RELEASING.md

RELEASING.md

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

Keep release-tag policy aligned with RELEASING.md: raw SemVer tags only, no leading v.

Document release tags as raw SemVer without a leading v, and keep release history and release-note links pointing to GitHub Releases rather than CHANGELOG.md or docs pages.

Files:

• RELEASING.md

**/*.{md,mdx,py,go,js,ts}

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

Examples and documentation must use each exporter's documented flush/deregister order before shutdown.

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

📚 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

🪛 zizmor (1.28.0)

.github/workflows/ci_python.yml

[warning] 404-404: code injection via template expansion (template-injection): may expand into attacker-controllable code

(template-injection)

🔇 Additional comments (5)

pyproject.toml (1)

99-99: LGTM!

RELEASING.md (1)

202-202: LGTM!

Also applies to: 248-249, 263-265, 292-293

.github/workflows/ci_python.yml (1)

398-406: LGTM!

.github/workflows/ci.yaml (1)

403-428: LGTM!

.gitlab-ci.yml (1)

71-71: LGTM!

Also applies to: 136-140, 175-175, 195-197

[github-actions]

License Diff

Compared against origin/release/0.6.

Lockfile license changes

Lockfile License Changes

Rust

Added

• None

Removed

• None

Updated/Changed

• None

Node

Added

• None

Removed

• None

Updated/Changed

• None

Python

Added

• None

Removed

• None

Updated/Changed

• None

Status output

[license-diff] selected languages: rust, node, python
[license-diff] generating current inventory
[license-diff] current: generating Rust inventory
[license-diff] current: Rust inventory complete (426 packages)
[license-diff] current: generating Node inventory
[license-diff] current: Node inventory complete (367 packages)
[license-diff] current: generating Python inventory
[license-diff] current: Python inventory complete (105 packages)
[license-diff] current inventory complete
[license-diff] checking out base ref origin/release/0.6 into a temporary worktree
[license-diff] base: generating Rust inventory
[license-diff] base: Rust inventory complete (426 packages)
[license-diff] base: generating Node inventory
[license-diff] base: Node inventory complete (367 packages)
[license-diff] base: generating Python inventory
[license-diff] base: Python inventory complete (105 packages)
[license-diff] base inventory complete
[license-diff] removing temporary base worktree
[license-diff] comparing inventories
[license-diff] rendering Markdown output
[license-diff] done

[willkill07]

/merge