Detect the .car layout on the host the way the runtime does

[userAugustos]

Refs CAN-334, finding 12.

The host CLI picked the .car layout by checking for the config file, while the runtime (_artifact_prefix, the global controller, the server) picks it by the presence of the .car directory. A project with a .car directory but no config in it, for example after an interrupted canyonos build, made the host read the legacy root config while the container insisted on the .car one, and deploy failed with a 400 naming a path that exists on the host.

• default_config_path() now keys on the .car directory, same as the runtime, and always returns the path so serve and status, which only read ports, keep working in a half-built project.
• New shared missing_config_message() gives one wording; config, deploy, and test use it. deploy refuses before run_init() so a project with nothing to deploy does not tear down a running one. test raises it because run_test renders failures itself and would otherwise report success under --json.

Tests: PYTHONPATH=cli:grpc_stubs:canyonos_core/controller/utils pytest tests/ -q → 283 passed, 6 failed. All 6 failures reproduce identically on origin/main: the 3 CliDeployTests patch the global os.path.isfile, which makes resolve_env_file see the platform secrets file, and the 3 InstanceManagerRuntimeTests patch a _port_bound attribute that no longer exists.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}