You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 7adfe48
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: docs/documentation-workflows.md
+22-6Lines changed: 22 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -83,9 +83,9 @@ jobs:
83
83
84
84
The project is created on the first trusted pull request, using `main` as its production branch by default. Set `cloudflare_production_branch` if the repository uses a different default branch. Set `cloudflare_preview_domain` to publish previews at `pr-42.preview.example.com`; leave it empty to use `pr-42.stacksmith-docs.pages.dev`. Set `cloudflare_preview_zone` when the preview domain is a subdomain of the DNS zone. The API token needs Pages Write, Zone Read, and Zone DNS Edit permissions when custom preview domains are enabled. Fork pull requests receive the build artifact but are not published because repository secrets are unavailable. A separate `pull_request`-closed workflow can remove the custom hostname, its matching DNS record, and older deployments for that preview branch while preserving the shared Pages project. Cloudflare retains the latest branch deployment.
85
85
86
-
## Deploy a single documentation site to GitHub Pages
86
+
## Deploy documentation to GitHub Pages
87
87
88
-
Enable GitHub Actions as the repository's Pages source. A default-branch caller can then select production deployment. Existing callers continue to use this mode when `docs_version` is empty.
88
+
Enable GitHub Actions as the repository's Pages source. GitHub Pages deployments are versioned by default and publish the current checkout as `dev` unless the caller selects another version. The caller must grant `contents: write` so the workflow can update the versions branch.
89
89
90
90
```yaml
91
91
jobs:
@@ -96,14 +96,14 @@ jobs:
96
96
dependency_group: dev
97
97
deploy_github_pages: true
98
98
permissions:
99
-
contents: read
99
+
contents: write
100
100
pages: write
101
101
id-token: write
102
102
```
103
103
104
-
Pin the workflow to the release that matches the installed package. Pin an exact commit SHA when an immutable workflow reference is required.
104
+
This initial deployment creates `dev` and uses it as the site root when the versions branch does not already contain a root redirect. Pin the workflow to the release that matches the installed package. Pin an exact commit SHA when an immutable workflow reference is required.
105
105
106
-
## Deploy versioned documentation to GitHub Pages
106
+
## Configure versioned documentation
107
107
108
108
Versioned deployment uses the Zensical-compatible `mike` fork. The workflow keeps generated versions on a Git branch and publishes the assembled branch through GitHub Actions, so the repository's Pages source remains GitHub Actions. The fork is a transitional dependency until Zensical provides native versioning support.
109
109
@@ -118,7 +118,7 @@ default = ["latest", "dev"]
118
118
alias_type = "redirect"
119
119
```
120
120
121
-
Pass a version identifier when deploying. The caller must grant `contents: write` so the workflow can update the versions branch.
121
+
Pass a version identifier, title, aliases, and default version when publishing a release.
122
122
123
123
```yaml
124
124
jobs:
@@ -142,6 +142,22 @@ jobs:
142
142
143
143
The workflow still performs the strict `poe docs-build` check and uploads the current checkout as the normal Actions artifact. It then builds through `mike`, updates the versions branch, and gives the complete assembled site to GitHub Pages.
144
144
145
+
## Preview multiple versions locally
146
+
147
+
`poe docs-serve`builds and watches only the current checkout. It is the quickest way to review content, but its version selector has no assembled `versions.json` to load.
148
+
149
+
Install the same pinned Zensical-compatible `mike` fork used by the workflow, assemble two versions on a disposable local Git branch, and serve that branch.
uv run --no-sync mike deploy --branch local-docs --alias-type redirect --update-aliases --title Development dev
154
+
uv run --no-sync mike deploy --branch local-docs --alias-type redirect --update-aliases --title 0.12.1 0.12 latest
155
+
uv run --no-sync mike set-default --branch local-docs latest
156
+
uv run --no-sync mike serve --branch local-docs
157
+
```
158
+
159
+
Open `http://localhost:8000/`. The root redirects to `latest`, and the selector switches between `0.12` and `dev`. These commands create only local commits on `local-docs`; they do not push anything. Stop the server before removing the disposable branch with `git branch -D local-docs`.
160
+
145
161
## Publish development and release versions
146
162
147
163
Use one serialized production workflow for default-branch and tag deployment. Publish the default branch as `dev`, and publish stable tags to a major/minor documentation series. For example, `v2.4.3` updates version `2.4`, uses `2.4.3` as its display title, moves the `latest` alias, and makes `latest` the site root. Later default-branch deployments update `dev` without moving the root away from `latest`.
0 commit comments