Open lbdyck opened 11 months ago
So you'd have something like "zopen --env prod update" so only one env would need the zopen tooling (notwithstanding a user obtaining their own copy!) ? Everything the zopen-* scripts do is keyed off the ZOPEN_ROOTFS envvar so it'd be theoretically possible to manipulate that...
something like that where each env
has it's own zopen-config
and thus its own ZOPEN_ROOTFS
What if zopen install had the ability to install, and upgrade, different installation targets. For example a prod filesystem, a dev filesystem, a qa filesystem, and an all filesystem. Then a promote would process the specified filesystem. Does this make sense?