Repository navigation
feat(website): add notecraft.cloud landing page + live demo - #37
Merged
Merged
Conversation
Static landing page (koala branding, feature summary, a big "Open the live demo" button) plus a draft deploy workflow, as a website/ subfolder rather than a separate repo: Azure Static Web Apps' per-PR preview environments only fire from pull_request webhooks on the repo the Static Web App is linked to, so this is the only way contributors get an automatic live preview of their changes, and the demo can stay always-current on every merge instead of needing a manual resync. website/demo/ (the compiled wasm) is gitignored, not committed - it is a build artifact. deploy-website.yml fetches it from daijro/openplayground's "builds" release, which already rebuilds this repo's head channel continuously; the fetch step is verified against the live release, but the workflow itself has not been run and needs review before it's enabled. Nothing deployed: no Azure resource created yet, not pushed. Co-Authored-By: Claude Sonnet 5 <[email protected]>
The site previously followed the OS prefers-color-scheme setting, which the owner flagged as wrong: it should default to dark (one of the app's own themes) regardless of the visitor's OS/browser setting. Added a theme picker (two rows of seven swatches: light/dark x seven accents) backed by the exact same palette math as crates/ui-egui/src/theme.rs (mix/ensure_contrast/WCAG contrast, ported to Python to generate the CSS custom properties - see AGENTS.md for how to regenerate if theme.rs changes), so the website shows the real 14 app themes, not invented marketing colors. An inline anti-flash script sets data-theme from localStorage (default: dark-default) before first paint; theme.js builds the picker and persists the choice. The three renamed images from docs/art (badge-testing-needed.png, koala-crafting.jpg, notecraft-wordmark-bubble.png) are in website/assets/ but intentionally left out of this commit and unused in the page - still pending a decision on whether/how each fits alongside the official brand kit's style. Co-Authored-By: Claude Sonnet 5 <[email protected]>
Three images from docs/art, now actually wired into the page: badge-testing-needed.png above the demo buttons (the site and demo are both early), notecraft-wordmark-bubble.png above the feature cards, koala-crafting.png below them, before the footer. Co-Authored-By: Claude Sonnet 5 <[email protected]>
- Added Discord (the app's real community link, discord.gg/artcraft, from crates/ui-egui/src/app.rs) and Playground (the live playground.daijro.dev/head/notecraft/ deployment) to the nav. - Gave every nav link an icon: GitHub's real mark, a chat bubble for Discord, a play-circle for Playground (matching the demo button), a document icon for Docs. - Fixed a real regression the two new links caused: the nav overflowed off-screen on mobile instead of wrapping. Verified at 375px. - Added workflow_dispatch to deploy-website.yml for a manual production redeploy with no source change (e.g. to retry once openplayground's build catches up, or to refresh the demo after an app-only change). Co-Authored-By: Claude Sonnet 5 <[email protected]>
The first real run of deploy-website.yml (PR #37) showed the actual cost of the "fail loudly" design: openplayground hadn't rebuilt the pushed commit yet, so the demo-fetch step correctly errored out -- but that failed the whole job, which meant the landing page didn't deploy either, even though it has nothing to do with openplayground. The site and the demo are independent concerns and shouldn't share a single point of failure. The demo fetch is now best-effort: try the exact commit, fall back to the newest available build with a loud ::warning:: if that commit isn't ready yet, and deploy with no demo (rather than not deploying at all) if no build exists whatsoever. The site itself always deploys. Co-Authored-By: Claude Sonnet 5 <[email protected]>
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://black-bay-029f1ea10-37.centralus.4.azurestaticapps.net |
Replaces the "fetch a pre-built wasm from daijro/openplayground's release" step with a real build: apply the patch recipe to this checkout, then trunk build + wasm-opt, ourselves, in this workflow. Deploys are no longer blocked on openplayground's own ~15-minute build cycle having caught up to the pushed commit, which was the actual cause of every deploy failure so far tonight. The recipe (.github/web-build/) is adapted from openplayground's patches/onenote.yaml (SPDX MIT OR Apache-2.0, same license as this repo) - the live-collaboration rules are left out, this is a solo no-sign-in demo. apply-web-diff.py deliberately does not use `git apply`: web.diff's own @@ hunk headers are wrong for two of its six files (confirmed by counting - playground.rs claims 277 lines, is really 280; playground_clipboard.rs claims 129, is really 206), and `git apply` trusts the header and silently truncates rather than erroring. Verified locally end to end in an isolated clone: all 43 patches apply, cargo check --target wasm32-unknown-unknown passes, and a full release trunk build produces a working demo (confirmed in a browser, no console errors). Updated the footer credit accordingly: we build from an adapted recipe now, not via their live service. Co-Authored-By: Claude Sonnet 5 <[email protected]>
The rest of the new self-built pipeline worked on the first real CI run (Rust compiled, trunk build succeeded) - only wasm-opt failed: "Unknown option '--enable-bulk-memory-opt'". Ubuntu's apt-packaged binaryen is too old for that flag. Pin to binaryen's own release (version_133) instead of whatever apt happens to carry, for the same reason trunk is already pinned to an exact version: reproducibility. Co-Authored-By: Claude Sonnet 5 <[email protected]>
|
Azure Static Web Apps: Your stage site is ready! Visit it here: https://black-bay-029f1ea10-37.centralus.4.azurestaticapps.net |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
website/, not a separate repo: Azure Static Web Apps' per-PR preview environments only work when the Static Web App is linked to the same repo the PR is against, so this gets contributors a live preview automatically and keeps the demo always current on every merge.crates/ui-egui/src/theme.rs's color math, not invented marketing colors.discord.gg/artcraft, fromapp.rs) and the live OpenPlayground deployment, plus required attribution for daijro/openplayground in the footer.website/demo/(the compiled wasm) is gitignored —deploy-website.ymlfetches the matching build from daijro/openplayground'sbuildsrelease instead of rebuilding the whole patch+trunk+wasm-opt pipeline a second time here.Test plan
website/and clicked through the landing page, theme picker (all 14 swatches), and the live demo end to end — boots the real app, no console errorsdeploy-website.yml(unverified until now)AZURE_STATIC_WEB_APPS_API_TOKENsecret still needs to be set on this repo before the deploy step can succeed (blocked on Claude Code's own permission system; see PR thread)notecraft.cloudDNS TXT record still needs to be added at the registrar (GoDaddy) before the custom domain itself resolves🤖 Generated with Claude Code