How Stackyard releases are made

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, 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.

If a release build fails, fix main, delete the tag, and push it again.

Secrets

• 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 are secrets of the demo environment, which only main and release tags can use. 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.

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.