Dry-running Core v0.1.4-rc1 against an existing environment

[Donifez]

We run an on-prem lab from the shared environment on Core v0.1.3. Our last successful deployment used this retained overlay:

~/.hybridops/envs/shared/config/blueprints/onprem-authoritative-foundation.yml

It also has saved module state and run records under the same runtime root.

hyops update check now reports v0.1.4-rc1.

Before replacing the v0.1.3 installation, we need to know whether the existing overlay still loads and plans with the prerelease. This check must not deploy or change provider resources.

[jeleel-muibi]

Confirm how the environment is selected and whether the deployment uses the retained file with --file or a shipped blueprint with --ref. The upgrade check needs to exercise the same input that the next deployment will use.

[Donifez]

After installing v0.1.4-rc1 over the active Core application, can preflight inspect our existing shared environment without reconciling resources?

[jeleel-muibi]

Yes. Run preflight against the same shared environment and --file overlay before deploy. Preflight resolves credentials, saved state, module contracts, and driver checks. Depending on the driver, it can read live provider state, but it does not deploy resources. Stop at preflight if a required check fails. Do not carry an old environment across a release boundary with --skip-preflight.

[Donifez]

We will assess v0.1.4-rc1 in this order:

1. Keep the verified v0.1.3 archive and checksum, along with copies of the current overlay and plan output.
2. Use an isolated v0.1.4-rc1 installation to validate and plan the copied overlay.
3. Install v0.1.4-rc1 without running setup-all.
4. Run preflight against the existing shared environment using the retained overlay.
5. Deploy only after the preflight result is clean and any reported changes are understood.

This keeps the initial release check isolated and ensures that installation and preflight do not become an unintended deployment.

[jeleel-muibi]

Correct. Reinstalling the verified v0.1.3 package restores the prior Core application if the prerelease needs to be rolled back before deployment. The runtime root remains in place. An application rollback cannot undo provider changes made after a deployment. That is why the sequence ends at preflight until its result is reviewed.