← All decisions

#0041 · 2026-08-09 · accepted · architecture

The project's public website (goals, devlog, live demo) lives in a separate glemy-website repo, not this one

architecturewebsitedeploymentdevops

Context

The user pointed out that glemy is meant to become a fully-fledged, genre-agnostic game engine, with the current Suika-style merge puzzler serving as a preview/proving-ground game rather than the end goal itself. They asked whether a fully-fledged public website (project goals, development logs, and a live playable demo) belongs directly in this repository, and required the decision be made from real, cross-checked online research rather than assumption -- multiple independent sources, not one.

Options considered

Host the website inside this repo (e.g. a docs/ or website/ directory, served from the same repo, same release cadence as the engine) — rejected
Cross-referenced four real, independent precedents directly (not summaries): Bevy (bevyengine/bevy-website), Godot (godotengine/godot-website, separate again from godotengine/godot-docs), the Gleam language itself (gleam-lang/website, separate from gleam-lang/gleam), and raylib (raysan5/raylib.com, separate from raysan5/raylib). All four converge on a separate repo. Reasoning behind the convergence, checked rather than assumed: release cadence mismatch (engine commits are frequent and code-focused; a website's own content/design commits are a different rhythm and would pollute the engine's git history), deployment-target mismatch (the engine repo's CI builds/tests a game engine; a website repo's CI builds/deploys a static site -- different jobs, different concerns), and repo cleanliness (a website's own asset/dependency footprint, e.g. a static-site generator's own package graph, has no reason to live inside the engine's dependency graph).
Separate glemy-website repo, built with a JS-ecosystem static site generator (Astro, Docusaurus, Hugo, etc.) — rejected
Would contradict this project's own already-established, repeatedly-applied rule of maximizing type safety and minimizing dependencies (decisions 0013/0015) for no real gain -- a JS SSG adds an entire second toolchain and dependency ecosystem this project otherwise has no need for, purely to render a handful of static pages.
Separate glemy-website repo, built with lustre_ssg (the official Gleam-native static site generator from the Lustre team), deployed to GitHub Pages via GitHub Actions, with the devlog rendered directly from this repo's own docs/decisions.jsonl at build time and the live demo embedded as this repo's own real gleam build --target javascript output — chosen
Matches this project's own standing ethos directly -- gleam.run itself, the flagship precedent, is written in Gleam. Keeps the devlog as a read-only view of the same real decision log this project already maintains rather than a second, hand-maintained blog that would inevitably drift out of sync. Keeps the live demo as this repo's actual build output (via a cross-repo CI checkout + gleam build --target javascript), not a reimplementation that could silently diverge from the real game.

Decision

Created a new, separate public repository, recregt/glemy-website (https://github.com/recregt/glemy-website), built with lustre_ssg and deployed to GitHub Pages via GitHub Actions at https://recregt.github.io/glemy-website/. It has three pages -- home (project goals), devlog (rendered from this repo's docs/decisions.jsonl, fetched fresh at build time), and play (this repo's real gleam build --target javascript output, embedded live via iframe) -- plus a shared layout/nav/footer. lustre_ssg's Hex-published 0.11.0 hard-pins jot = "4.0.0", whose code calls gleam/result.then, a function current gleam_stdlib no longer has (confirmed by reading gleam_stdlib's own result.gleam directly); lustre-labs/ssg's GitHub main branch already fixes this as an unreleased 0.12.0, so glemy-website's gleam.toml pins lustre_ssg to that exact commit SHA rather than the broken Hex release, with a note to switch back to a normal Hex constraint once 0.12.0 is published. deploy.yml checks out both repos, runs glemy-website's own gleam test, fetches docs/decisions.jsonl and builds this repo's JS target, copies both into glemy-website's static assets, then builds and deploys to Pages -- on every push to glemy-website, once daily on a schedule (so glemy changing alone still eventually republishes, since the repos are deliberately separate with no single push event covering both), and on manual dispatch.

Verification

The full pipeline was run for real in GitHub Actions (not just simulated locally first) and succeeded end-to-end on the first real run: cross-repo checkout of this repo, gleam build --target javascript, the static-asset copy, glemy-website's own gleam test, the lustre_ssg build, and the Pages deploy all passed. The live deployed site was then checked with a real headless-Chromium session (Playwright, the same technique as this repo's own tools/browser_check.ts): all four pages (/, /devlog/, /devlog/0040.html, /play/) load with zero console/page errors, and navigating directly to the embedded demo URL shows it genuinely rendering via WebGPU -- 149 real draw calls counted by instrumenting GPUCanvasContext.prototype.configure, the same real-frame-counting technique used elsewhere in this project, not just 'the page loaded.' One real bug was caught and fixed by this same live-verification step: GitHub Pages serves a project site (no custom domain) under a /glemy-website subpath rather than the domain root, so the site's root-relative links/assets (href="/style.css" etc.) all 404'd on first deploy (confirmed directly: curl showed https://recregt.github.io/style.css as 404 and the /glemy-website/ equivalent as 200). Fixed by threading a base_path through every generated URL, sourced from actions/configure-pages' own base_path output (which already resolves to empty automatically if a custom domain is ever added later) -- re-verified live afterward with zero errors on every page.

Consequences

glemy's own repository stays focused purely on the engine and its proving-ground game -- no website assets, no second dependency graph, no design-churn commits in this repo's history. The devlog has zero maintenance burden beyond writing decisions here as already practiced; it is automatically public. The live demo on the website can silently go stale for up to a day if this repo changes without a corresponding glemy-website push (accepted trade-off of the daily-schedule approach, chosen specifically to avoid requiring a cross-repo GitHub PAT/secret for an immediate cross-repo trigger). A follow-up task, not yet done, is to switch lustre_ssg back to a plain Hex version constraint once a fixed release is actually published.

References