Registry: Add info about SA access to different types of registries#2753
Open
ngrayluna wants to merge 18 commits into
Open
Registry: Add info about SA access to different types of registries#2753ngrayluna wants to merge 18 commits into
ngrayluna wants to merge 18 commits into
Conversation
Contributor
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
Contributor
There was a problem hiding this comment.
Pull request overview
Adds documentation clarifying how service accounts (SAs) get access to registries depending on registry visibility and team roles, and updates related cross-references within the registry access docs.
Changes:
- Adds a new “Service account access” section describing SA access behavior for Organization vs Restricted visibility registries.
- Expands the service account footnote to link readers to the new section.
- Updates the “registry role permissions” link near the “Add a user or a team” section.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Contributor
📚 Mintlify Preview Links📝 Changed (1 total)📄 Pages (1)
🤖 Generated automatically when Mintlify deployment succeeds |
Contributor
🔗 Link Checker Results✅ All links are valid! No broken links were detected. Checked against: https://wb-21fd5541-sa-registry-access.mintlify.app |
ibindlish
reviewed
Jun 12, 2026
dfinster
approved these changes
Jun 12, 2026
ibindlish
reviewed
Jun 12, 2026
## Description trivial fix for style guide for golden set For example: ## Testing - [ x] Local build succeeds without errors (`mint dev`) - [ ] Local link check succeeds without errors (`mint broken-links`) - [ ] PR tests succeed
## Description Enables Mintlify's [Twoslash](https://www.mintlify.com/docs/create/code#twoslash) on TypeScript code blocks across the Weave **guides, tutorials, concepts, and quickstarts**, so readers can hover identifiers for IDE-style type information. --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This PR updates the Serverless Training API documentation based on the latest OpenAPI specification. **Generated on**: 2026-06-15 11:33:05 UTC **OpenAPI spec source**: https://api.training.wandb.ai/openapi.json ### Changes - Synced latest OpenAPI specification from the Serverless Training API service - Updated Serverless Training API landing page with current endpoints ### Review Checklist - [ ] Verify new endpoints are correctly listed - [ ] Check that removed endpoints (if any) are intentional - [ ] Confirm all Serverless Training API links work correctly --- *This PR was automatically generated by the Serverless Training API update workflow.* Co-authored-by: johndmulhausen <5439615+johndmulhausen@users.noreply.github.com>
## Description Extends `scripts/reference-generation/weave/generate_typescript_sdk_docs.py` so the generated Weave TypeScript SDK reference docs get the same Mintlify Twoslash treatment that #2757 applied to guides, tutorials, concepts, and quickstarts. ## Related - Follow-up to #2757 ("Reference docs are intentionally excluded and will be handled in a separate PR") Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
This PR applies the `/style-guide` skill (Google Developer Style Guide +
CoreWeave conventions) to the Reports section under `models/reports`.
The run was automated; no technical content was intentionally changed.
## Files edited
- `models/reports/clone-and-export-reports.mdx`
- `models/reports/collaborate-on-reports.mdx`
- `models/reports/create-a-report.mdx`
- `models/reports/cross-project-reports.mdx`
- `models/reports/edit-a-report.mdx`
- `models/reports/embed-reports.mdx`
- `models/reports/reports-gallery.mdx`
## Recommendations for technical review
**Prerequisites**
- Report and Workspace API examples reference `wr` without showing or
linking the import (e.g., `import wandb_workspaces.reports.v2 as wr`) —
confirm whether to add or link this prerequisite
(`clone-and-export-reports.mdx`).
- `PROJECT` and `ENTITY` placeholders are introduced inline; consider
linking to the entities/projects concept pages, and note CoreWeave
convention prefers `[ALL-CAPS-HYPHENATED]` placeholders — converting
requires touching code samples (`clone-and-export-reports.mdx`).
- `create-a-report.mdx` (API tab) has no prerequisites section; consider
whether to require an authenticated W&B environment, a supported Python
version, or a `wandb login` step.
- `collaborate-on-reports.mdx` lists no prerequisites (team/project/org
membership, role or permission level required to share, edit, comment,
or star) — consider adding one.
- `embed-reports.mdx` lacks a brief prerequisites section (e.g., a
published report URL or specific sharing permissions).
- `cross-project-reports.mdx` does not define "run set" or link to run
set documentation, references "private/team/public/open project" without
linking project-visibility docs, and uses "magic link" and "view-only
link" interchangeably without defining them together.
**Verification steps**
- Neither flow in `clone-and-export-reports.mdx` (UI export, UI clone,
API clone) has a "you should see..." statement after the procedure.
- `collaborate-on-reports.mdx`: after **Save to report**, the doc does
not describe how a reader confirms changes were saved (status indicator,
draft location if not published); and after **Invite** or sharing link,
no way to verify the recipient has access or to revoke it.
- `create-a-report.mdx` (Report tab) ends at "Click **Create report**"
without describing the resulting screen; the W&B App tab step 4 outcome
("A draft report is saved automatically") could cross-link to the
publish/edit workflow.
- `cross-project-reports.mdx`: no way to confirm a cross-project pull
worked (e.g., expected run set table state), and no way to confirm a
view-only link works or to revoke/rotate the secret token.
- `edit-a-report.mdx`: **Visualize relationships across multiple
dimensions** ends without a screenshot, sample output, or rendered
example.
- `embed-reports.mdx`: the HTML `iframe` procedure does not describe
what the embedded report should look like once pasted.
**Technical accuracy**
- `clone-and-export-reports.mdx`: confirm the **action menu > Download >
PDF/LaTeX** click path is current; confirm
`wr.Report.from_url(report.url)` is still the recommended clone-via-API
workflow; the top-level `<Note>` about Public Preview applies only to
the API tab and may need to be scoped.
- `collaborate-on-reports.mdx`: the "edit conflict" warning is mentioned
but the resolution UI and user options aren't described; confirm the
**Invite** and **Share** button labels still match the current UI;
consider whether full-screen panel URL-sharing belongs under "Share a
report" or in a panels/embedding section.
- `create-a-report.mdx`: confirm whether `Report` should be styled as a
class name (`Report` class) or remain prose (line 53); confirm "select
the **Filter run sets** option" sufficiently conveys reversibility after
the redundant toggle phrasing was removed.
- `cross-project-reports.mdx`: the statement that history data on time
series lines is supported but summary metrics across projects aren't
could use a concrete example or workaround link; the "add a tag and move
runs" workaround has no link to instructions for moving runs between
projects.
- `edit-a-report.mdx`: step 2 in **Visualize relationships across
multiple dimensions** ("Highlight key trends. Hover over a specific
group of runs to highlight them in the visualization") reads more like a
tip than a sequential step; the audit pass changed `` `run sets` `` to
`` `runsets` `` (line 99) to match the `runsets=` parameter — confirm;
the audit pass unified the Tabs title to `App UI` across all Tabs
sections (previously two used "W&B App") — confirm which label is
canonical.
- `embed-reports.mdx`: verify only fully public reports embed correctly
versus reports shared via magic links or team visibility (line 16);
reconcile Confluence guidance — prose says "insert the direct link...
within an `iframe` cell," but the HTML section instructs copying a full
`<iframe>` embed code (line 25); verify Confluence has a built-in
`iframe` macro versus requiring an add-on (line 25); confirm Notion's
`Embed` block accepts the full embed code, not just a report URL (line
33); verify the Gradio f-string `<iframe>` (no closing tag) renders
correctly in `gr.HTML` (line 48); confirm the **Share** button is still
in the upper right of a report (line 13).
- `reports-gallery.mdx`: verify external link liveness — all example
report links point to public `wandb.ai/stacey/...` URLs plus a
`bit.ly/wandb-learning-dexterity` shortlink, which can rot.
**Missing content**
- `clone-and-export-reports.mdx`: no troubleshooting guidance for failed
exports or clones (e.g., team permissions when cloning).
- `collaborate-on-reports.mdx`: no coverage of how to stop sharing,
remove a collaborator, or change permissions; who can see comments,
whether comments support mentions/notifications, or how to
resolve/delete them; whether starred reports are visible only to the
current user or to the team (the closing sentence implies the latter);
and no links to related concepts (Reports overview, project/team
permissions, panels).
- `create-a-report.mdx` (API tab): no `wandb.login()` or authentication
step is shown before `report.save()` — confirm whether intentional.
- `cross-project-reports.mdx`: no procedure for generating or toggling a
view-only link in the UI (only what view-only mode is); no mention of
where in the UI to find the project selector beyond "in the run set
table"; no guidance on choosing a destination report for **Add to
report** (new vs. existing).
- `edit-a-report.mdx`: introduction lists no prerequisites beyond the
`pip install` Note; the **Group runs by config values** code example
(lines 250–264) has uneven indentation in the `report.blocks` literal.
- `embed-reports.mdx`: the Gradio example URL is hardcoded to
`_scott/pytorch-sweeps-demo/...` (an individual user's report) —
consider a placeholder or a canonical W&B-owned sample.
- `reports-gallery.mdx`: intro doesn't explicitly name the audience
(first-time authors vs. experienced users looking for templates); the
**Notes** section bundles two distinct example patterns under one H2 —
consider splitting; all three H2 headings use a `Label: action` colon
pattern unusual for the style guide — consider refactoring as H2 label +
H3 subtitle or dropping the labels.
## How to review
- Each file's changes are style edits only. Compare side-by-side and
flag any that change technical meaning.
- Approve and merge to accept the edits, or close to reject them.
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Summary Documents the customizable `agent_name` setting and `WEAVE_AGENT_NAME` environment variable added in [wandb/weave-claude-code#89](wandb/weave-claude-code#89). This lets users rename the top-level agent shown in Weave's Agents view instead of the hardcoded `claude-code` default. Changes to `weave/guides/integrations/agents/claude-code-harness.mdx`: - **Configure the plugin**: add a `config set agent_name` example, a `WEAVE_AGENT_NAME` env var export, and a short explanation (default `claude-code`, can't be empty, whitespace trimmed). - **Trace tree**: note that the root `invoke_agent claude-code` span uses the configurable top-level agent name, and that subagents keep their own type names. - **Weave skills**: add `agent_name` to the `/weave:weave-config set` examples. ## Notes - Edits target the harness doc, which tracks the current `weave-claude-code` CLI (matching the PR repo's naming, the Agents view, and the `invoke_agent` span names). - The older `weave/guides/integrations/claude_code.mdx` page documents a differently-named `weave-claude-plugin` incarnation and was left untouched. Worth a follow-up if that page is still meant to be current. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
Author
|
@ibindlish Hopefully this does the trick? |
ibindlish
reviewed
Jun 23, 2026
ibindlish
left a comment
ibindlish
left a comment
Contributor
There was a problem hiding this comment.
almost there i think! thanks for your patience
|
|
||
| <Note> | ||
| Your [role in a team](/platform/app/settings-page/teams/#team-roles-and-permissions) has no impact or relationship to your role in any registry. | ||
| Your [role in a team](/platform/app/settings-page/teams/#team-roles-and-permissions) does not automatically assign the same role in every registry. For a registry owned by a team, however, W&B considers your role in that team when it calculates your effective registry role. |
Contributor
There was a problem hiding this comment.
couple of things to note here:
- what does it mean for a team to own a registry?
- we don't consider the user's role in the team while resolving registry access. we just consider the role of the team in the registry + the user's role
|
|
||
| If a higher role comes from the organization or owning team instead of the registry role dropdown, the user inherits that higher role. For example: | ||
|
|
||
| - A team **Admin** or organization **Admin** with the **Viewer** role in a particular registry owned by the team is effectively an **Admin** of the registry. |
Contributor
There was a problem hiding this comment.
i acknowledge this isn't a part of your changes, but not sure what it means for a team to own a registry
Comment on lines
+140
to
+142
| - Their organization role. | ||
| - Their assigned role in the registry. | ||
| - Their role in the team that owns the registry. |
Contributor
There was a problem hiding this comment.
Suggested change
| - Their organization role. | |
| - Their assigned role in the registry. | |
| - Their role in the team that owns the registry. | |
| - The default registry role for the organization, if it is not a restricted registry. | |
| - Their assigned role in the registry. | |
| - The role(s) assigned in the registry to any team(s) they are a part of. |
Contributor
There was a problem hiding this comment.
I don't think we need to mention what individual role gets assigned to a user when they're added to a registry when explaining what their effective registry role is. wdyt?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Add info about SA access to different types of registries.
Related issues
https://coreweave.atlassian.net/browse/DOCS-2549