chrisfu/prole
1
0
Fork 0
mirror of https://github.com/dredx/prole.git synced 2026-09-23 12:03:59 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
2e517686a8
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

2.1 KiB
Raw Blame History

Prole configuration environments

Prole treats $PROLE_CONF as an explicit, switchable set of isolated environment configs.

Directory layout

Under $PROLE_CONF:

$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.