Skip to content

Decide the deployment, and check what a broken commit would break - #25

Merged
onatozmenn merged 1 commit into
mainfrom
deployment-decided
Jul 31, 2026
Merged

Decide the deployment, and check what a broken commit would break#25
onatozmenn merged 1 commit into
mainfrom
deployment-decided

Conversation

@onatozmenn

Copy link
Copy Markdown
Contributor

Closes #11.

Pages serving the default branch at its root, which the repository name already arranged, and no custom domain.

Measured

The content type was the thing most likely to be quietly wrong, since streaming instantiation refuses anything that is not application/wasm:

assets/deed-v0.2.1-wasm32-unknown-unknown.wasm   application/wasm
assets/worker.js                                 application/javascript; charset=utf-8
play/                                            text/html; charset=utf-8

Caching is not ours to set. Everything comes back max-age=600, pages and artifact alike, and Pages has no per-path headers, so the artifact cannot be cached hard even though its name carries the tag and its bytes can never change. Ten minutes with an ETag is a 304 and no bytes, which is a cost worth naming and not worth a CDN.

No custom domain, as a decision

Nothing to gain: the name is already deed-lang.github.io and the certificate is already there. Something specific to lose: GitHub's own docs say a custom domain left configured while a Pages site is disabled is a domain takeover waiting to happen.

The usual argument for buying early is that moving later splits the links. That is the claim to check rather than assume, and I did not confirm it, so the decision does not lean on it either way. It is written into the record as the thing to check first if this reopens.

A broken deploy

Serving from a branch means there is no half-updated site, only a commit that is fully deployed and wrong. Nothing here fails to compile, so tools/check.mjs is what stands in the way:

  • every JSON file parses
  • every local href and src resolves against the tree
  • TAG and VERSION in assets/play.js agree, and name an artifact that is actually committed
  • examples/index.json and the files on disk are the same list, at the same tag

Node, no dependencies, matching the rest of the repository. It runs on every pull request.

Verified by pointing the landing page at a directory that does not exist:

index.html: points at playgroundd/, which is not here
2 problems.

Written with AI assistance.

Pages serving the default branch at its root, which the repository name
already arranged, and no custom domain.

The content type was the thing most likely to be quietly wrong, since
streaming instantiation refuses anything that is not application/wasm. It is
application/wasm. Measured rather than hoped.

Caching is not ours to set: everything comes back max-age=600, pages and
artifact alike, and Pages has no per-path headers. So the artifact cannot be
cached hard even though its name carries the tag and its bytes can never
change. Ten minutes with an ETag is a 304 and no bytes, which is a cost worth
naming and not worth a CDN.

No custom domain, as a decision and not a delay. Nothing to gain, and
something specific to lose: GitHub's documentation says a custom domain left
configured while a Pages site is disabled is a domain takeover waiting to
happen. The claim that moving later splits the links is the one to check
first rather than assume, so this does not lean on it.

Serving from a branch means there is no half-updated site, only a commit that
is fully deployed and wrong. Nothing here fails to compile, so tools/check.mjs
is what stands in the way: every local link resolves, every JSON file parses,
the tag and version in play.js agree and name an artifact that is committed,
and the example index matches the files on disk. Verified by pointing the
landing page at a directory that does not exist and watching it say so.

Closes #11

Co-authored-by: GitHub Copilot <copilot@github.com>
@onatozmenn
onatozmenn merged commit 62b2b9e into main Jul 31, 2026
1 check passed
@onatozmenn
onatozmenn deleted the deployment-decided branch July 31, 2026 14:06
@onatozmenn onatozmenn mentioned this pull request Jul 31, 2026
11 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Deployment, and whether there is ever a custom domain

1 participant