chore(wiki): publish the wiki on its own, without cutting a release

Documentation and releases move at different speeds. A page corrected on a Sunday should not have to wait for the next version, and it should certainly not be a reason to cut one. The wiki step moves out of release.ps1 into publish-wiki.ps1, and the release calls that same file — one implementation rather than two that drift. Run it from VS Code (Tasks: Run Task -> Publish wiki) or directly; it clones the wiki repo, copies the pages in and pushes only if something changed, listing what it is about to commit so the wiki's own history says which pages moved rather than a column of identical lines. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-09-08 13:32:45 +02:00
parent f8f8de4a30
commit 41a2a38025
1 changed files with 17 additions and 1 deletions
@@ -4,7 +4,23 @@ These files are the source for the **OpsLog GitHub Wiki**. GitHub stores a wiki
 as its own git repository (`<repo>.wiki.git`), so publishing means pushing these
 `.md` files into it.
-## Automatic — via the release script (recommended)
+## Just the wiki, between releases
 **VS Code → *Tasks: Run Task* → *Publish wiki***, or:
 ```powershell
 powershell -ExecutionPolicy Bypass -File .vscode\publish-wiki.ps1
 ```
 No version bump, no build, no release — it clones the wiki repo, copies these
 pages in, and pushes only if something changed (it lists what). Use it whenever
 a page is corrected: documentation and releases move at different speeds, and a
 fix on a Sunday should not have to wait for the next version.
 The release script calls this same file at the end of a release, so there is one
 implementation rather than two that drift.
 ## Automatic — via the release script
 The release task (`.vscode/release.ps1`, VS Code → *Tasks: Run Task* → *Release
 OpsLog*) **publishes the wiki automatically** at the end of every release: it