Document monorepo and multi-repo SDK reference setups - #6844
Open
mintlify[bot] wants to merge 4 commits into
Open
Document monorepo and multi-repo SDK reference setups#6844mintlify[bot] wants to merge 4 commits into
mintlify[bot] wants to merge 4 commits into
Conversation
Contributor
Author
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
Contributor
Author
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
hahnbeelee
reviewed
Aug 1, 2026
|
|
||
| The simplest setup. Generate the artifact in the same repository as your docs and point `source` at its relative path. Any workflow that already produces the artifact on push or release can commit it back to the repository, and the next docs deployment picks it up automatically. | ||
|
|
||
| This works for a monorepo that contains both the SDK source and the docs, or for a docs repository that vendors the SDK as a submodule. |
Member
There was a problem hiding this comment.
@mintlify , or for a docs repository that vendors the SDK as a submodule get rid of this part of the sentence
Contributor
Author
There was a problem hiding this comment.
Removed the submodule clause from the same-repo pattern description.
hahnbeelee
reviewed
Aug 1, 2026
Comment on lines
+133
to
+135
| **Commit the artifact to your docs repository.** In the SDK repository, run a CI job on release that generates the artifact and opens a pull request (or pushes a commit) to your docs repository with the updated file. Merging that change to your deployment branch triggers a docs deployment on its own, so no extra API call is needed. Point `source` at the committed path, the same as the single-repository setup. | ||
|
|
||
| **Host the artifact and fetch it at build time.** Upload the artifact to a stable HTTPS URL (for example, an S3 bucket, GitHub Releases asset, or Maven Central for Javadoc jars) and set `source` to that URL. Because nothing changes in your docs repository when the SDK updates, you also need to trigger a docs deployment so the new artifact is fetched. Call the [Trigger deployment](/api/update/trigger) endpoint from your SDK release pipeline after the artifact is published. See [Remote artifact limits](#use-remote-sources) for size constraints. |
Contributor
Author
There was a problem hiding this comment.
Numbered the two separate-repo SDK artifact options as an ordered list.
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
2 participants
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.
Documentation changes
Adds a "Where your SDK code lives" section to the SDK reference setup page covering monorepo and multi-repo scenarios: SDK in the same repo as docs, SDK in a separate repo with the artifact committed to docs, and SDK in a separate repo with the artifact hosted remotely (with a callout that the latter needs a Trigger deployment API call after publish).
Closes
For Reviewers
When reviewing documentation PRs, please consider:
✅ Technical accuracy
✅ Clarity and completeness
✅ User experience
Generated by Mintlify Agent.
Requested by: hahnbee@mintlify.com via Slack
Mintlify session: slack_1785613194.223009_C0A6A37P2AK
Note
Low Risk
Documentation-only change to sdk-reference-setup.mdx with no runtime or config behavior changes.
Overview
Adds Where do the docs and code live? to the SDK reference setup guide so readers can choose a workflow based on where the SDK lives relative to the docs.
For a monorepo (SDK and docs together), it describes generating the artifact in-repo, pointing
sourceat a relative path, and letting normal deploys pick up committed artifacts. For a separate SDK repo, it documents two paths: CI that commits or PRs the artifact into the docs repo (deploy on merge, no extra API), or hosting the artifact at an HTTPSsourceplus calling Trigger deployment after publish so builds fetch the new file. A Tip contrasts when to commit vs host (release cadence, size, existing publishes like Maven Javadoc).Reviewed by Cursor Bugbot for commit 04b4a59. Bugbot is set up for automated code reviews on this repo. Configure here.