prole/docs/config-environments.md
chrisfu b905cbe584 Bootstrap env-based prole.cfg entrypoint (safe legacy migration)
- Add centralized config resolver/activator with per-environment layering and stable symlink entrypoint\n- Bootstrap missing env dirs and preserve non-symlink legacy prole.cfg by seeding into inferred env\n- Wire installer UI/backend + shell helpers to shared resolution path for explicit, safe env switching\n- Harden k3d: registry network/DNS wiring and ArgoCD repo-server hostPath permission init\n- Add docs + regression tests for env switching, namespace stability, k3d registry, and ArgoCD rollout

Co-authored-by: Junie <junie@jetbrains.com>
2026-03-13 12:23:15 -07:00

45 lines
2.1 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

### Prole configuration environments
Prole treats `$PROLE_CONF` as an explicit, switchable set of isolated environment configs.
#### Directory layout
Under `$PROLE_CONF`:
```text
$PROLE_CONF/prole.cfg -> symlink entrypoint (active env)
$PROLE_CONF/dev/prole.cfg -> base config (dev)
$PROLE_CONF/service/prole.cfg -> base config (service)
$PROLE_CONF/prod/prole.cfg -> base config (prod)
$PROLE_CONF/test/prole.cfg -> base config (test)
# Optional overrides (conf.d-style) per environment:
$PROLE_CONF/<env>/*.cfg -> applied as layered overrides
```
Existing code continues to read `.../prole.cfg` via the single stable entrypoint path: `$PROLE_CONF/prole.cfg`.
#### Activation (selecting the active environment)
- The active environment is determined by what `$PROLE_CONF/prole.cfg` points to.
- The Cluster Environment screen activates the selected env by updating the symlink (via `installer/prole_conf.py`).
- Switching environments only changes the symlink target; it does not overwrite any other environment’s curated files.
If the entrypoint is a regular file (legacy layout), activation preserves it as `prole.cfg.legacy.<timestamp>` and switches to the symlink-based layout.
#### Override layering (deterministic merge)
For a selected environment directory `$PROLE_CONF/<env>/`:
1. Load `$PROLE_CONF/<env>/prole.cfg` (base)
2. Load every other `*.cfg` file in the same directory, in lexicographic filename order
Later files override earlier values (last write wins). This makes overrides predictable and reviewable.
#### Why this prevents accidental namespace drift
- Tests can target an isolated environment (`test`) with its own base config and overrides.
- Environment switching is explicit (symlink target changes) and stable (entrypoint path stays the same).
- Updates that need to modify config write through the entrypoint symlink to the active environment’s base file, avoiding hidden cross-environment mutations.
- The `test` environment defaults to a non-`default` namespace (`prole-test`), reducing the chance that unit/integration runs revert to Kubernetes `default`.