ci: pick the docs-preview toolchain from the PR checkout
Unblocks docs previews for #3073 (and any future toolchain change) by resolving the pull_request_target chicken-and-egg: this workflow file always runs from the base branch, so a hardcoded build recipe can only preview heads that share the base's toolchain — #3073's preview check is currently guaranteed-red until after it merges.
Motivation and Context
The build job checks out the PR head but runs base-branch workflow steps. Instead of hardcoding the MkDocs commands, detect the recipe from the checkout: heads that ship scripts/docs/build.sh (a complete recipe, dependency sync included — arrives with #3073) build with it; all other heads — including v1.x heads previewed via /preview-docs — keep today's MkDocs path unchanged. Same pattern as build_site() in scripts/build-docs.sh on #3073; the two copies cross-reference each other.
On main today this is a no-op: scripts/docs/build.sh doesn't exist, so every preview takes the fallback arm, which is byte-equivalent to the current step.
Also sets if-no-files-found: error on the artifact upload, so a build arm that violates the site/ output contract fails loudly in build instead of as a confusing artifact-download error in deploy.
Security posture is unchanged: the build job already executes head-controlled Python (mkdocstrings imports src/mcp, !!python/name: config directives), is admin-gated by authorize, and never shares a runner with the Cloudflare token. The header comment now spells out the head-supplied-script vector explicitly.
How Has This Been Tested?
The fallback arm is the existing command relocated (verified by inspection; it's what every preview on main runs today). The build.sh arm is exercised by #3073's preview run once this merges — that run is the end-to-end verification, and #3073's own CI builds the same script from its branch.
Breaking Changes
None.
Types of changes
- Bug fix (non-breaking change which fixes an issue)
- New feature (non-breaking change which adds functionality)
- Breaking change (fix or feature that would cause existing functionality to change)
- Documentation update
Checklist
- I have read the MCP Documentation
- My code follows the repository's style guidelines
- New and existing tests pass locally
Additional context
Merge order: this first, then #3073 — its preview goes green on the next push to that branch afterwards.