1# tools/deploy
2
3The steps `nix run .#deploy` (flake.nix) runs before `wrangler deploy`,
4in order.
5
6`release-check.mjs` runs inside `nix run .#deploy`, before anything is
7published. It compares the newest release note in the build
8(`release-notes.json`, from the repo's `RELEASES.md`) with the one the live
9site serves, and refuses the deploy when they are the same: every deploy
10carries a note, which the site's update prompt shows to visitors whose tab
11is on an older version.
12
13`resources.mjs` then makes the Worker's storage exist and current, on the
14deploy's temporary copy of `worker/` (the flake's `strudel.worker`: the
15Worker with its own dependencies, `nix/worker-closure.mjs`). Every D1 database and KV namespace the
16production config binds without an id is looked up by name (a KV namespace
17by the title wrangler itself would give it, `jevstrudel-<binding>`), and
18created if the account has none; its id goes into the copy's
19`wrangler.json`, never the repo's. Every R2 bucket it binds (`bucket_name`,
20a name, so nothing is written) is created if the account has none, since
21`wrangler deploy` refuses a binding to a missing bucket. Then each database's pending migrations
22(`worker/migrations/`) are applied with `d1 migrations apply --remote`, so
23the Worker published next never runs against an older schema. From a
24terminal, wrangler lists the migrations and asks before applying them.