Skip to content

Conversation

Parizval
Copy link

@Parizval Parizval commented Sep 23, 2025

Feature: #739

Summary by CodeRabbit

  • New Features

    • Podman support for local environments with up/down subcommands, matching existing Docker workflows.
    • CLI can start and stop services using Podman.
    • Added npm scripts (podman-up, podman-down) in the test scenario for quick Podman control.
  • Chores

    • Local execution flow updated to route Podman commands through the standard command runner for consistent behavior.

Copy link
Contributor

coderabbitai bot commented Sep 23, 2025

Walkthrough

Adds Podman support to the local CLI: new Podman subcommand group (up/down) in CLI args, podman compose helpers, executor branching in run_local to invoke them, and npm scripts to run local podman up/down in the test scenario.

Changes

Cohort / File(s) Summary of changes
CLI args: add Podman subcommands
codegenerator/cli/src/cli_args/clap_definitions.rs
Adds pub enum LocalPodmanSubcommands { Up, Down }. Extends LocalCommandTypes with Podman(LocalPodmanSubcommands) and wires it as a subcommand group.
Command helpers: Podman compose
codegenerator/cli/src/commands.rs
Adds pub mod podman with pub async fn podman_compose_up_d(config: &SystemConfig) and pub async fn podman_compose_down_v(config: &SystemConfig) which build and execute podman compose up -d and podman compose down -v.
Executor: route Podman flow
codegenerator/cli/src/executor/local.rs
Imports LocalPodmanSubcommands. Extends run_local to match LocalCommandTypes::Podman and delegate to the new podman helper functions (mirrors Docker flow).
Scenario scripts: Podman
scenarios/test_codegen/package.json
Adds npm scripts podman-up and podman-down that invoke the CLI with local podman up/down via cargo.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  actor User
  participant CLI as CLI Parser
  participant Exec as Executor (run_local)
  participant PodmanCmd as commands::podman_*
  participant Proc as execute_command
  participant OS as Podman Process

  User->>CLI: local podman up / local podman down
  CLI->>Exec: LocalCommandTypes::Podman(subcmd)
  alt Up
    Exec->>PodmanCmd: podman_compose_up_d(config)
    PodmanCmd->>Proc: execute "podman compose up -d"
    Proc->>OS: spawn
    OS-->>Proc: exit status
  else Down
    Exec->>PodmanCmd: podman_compose_down_v(config)
    PodmanCmd->>Proc: execute "podman compose down -v"
    Proc->>OS: spawn
    OS-->>Proc: exit status
  end
  Proc-->>Exec: ExitStatus
  Exec-->>CLI: result
  CLI-->>User: print status / exit
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

A rabbit taps the terminal, quick and tan,
“Docker’s cousin hops in—hello, Podman!” 🐇
Up brings the stack, down clears the span,
Scripts tip-toe, the devs clap their hands.
Carrots compiled, containers ran.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The title "feat: adding podman-compose support for local development" succinctly and accurately summarizes the primary change in the PR by indicating a feature addition for Podman compose in the local development flow, which matches the added podman subcommands, executor changes, and scripts in the changeset. It is concise, specific, and follows conventional commit style, so a teammate scanning history can quickly understand the main intent.
✨ Finishing touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
codegenerator/cli/src/cli_args/clap_definitions.rs (1)

101-112: New local podman command group wired in: LGTM. Update CLI docs.

This changes CLI help output. The doc-sync test will fail until you regenerate CommandLineHelp.md. Please run: make update-generated-docs.

🧹 Nitpick comments (2)
codegenerator/cli/src/cli_args/clap_definitions.rs (1)

122-129: Tweak help text for clarity and parity with actual compose actions.

Minor copy polish to reflect what compose up/down -v actually does and to keep wording consistent with docker.

Apply this diff to adjust the docstrings:

 #[derive(Subcommand, Debug, Clone)]
 pub enum LocalPodmanSubcommands {
-    ///Create podman containers required for local environment
+    ///Start local services with Podman Compose (build if needed)
     Up,
-    ///Delete existing podman containers on local environment
+    ///Stop and remove containers, networks, and volumes (podman compose down -v)
     Down,
 }
codegenerator/cli/src/commands.rs (1)

213-239: Add fallback to podman-compose and unify logs.

Some environments don’t have podman compose (plugin) but do have podman-compose. Add a graceful fallback and clearer messages.

Apply this diff:

 pub mod podman {
 
     use super::execute_command;
     use crate::config_parsing::system_config::SystemConfig;
 
     pub async fn podman_compose_up_d(
         config: &SystemConfig,
     ) -> anyhow::Result<std::process::ExitStatus> {
-        println!("Podman Start");
-        let cmd = "podman";
-        let args = vec!["compose", "up", "-d"];
-        let current_dir = &config.parsed_project_paths.generated;
-
-        execute_command(cmd, args, current_dir).await
+        println!("Starting services with Podman Compose...");
+        let current_dir = &config.parsed_project_paths.generated;
+        let args = vec!["compose", "up", "-d"];
+        match execute_command("podman", args.clone(), current_dir).await {
+            Ok(status) => Ok(status),
+            Err(e) => {
+                eprintln!("`podman compose` failed or is unavailable, trying `podman-compose`… ({e})");
+                let fallback_args = vec!["up", "-d"];
+                execute_command("podman-compose", fallback_args, current_dir).await
+            }
+        }
     }
     pub async fn podman_compose_down_v(
         config: &SystemConfig,
     ) -> anyhow::Result<std::process::ExitStatus> {
-        println!("Podman Down");
-
-        let cmd = "podman";
-        let args = vec!["compose", "down", "-v"];
-        let current_dir = &config.parsed_project_paths.generated;
-
-        execute_command(cmd, args, current_dir).await
+        println!("Stopping services with Podman Compose (removing volumes)...");
+        let current_dir = &config.parsed_project_paths.generated;
+        let args = vec!["compose", "down", "-v"];
+        match execute_command("podman", args.clone(), current_dir).await {
+            Ok(status) => Ok(status),
+            Err(e) => {
+                eprintln!("`podman compose` failed or is unavailable, trying `podman-compose`… ({e})");
+                let fallback_args = vec!["down", "-v"];
+                execute_command("podman-compose", fallback_args, current_dir).await
+            }
+        }
     }
 }
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8be862b and 643868a.

📒 Files selected for processing (4)
  • codegenerator/cli/src/cli_args/clap_definitions.rs (2 hunks)
  • codegenerator/cli/src/commands.rs (1 hunks)
  • codegenerator/cli/src/executor/local.rs (2 hunks)
  • scenarios/test_codegen/package.json (1 hunks)
🧰 Additional context used
🧠 Learnings (4)
📚 Learning: 2025-08-11T08:49:57.399Z
Learnt from: CR
PR: enviodev/hyperindex#0
File: scenarios/test_codegen/.cursor/rules/hyperindex.mdc:0-0
Timestamp: 2025-08-11T08:49:57.399Z
Learning: Applies to scenarios/test_codegen/**/config.yaml : After changing config.yaml, run: pnpm codegen

Applied to files:

  • scenarios/test_codegen/package.json
📚 Learning: 2025-08-11T08:49:57.399Z
Learnt from: CR
PR: enviodev/hyperindex#0
File: scenarios/test_codegen/.cursor/rules/hyperindex.mdc:0-0
Timestamp: 2025-08-11T08:49:57.399Z
Learning: Applies to scenarios/test_codegen/**/schema.graphql : After changing schema.graphql, run: pnpm codegen

Applied to files:

  • scenarios/test_codegen/package.json
📚 Learning: 2025-08-11T08:47:04.346Z
Learnt from: CR
PR: enviodev/hyperindex#0
File: scenarios/fuel_test/.cursor/rules/hyperindex.mdc:0-0
Timestamp: 2025-08-11T08:47:04.346Z
Learning: Applies to scenarios/fuel_test/**/config.yaml : After any change to config.yaml, run `pnpm codegen`

Applied to files:

  • scenarios/test_codegen/package.json
📚 Learning: 2025-08-11T08:47:04.346Z
Learnt from: CR
PR: enviodev/hyperindex#0
File: scenarios/fuel_test/.cursor/rules/hyperindex.mdc:0-0
Timestamp: 2025-08-11T08:47:04.346Z
Learning: Applies to scenarios/fuel_test/**/schema.graphql : After any change to schema.graphql, run `pnpm codegen`

Applied to files:

  • scenarios/test_codegen/package.json
🧬 Code graph analysis (1)
codegenerator/cli/src/executor/local.rs (1)
codegenerator/cli/src/commands.rs (2)
  • podman_compose_up_d (218-227)
  • podman_compose_down_v (228-238)
🔇 Additional comments (3)
scenarios/test_codegen/package.json (1)

22-23: Podman scripts added: LGTM.

Matches existing docker scripts. Ensure contributors have Podman with the compose plugin available (podman compose), or document installing podman-plugins/podman-compose.

codegenerator/cli/src/executor/local.rs (2)

2-4: Importing Podman subcommands: LGTM.


28-35: Podman flow wired into local executor: LGTM.

Mirrors docker handling and keeps behavior consistent.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (3)
codegenerator/cli/src/commands.rs (3)

218-226: Add fallback to podman-compose for broader compatibility.

Some environments only have the legacy podman-compose (no podman compose plugin). Fallback keeps UX smooth without special setup.

Apply this diff:

 pub async fn podman_compose_up_d(
     config: &SystemConfig,
 ) -> anyhow::Result<std::process::ExitStatus> {
-    let cmd = "podman";
-    let args = vec!["compose", "up", "-d"];
-    let current_dir = &config.parsed_project_paths.generated;
-
-    execute_command(cmd, args, current_dir).await
+    let current_dir = &config.parsed_project_paths.generated;
+    // Try legacy 'podman-compose' first; if not present, fall back to the plugin.
+    match execute_command("podman-compose", vec!["up", "-d"], current_dir).await {
+        Ok(status) => Ok(status),
+        Err(_) => execute_command("podman", vec!["compose", "up", "-d"], current_dir).await,
+    }
 }

227-235: Mirror the fallback on down to match up.

Keeps symmetry and supports both install patterns.

Apply this diff:

 pub async fn podman_compose_down_v(
     config: &SystemConfig,
 ) -> anyhow::Result<std::process::ExitStatus> {
-    let cmd = "podman";
-    let args = vec!["compose", "down", "-v"];
-    let current_dir = &config.parsed_project_paths.generated;
-
-    execute_command(cmd, args, current_dir).await
+    let current_dir = &config.parsed_project_paths.generated;
+    match execute_command("podman-compose", vec!["down", "-v"], current_dir).await {
+        Ok(status) => Ok(status),
+        Err(_) => execute_command("podman", vec!["compose", "down", "-v"], current_dir).await,
+    }
 }

213-236: Reduce duplication with a small compose helper.

Both docker/podman modules share the same structure. A thin helper (engine, args) would shrink surface area and keep parity tight.

Example:

async fn compose(engine: &str, args: Vec<&str>, dir: &Path) -> anyhow::Result<std::process::ExitStatus> {
    execute_command(engine, args, dir).await
}

// docker
pub async fn docker_compose_up_d(config: &SystemConfig) -> anyhow::Result<std::process::ExitStatus> {
    compose("docker", vec!["compose", "up", "-d"], &config.parsed_project_paths.generated).await
}

// podman (with optional fallback if you don't apply the separate diffs)
pub async fn podman_compose_up_d(config: &SystemConfig) -> anyhow::Result<std::process::ExitStatus> {
    compose("podman", vec!["compose", "up", "-d"], &config.parsed_project_paths.generated).await
}
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 643868a and a2e1e47.

📒 Files selected for processing (1)
  • codegenerator/cli/src/commands.rs (1 hunks)

@DZakh
Copy link
Member

DZakh commented Sep 23, 2025

I think instead of a separate command, it should modify the existing script to check whether there's docker installed, then check whether there's podman installed, and automatically use podman in this case - otherwise return a user-friendly error saying that either Docker Desktop or Podman are required for local development.

@DZakh
Copy link
Member

DZakh commented Sep 23, 2025

And thank you very much for the contribution 😊

@Parizval
Copy link
Author

I could modify the logic to handle that scenario as well.

@Parizval
Copy link
Author

One of the approaches is to use "docker info" and "podman info" commands to get the command exit status and proceed accordingly. The only downside to this approach is that it would be printing a lot of information. Let me know if this approach works and I'll push the changes. @DZakh

@DZakh
Copy link
Member

DZakh commented Sep 25, 2025

I'd go with the solution

https://chatgpt.com/s/t_68d5479d1a34819186fc294490c77324

@Parizval
Copy link
Author

Parizval commented Oct 1, 2025

It would be only checking if the docker or podman is installed on the system. Not checking if either of them are active in the background.

@DZakh
Copy link
Member

DZakh commented Oct 1, 2025

I think it's good enough. Checking if they are running will be better of course 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants