rouggyandClaude Opus 5
41a2a38025
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]>
62 lines
2.4 KiB
Markdown
62 lines
2.4 KiB
Markdown
# Publishing this wiki to GitHub
|
|
|
|
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.
|
|
|
|
## 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
|
|
clones `github.com/GregTroar/OpsLog.wiki.git` to a temp folder, copies every page
|
|
from this `wiki/` folder (except this guide), and pushes only if something
|
|
changed. Auth reuses your GitHub git credential (set up by `gh auth login`).
|
|
|
|
**One-time:** on GitHub, open the repo → **Wiki** tab → *Create the first page* →
|
|
Save. This initialises the wiki repo so the script's clone succeeds.
|
|
|
|
## Manual (if you want to push between releases)
|
|
|
|
```bash
|
|
# One-time: clone the wiki repo NEXT TO the project (not inside it)
|
|
git clone https://github.com/GregTroar/OpsLog.wiki.git
|
|
|
|
# Then, to update:
|
|
cp wiki/*.md ../OpsLog.wiki/ # (skip README-PUBLISHING.md if you like)
|
|
cd ../OpsLog.wiki
|
|
git add . && git commit -m "Update wiki" && git push
|
|
```
|
|
|
|
The pages appear immediately under the repository's **Wiki** tab.
|
|
|
|
## How the pages work
|
|
|
|
- Each `.md` file is one wiki page. The **file name** becomes the page title and
|
|
URL: `Getting-Started.md` → page *Getting Started* at `.../wiki/Getting-Started`.
|
|
- **`_Sidebar.md`** renders as the navigation sidebar on every page.
|
|
- **`_Footer.md`** renders at the bottom of every page.
|
|
- Link between pages with `[[Page Name]]` (wiki-link) or a normal relative link
|
|
`[text](Getting-Started)`.
|
|
- `Home.md` is the wiki landing page.
|
|
|
|
## Keep it in sync with the README
|
|
|
|
The wiki mirrors [`README.md`](../README.md). When you add a feature, update the
|
|
matching wiki page and the README together so they don't drift.
|