wild-cloud/wild-pc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(core): single-source data_dir/repos_dir via castle.yaml

Browse Source 
The `castle` CLI and the `castle-api` service are two independent in-process
drivers of `castle_core`. Each resolved DATA_DIR/REPOS_DIR at import time from
its own process env (default /data/castle), persisted nowhere — so they silently
diverged, and `apply`/dashboard-apply crashed on a non-existent /data.

Make the loaded CastleConfig the single source of truth:
- Resolve data_dir/repos_dir only in load_config (env > castle.yaml > default),
  anchored to the config root; drop the DATA_DIR/REPOS_DIR module globals and the
  import-time file read entirely — no global twin that can disagree with the file.
- Thread config.data_dir/repos_dir through ensure_dirs, _env_context, tls_dir_for
  (now unified — deploy no longer inlines the tls path), and create/add/clone.
- ensure_dirs raises an actionable CastleDirError instead of a bare PermissionError;
  the api surfaces it as 422.
- doctor: "data dir writable" check + WARN when CASTLE_DATA_DIR/REPOS_DIR env
  overrides the file (the one remaining cross-process divergence vector).
- install.sh persists data_dir/repos_dir into castle.yaml (idempotent, non-default).
- Docs: registry.md globals + AGENTS.md roots.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Paul Payne
2026-07-06 23:02:33 -07:00
parent b28645f2f4
commit 340f469b3d
16 changed files with 417 additions and 88 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
docs/registry.md
View File

@@ -59,8 +59,29 @@ The core `castle.yaml` contains configuration settings that apply globally to yo
gateway:
port: 9000
repo: /data/repos/castle
data_dir: /data/castle # optional — where program/service data lives
repos_dir: /data/repos # optional — default home for new program source repos
```
**`data_dir` / `repos_dir` — the configurable roots.** Both are optional and omitted
by default (the built-ins `/data/castle` and `/data/repos` apply). Each resolves with
precedence **env var > `castle.yaml` > built-in default**:
| root | env override | castle.yaml key | default |
|------|--------------|-----------------|---------|
| program data (`${data_dir}` base) | `CASTLE_DATA_DIR` | `data_dir:` | `/data/castle` |
| new-repo home (`castle create`/`add`/`clone`) | `CASTLE_REPOS_DIR` | `repos_dir:` | `/data/repos` |
Put the value in `castle.yaml`, not an env var. The `castle` CLI and the `castle-api`
service each resolve config independently in their own process; a per-shell env var is
seen by only one of them, so the two silently diverge (and `apply` crashes if the
resolved dir — e.g. a non-existent `/data/castle` — can't be created). Persisting the
choice in `castle.yaml` is the single source of truth both read. `install.sh` writes
these keys when you install with `CASTLE_DATA_DIR`/`CASTLE_REPOS_DIR` set; `castle
doctor` flags a data dir that isn't writable, or an env var that's overriding the file.
(`CASTLE_HOME`, the dir that *contains* castle.yaml, stays env-or-default `~/.castle` —
it can't be defined inside the file it locates.)
### Resource Configuration Files (`programs/`, `deployments/`)
Each resource (a program or a deployment) is configured in its own YAML file named after the resource's unique ID (e.g., `deployments/my-service.yaml` defines the deployment `my-service`).