Skip to content

Docs: describe the demo published by the Demo workflow #113

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
SandObserver merged 1 commit into from
Oct 20, 2026
Merged

Docs: describe the demo published by the Demo workflow #113

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions src/content/docs/docs/contributing/releasing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,8 @@ description: How a Stackyard version is cut, signed and published, and how the p
## Cut a release

1. Run **Release prep** in Actions with the version, such as `1.8.0`.
2. It dates the `[Unreleased]` section, bumps the version, pins the demo image, and opens a pull request.
3. Merge it. The tag builds, scans, signs and publishes the image and the release page.
2. It dates the `[Unreleased]` section, bumps the version, and opens a pull request.
3. Merge it. The tag builds, scans, signs and publishes the image and the release page. A stable tag also publishes the demo.
4. Merge the Community Applications pull request that follows.

A tag like `v1.8.0-beta.1` publishes a pre-release and leaves `latest` and the demo alone.
Expand All @@ -18,11 +18,12 @@ If a release build fails, fix `main`, delete the tag, and push it again.

- `RELEASE_APP_CLIENT_ID` and `RELEASE_APP_PRIVATE_KEY`: a GitHub App with read and write on Contents and Pull requests, installed on this repository only. The built-in token cannot trigger the release workflows. The app is also a bypass actor on the `main` ruleset, so it can push changelog entries after each merge.
- `DOCS_DEPLOY_HOOK_URL`: a Cloudflare Pages deploy hook. It rebuilds this site after a stable release. The release still succeeds without it.
- `CLOUDFLARE_API_TOKEN` and `CLOUDFLARE_ACCOUNT_ID`: a token made from the Edit Cloudflare Workers template, and its account. They publish the demo after a stable release. The release still succeeds without them.

## Demo

`DEMO_MODE=true` serves `api/demo/demo-config.json`, blocks every write, and makes no outbound requests. Widgets read their `demo.js` instead.

`api/test/demo.test.js` fails on a private address, a secret or an unknown host in the demo config.

On Render, `render.yaml` runs a pinned release image. Keep `PORT=80`.
The **Demo** workflow publishes the demo as a static copy on Cloudflare Workers. It starts the released image in demo mode, records its answers for ten minutes, and serves them from a script in each page. A version goes live only after a browser tour of its preview address matches the image. To republish, run **Demo** in Actions with a published version.
4 changes: 0 additions & 4 deletions src/content/docs/docs/troubleshooting.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -315,7 +315,3 @@ Messages shown in the admin, and what each one means.
Set the browser's page zoom back to 100% before reporting a layout bug. The admin is laid out in fixed pixels, while the dashboard scales itself from the viewport width, so at any other zoom the two disagree and spacing looks wrong. On iOS the safe-area inset is also reported in points regardless of zoom, so content can sit under the status bar.

This has produced convincing false bug reports. Check the zoom first.

### The demo site is slow to load

The public demo runs on a free tier that sleeps when idle. The first visit can take up to a minute.
Loading