Repository navigation
[main] Support release-line docs publishing and release coordination - #1972
jeffhandley wants to merge 2 commits into
Conversation
Validate and pin selected documentation sources while keeping runtime orchestration on main. Add regression coverage and update release-process guidance, including coordinated verification and ApiDiff tooling. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
tarekgh
left a comment
tarekgh
left a comment
There was a problem hiding this comment.
Two issues found in the docs orchestration and regression tests.
| git fetch --tags --prune origin "+refs/heads/*:refs/remotes/origin/*" | ||
| # Resolve and validate every selected content ref once, before building any version. | ||
| # Use a file rather than process substitution so resolution failures stop the run. | ||
| node "$ROOT/scripts/list-versions.mjs" --source "$DOCS_SOURCE" > "$RUNNER_TEMP/docs-sources.tsv" |
There was a problem hiding this comment.
[P2] Ensure older workflow entry points execute the new main orchestration
This resolver is invoked only by this version of docs.yml. Checking out main updates files on disk, but does not replace the running workflow definition. The existing release/1.x and release/2.x workflows still call list-versions.mjs without --source, so they bypass the new selection and validation path.
I reproduced this with the actual release/2.x workflow definition and this PR's main helpers in a synthetic repository: a latest-branches dispatch with release/2.x missing exited successfully and produced v2 pages from unreleased main content instead of rejecting the missing branch. The current fixtures always execute the new workflow definition, even when simulating another triggering ref, so they miss this case.
Please ensure supported servicing/release workflow entry points invoke the current main orchestration, and add coverage using an older workflow definition.
There was a problem hiding this comment.
Good catch, and tricky. I'll explore options here, but I'm inclined to leave this as a point-in-time mismatch, since after this merges, I'll be replicating this docs infrastructure into each of the release branches too.
But it also has me wondering if there should just be a separate/dedicated (and perhaps even orphaned) branch for the docs infrastructure scripts that all release branches' infrastructure would rely on. And I could make it a protected branch.
There was a problem hiding this comment.
But it also has me wondering if there should just be a separate/dedicated (and perhaps even orphaned) branch for the docs infrastructure scripts that all release branches' infrastructure would rely on. And I could make it a protected branch.
Sounds a good idea to me.
|
@jeffhandley already have isolated PR for fixing the markdown failure #1975 |
Pin newline settings for temporary Git repositories, normalize both sides of picker comparisons, and cover CRLF input under inherited Windows newline settings. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Summary
to refresh every published major from its matching release branch.
immutable commit snapshots without falling back to main for content.
separation, failure handling, and versioned-site behavior.
branches, PR-only changes, coordinated publication, and provenance checks.
No product APIs, package versions, dependencies, or Pages deployment
protections are changed.
Validation
Docs tests use synthetic HTML fixtures; no live Pages deployment was run.
Note
This PR description was generated with GitHub Copilot.