ci: cut a docs version on release, only when the docs changed - #821
Merged
Merged
Conversation
Docusaurus versioning here is a manual commit and it has drifted: 8.0.0, 8.2.0 and 8.3.0 were cut while 8.1.0 and every patch release were not, so anyone reading the docs for a released version can be reading a snapshot several releases stale. Cuts a version if, and only if, website/docs differs from the most recent snapshot. The version number decides nothing: a patch release that changed documentation gets a snapshot, and a major that changed none does not, because a snapshot identical to the one before it is noise in the version picker. The comparison is against the previous snapshot directory rather than the previous release's tag, and the distinction matters. The 8.3.0 snapshot was committed in 0335865, which also carried doc edits, after v8.3.0 was tagged; diffing against the tag reports three files as changed that the snapshot already contains. The snapshot is what readers see, so the snapshot is what to compare against. Opens a pull request rather than pushing to master. A cut is ~41 files and 6,000 lines, which deserves review, and a PR avoids both the protected-branch question and re-triggering the deploy workflow. The release tag and the dispatch input reach the shell through env rather than expression interpolation, so a tag carrying shell syntax is data rather than script.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #821 +/- ##
============================================
- Coverage 95.72% 91.72% -4.01%
- Complexity 1773 2025 +252
============================================
Files 154 198 +44
Lines 4586 5436 +850
============================================
+ Hits 4390 4986 +596
- Misses 196 450 +254 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
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.
Cuts a Docusaurus docs version on release, but only when the documentation actually changed.
Why
Versioning is a manual
docusaurus docs:versioncommit today, and it has drifted:troubleshooting.mdby 39 linesversions.jsoncurrently stops at 8.3.0 while 8.3.1 is released, so a reader on the 8.3.x docs isreading a snapshot that predates the fixes shipped in 8.3.1.
The rule
Cut a version if, and only if,
website/docsdiffers from the most recent snapshot.The version number decides nothing. A patch release that changed documentation gets a snapshot, and
a major release that changed none does not, because a snapshot identical to the one before it is
just noise in the version picker. That is the whole policy; the other two guards are safety rather
than policy:
versions.jsonis skipped, so re-running is harmlessX.Y.Zis skipped, which keeps prereleases out of the pickerComparing against the snapshot, not the tag
The diff is taken against
website/versioned_docs/version-<previous>/rather than against theprevious release's git tag, and the distinction is load-bearing.
The 8.3.0 snapshot was committed in 0335865, which also carried documentation edits, after v8.3.0
had already been tagged. Diffing
website/docsagainst the tag therefore reports 7 changedfiles; diffing against the snapshot reports 4. The three-file difference is content the snapshot
already contains. Since the snapshot is what readers actually see, the snapshot is the correct
baseline, and it does not depend on tags existing or on when they were placed.
Output
The run opens a pull request rather than pushing to
master. A cut is roughly 41 files and 6,000lines, which is worth a human glance, and a PR avoids both the protected-branch question and
re-triggering
doc_generation.ymlfrom a push the workflow itself made.add-pathsrestricts thecommit to
versions.json,versioned_docs/andversioned_sidebars/.The site is built from the generated snapshot before the PR is opened, so a snapshot that does not
compile fails the run instead of landing.
Testing
Verified locally against this repository:
docusaurus docs:version 8.4.0produces 41 doc files,version-8.4.0-sidebars.jsonand theversions.jsonentry, and touches nothing outside the three allowlisted pathsagainst the real 8.3.0 snapshot for both the changed and unchanged cases
workflow_dispatchis available to cut a version by hand, withforceto snapshot even when thedocs are unchanged.
Note on inputs
The release tag and the dispatch input reach the shell through
env:rather than${{ }}interpolation, so a tag containing shell syntax is data rather than script. The
X.Y.Zcheck runsbefore the value is used for anything.