X-ORG-2491: Publish API docs to docs.nvidia.com - #2492
Conversation
josephine-wolf-oberholtzer
added
doc
josephine-wolf-oberholtzer
added
improvement
|
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:
📝 WalkthroughWalkthroughAdds branch-gated ChangesAPI documentation publishing
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related issues
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
d938c89 to
4af8f56
Compare
|
/ok to test |
gforsyth
left a comment
gforsyth
left a comment
There was a problem hiding this comment.
This looks good -- few small questions that are more about process and less about implementation.
Is the plan to merge this in while it's still pointing at your branch on shared-workflows or will that stabilize before this goes in?
| akamai-emails-to-notify: joberholtzer@nvidia.com | ||
| docs-projects: rmm,librmm | ||
| dry-run: false | ||
| version-map: '{"26.08": "legacy", "26.10": "stable"}' |
There was a problem hiding this comment.
26.08 isn't released yet -- is this indicative of when we expect these docs to go live in their new home?
There was a problem hiding this comment.
Yes, exactly. The docs are slated for going live on docs.nvidia.com at/just after the upcoming release.
There was a problem hiding this comment.
At that point, 26.08 would be stable and 26.10 would be nightly. (legacy is 26.06 after the 26.08 release.) Do we need to make a change here?
There was a problem hiding this comment.
Probably just misunderstanding on my end!
I'm updating the map like so: {"26.06": "legacy", "26.08": "stable"}
So, in this moment:
mainhas version26.10in itsVERSIONfile, but26.10is no longer in the map, so merges tomainget published to/rmm/26.10/,/rmm/latest/and/rmm/nightly/26.08is in the map asstable, so merges to therelease/26.08branch should get published to/rmm/26.08/and/rmm/stable/26.06is also in the map, but nobody's pushing torelease/26.06anymore, so it's unlikely we'll see any26.06docs show up on docs.nvidia.com unless you go out of your way to do it
Lemme know if I'm on the right track here.
There was a problem hiding this comment.
This is really close. That will be the correct state after the 26.08 release -- with the one caveat that we won't publish /rmm/latest/.
The current state (2026-07-28) is that the 26.08 burndown process has begun (and we've hit code freeze for some libraries), but the 26.08 release hasn't happened yet. When burndown begins, we open release/26.08 and update main to 26.10. The current mapping should be:
| branch | endpoints |
|---|---|
main |
/rmm/26.10/ and /rmm/nightly/ |
release/26.08 |
/rmm/26.08/ (no special tag 😢) |
release/26.06 |
/rmm/26.06/ and /rmm/stable/ |
release/26.04 |
/rmm/26.04/ and /rmm/legacy/ |
After the 26.08 release happens, it should be basically what you wrote above:
| branch | endpoints |
|---|---|
main |
/rmm/26.10/ and /rmm/nightly/ |
release/26.08 |
/rmm/26.08/ and /rmm/stable/ |
release/26.06 |
/rmm/26.06/ and /rmm/legacy/ |
But don't worry about 26.06 or earlier for docs.nvidia.com, as you're saying -- we don't need to publish retroactively (at least not right now).
There was a problem hiding this comment.
OK, will adjust the mapping to {"26.04": "legacy", "26.06": "stable"}.
|
@gforsyth re: your top-level review question, once I verify this works end-to-end in this PR with my shared-workflows branch, I'll finalize both the shared-actions and shared-workflows changes and merge them to their respective mains, then update the branch reference here to point to shared-workflows@main. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
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 (2)
.github/workflows/pr.yaml (2)
24-24: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick winDo not make
pr-builderdepend on the conditional publishing job.When
docs-buildis skipped becausebuild_docsis false (Line 327),publish-api-docsis also skipped, and GitHub Actions consequently skipspr-builderbecause of this newneedsdependency. This prevents normal PR validation whenever documentation files are unchanged.Remove
publish-api-docsfrompr-builder.needs; retain the dependency chain only for the publishing job.Also applies to: 334-355
🤖 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 @.github/workflows/pr.yaml at line 24, Remove publish-api-docs from the needs list for pr-builder in the workflow, while preserving its dependency chain for the publishing job. Ensure pr-builder runs normally when conditional documentation jobs are skipped.
335-355: 🔒 Security & Privacy | 🟠 Major | ⚡ Quick winRestrict non-dry-run publishing to a trusted target.
github.ref_type == 'branch'permits publication from every branch, whiledry-run: falseand the26.10→stablemapping target the live documentation bucket. A same-repository feature branch could therefore overwrite stable docs. Use a dedicated test bucket/environment for integration, or gate this job to an explicitly trusted branch with deployment approval.🤖 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 @.github/workflows/pr.yaml around lines 335 - 355, Restrict the non-dry-run publish job guarded by github.ref_type and using publish-api-docs.yaml to an explicitly trusted branch or deployment-approved environment instead of allowing every branch. Preserve the existing stable version mapping only for the trusted production target; use a dedicated test bucket/environment for integration branches if they must continue publishing.
🤖 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 @.github/workflows/pr.yaml:
- Line 24: Remove publish-api-docs from the needs list for pr-builder in the
workflow, while preserving its dependency chain for the publishing job. Ensure
pr-builder runs normally when conditional documentation jobs are skipped.
- Around line 335-355: Restrict the non-dry-run publish job guarded by
github.ref_type and using publish-api-docs.yaml to an explicitly trusted branch
or deployment-approved environment instead of allowing every branch. Preserve
the existing stable version mapping only for the trusted production target; use
a dedicated test bucket/environment for integration branches if they must
continue publishing.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 8f66eb06-b5ce-4d6d-91f2-51568012a666
📒 Files selected for processing (1)
.github/workflows/pr.yaml
gforsyth
left a comment
gforsyth
left a comment
There was a problem hiding this comment.
Leaving an approval here for when this gets unblocked.
We should see that the shared-workflows branch is pointed at main.
Thanks for all the work on this @josephine-wolf-oberholtzer !
6337691 to
d96388d
Compare
e7dc034 to
4ea0400
Compare
|
/merge |
3 participants
Description
Contributes to #2491
As part of publishing API docs to docs.nvidia.com, we need to integrate a new shared workflow into the build workflow.
This integration will take the docs publish by the docs-build job and push them to the docs.nvidia.com S3 bucket. It does not automatically make those docs go live - that needs to be handled out-of-band by the docs team themselves.
N.B. This does not replace publishing docs to docs.rapidsai.org. This is in addition to.
XREF: rapidsai/shared-workflows#596
Checklist