Skip to content

Enable CodeRabbit auto-review on cuda-python (port CCCL's .coderabbit.yaml) #2137

@rparolin

Description

@rparolin

Summary

Enable CodeRabbit auto-review on cuda-python by adopting a config modeled on CCCL's .coderabbit.yaml (NVIDIA/cccl#8930). CodeRabbit is already installed on this repo but in opt-in mode (no .coderabbit.yaml in main; recent PRs show "Auto reviews are disabled on this repository... To trigger a single review, invoke the @coderabbitai review command").

CCCL is flipping auto-on with a config tuned to suppress the noise that caused us to keep auto-review off here. This issue proposes we port that config, adapted for cuda-python's layout and review culture.

Background: why we turned it off, and what's changed

CodeRabbit auto-review was previously disabled on cuda-python because the default profile was noisy: long walkthroughs, status/details panels, "poem" and "fortune" sections, AI-prompt blocks, finishing-touch suggestions (docstrings/unit tests/simplify), and pre-merge check comments on every PR. This made review threads hard to scan and crowded out human reviewers.

CCCL's new config (NVIDIA/cccl#8930, .coderabbit.yaml) addresses each of those failure modes explicitly. The relevant CCCL settings are below, with notes on what each one does and whether it should carry over to cuda-python unchanged.

CCCL config breakdown and cuda-python adaptation

Tone and profile (copy as-is)

profile: chill
tone_instructions: |
  Be direct, technical, brief. No praise, emojis, headings, or collapsible menus.
  Start each comment with one prefix:
  - suggestion: optional improvement;
  - important: must-fix/high-impact risk;
  - critical: blocking correctness/security/data-loss.

profile: chill is the lower-noise reviewer mode. The tone instructions constrain comment format and force a severity prefix so we can scan quickly. This is the single biggest noise-reduction lever and should copy over verbatim.

Walkthrough / status noise (copy as-is)

high_level_summary: true
high_level_summary_in_walkthrough: true
poem: false
in_progress_fortune: false
sequence_diagrams: false
estimate_code_review_effort: false
collapse_walkthrough: true
request_changes_workflow: false
review_status: false
review_details: false
enable_prompt_for_ai_agents: false

These remove the cosmetic and meta sections that drove most of the "CodeRabbit is loud" complaints. Keep all of these as CCCL has them.

Auto-review scope (adapt branch regex)

CCCL:

auto_review:
  enabled: true
  drafts: false
  base_branches:
    - "^main$"
    - "^branch/[0-9]+\\.[0-9]+\\.x$"
  ignore_usernames: ["copy-pr-bot", "dependabot[bot]", "github-actions[bot]", "nv-automation-bot"]

cuda-python adaptation:

  • enabled: true, drafts: false — copy as-is.
  • base_branches — CCCL's branch/X.Y.x pattern doesn't match our conventions. We should enumerate the active backport branches we care about (e.g. cuda-bindings 13.x, cuda-core release branches) or list the exact branch names. Proposal: start with ^main$ only, then add backport branches as they're cut.
  • ignore_usernames — CCCL's list is a strong baseline. We should confirm whether nv-automation-bot and copy-pr-bot operate on cuda-python; if not, prune. Add any cuda-python-specific bots.

Tools (copy as-is)

tools:
  gitleaks: { enabled: true }
  markdownlint: { enabled: true }
  shellcheck: { enabled: true }

All three are appropriate for cuda-python (we have markdown docs, shell scripts under ci/, and gitleaks is cheap insurance).

Finishing touches (copy as-is)

finishing_touches:
  docstrings: { enabled: false }
  unit_tests: { enabled: false }
  simplify: { enabled: false }

These are the "auto-generate docstrings/tests/refactors" features. They produce drive-by suggestions that don't fit our review process. Disable.

Pre-merge checks (copy as-is)

pre_merge_checks:
  docstrings: { mode: "off" }
  title: { mode: "off" }
  description: { mode: "off" }
  issue_assessment: { mode: "off" }
  custom_checks: []

CCCL turns all of these off to keep the PR conversation focused on code. We should do the same.

Path instructions (replace wholesale)

CCCL's path_instructions cover libcudacxx, cudax, cub, thrust, c, and python/cuda_cccl. None of these paths exist in cuda-python. We need our own set, mapped to our top-level packages:

  • cuda_bindings/**/* — focus on Cython binding correctness, ABI stability with the CUDA driver/runtime, error-code propagation, reference counting, GIL handling, NVRTC/nvJitLink coverage.
  • cuda_core/**/* — focus on Pythonic API stability (we just shipped v1.0.0), stream ordering, lifetime/ownership of CUDA resources, CUDA Array Interface compatibility, host/device memory semantics, error translation.
  • cuda_pathfinder/**/* — focus on path-resolution correctness across platforms, wheel/conda layouts, and behavior when the toolkit is missing or partial.
  • cuda_python/**/* (the meta package) — focus on packaging correctness, dependency pins, and wheel/sdist surface.
  • benchmarks/**/* — meaningful workloads, comparable axes, no excessive runtime.
  • ci/**/* — matrix correctness, GPU-vs-CPU job split, artifact handling, clear failure modes.
  • .github/**/* — permissions, event triggers, security boundaries.
  • **/*.pyx, **/*.pxd — Cython-specific concerns: typed memoryviews, GIL/nogil correctness, exception specifications, fused types.

Concrete strings can be drafted in the PR; the principle is to keep comments narrowly scoped to high-impact concerns per area and let ruff/pre-commit handle style.

Knowledge base (replace file list)

CCCL points the knowledge base at AGENTS.md, CONTRIBUTING.md, and a dozen developer/docs pages. cuda-python's equivalents:

knowledge_base:
  opt_out: false
  code_guidelines:
    filePatterns:
      - "AGENTS.md"
      - "CONTRIBUTING.md"
      - "cuda_bindings/README.md"
      - "cuda_core/README.md"
      - "cuda_pathfinder/README.md"
      - "cuda_bindings/docs/source/release_notes.rst"  # if applicable
      - "cuda_core/docs/source/release_notes.rst"      # if applicable

AGENTS.md (~270 lines) and CONTRIBUTING.md are the highest-value context. Per-package READMEs and any developer/style docs should be added based on what we have. To be filled in during PR review.

Greptile coexistence

cuda-python currently has greptile.json in the repo root, so Greptile auto-reviews PRs today. CodeRabbit auto-detects other AI reviewers and explicitly says it "will avoid duplicating their findings... this may lead to a less comprehensive review." Running both auto means each does less work.

Options to discuss in this issue:

  1. Run both auto; accept reduced coverage from each but get two independent perspectives. (Status quo + CodeRabbit on.)
  2. Keep CodeRabbit auto + Greptile manual-trigger only.
  3. Keep Greptile auto + CodeRabbit manual-trigger only (i.e. don't do this issue).
  4. Drop one. Pick a primary.

Recommendation: start with option 1 for one to two weeks, measure noise and signal overlap on real PRs, then decide whether to consolidate.

Maintainer workflow

Mirror CCCL's docs/maintainers/coderabbit.rst into our maintainer docs so the team has a single reference for:

  • @coderabbitai review / full review — manual trigger.
  • @coderabbitai pause / resume — silence during heavy iteration.
  • @coderabbitai ignore (in PR description) — opt a PR out entirely.
  • @coderabbitai configuration — inspect resolved config on a PR.

Proposed rollout

  1. Open a PR adding .coderabbit.yaml based on this proposal, with the path_instructions and knowledge_base sections filled in.
  2. Land it on main only (not backport branches yet).
  3. Watch the next ~10 PRs. If noise is acceptable, extend base_branches to active backport branches. If not, tune path_instructions or pause and revisit.
  4. Add the maintainer doc.
  5. Decide on Greptile coexistence after two weeks of data.

References

Metadata

Metadata

Assignees

Labels

featureNew feature or request
No fields configured for Initiative.

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions