-
Notifications
You must be signed in to change notification settings - Fork 28
feat: adding podman-compose support for local development #755
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
WalkthroughAdds 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
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
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests
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. Comment |
There was a problem hiding this 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
: Newlocal 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 topodman-compose
and unify logs.Some environments don’t have
podman compose
(plugin) but do havepodman-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
📒 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.
There was a problem hiding this 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 topodman-compose
for broader compatibility.Some environments only have the legacy
podman-compose
(nopodman 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 }
I think instead of a separate command, it should modify the existing script to check whether there's |
And thank you very much for the contribution 😊 |
I could modify the logic to handle that scenario as well. |
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 |
I'd go with the solution |
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. |
I think it's good enough. Checking if they are running will be better of course 😁 |
Feature: #739
Summary by CodeRabbit
New Features
Chores