Files
Adriano Machado e5f5fada05 feat(runtime): add Auto runtime that detects Docker then Podman (#114)
* feat(runtime): add Auto runtime that detects Docker then Podman

Previously the default runtime was always Docker, causing Podman-only
users to see "Docker is not available" warnings and fall back to
emulation. The TUI launched with no args also hardcoded Docker.

Adds RuntimeType::Auto (and --runtime auto CLI flag) which probes
Docker first, then Podman, then falls back to emulation. Auto is now
the default for all subcommands and for the no-args TUI launch.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Adriano Machado <60320+ammachado@users.noreply.github.com>

* fix(runtime): resolve Auto to concrete type before env vars and mounts

- Add `detect_runtime()` to executor crate; resolves Auto -> Docker/Podman/Emulation
  by probing availability, all other variants pass through unchanged.
- Resolve `config.runtime_type` at the top of `execute_github_workflow` and
  `execute_gitlab_pipeline` so `WRKFLW_RUNTIME_MODE` env var and
  `prepare_container_mounts` always see a concrete value, not "auto".
  Fixes broken GITHUB_ENV/GITHUB_OUTPUT remapping on the new default path.
- Replace the duplicated double-probe Auto arm in `state.rs` with a single
  `detect_runtime` call wrapped in `catch_unwind` (matching the guard present
  in the Docker and Podman arms). Eliminates worst-case 2x sequential probe stall.
- Add `PodmanRuntime::new_unchecked` to skip the redundant `is_available()`
  re-check inside `new_with_config` when the caller already gated on it.
- Update README: mark Auto as the default runtime; add Auto row to the modes table.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

---------

Signed-off-by: Adriano Machado <60320+ammachado@users.noreply.github.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-11 22:10:39 +05:30
..
2026-04-22 00:22:41 +05:30

wrkflw-executor

The execution engine that runs GitHub Actions workflows locally (Docker, Podman, emulation, or secure emulation).

  • Job graph execution with needs ordering and parallel independent jobs
  • Docker/Podman container steps, emulation, and sandboxed secure emulation
  • Run individual jobs via target_job / --job flag
  • GitHub Actions environment file support (GITHUB_OUTPUT, GITHUB_ENV, GITHUB_PATH, GITHUB_STEP_SUMMARY) with read-back
  • ${{ ... }} expression evaluator (toJSON, fromJSON, contains, startsWith, success(), failure(), etc.) with GitHub / env / matrix / secrets / needs / steps context
  • Action resolution for container, JavaScript, composite (with output propagation), and local actions
  • Job-level container: directive support
  • Local actions/upload-artifact, actions/download-artifact, and actions/cache via shared artifact and cache stores
  • Reusable workflow execution (jobs.<id>.uses, local or owner/repo/path@ref) with output aggregation into needs.<id>.outputs.*
  • Used by: wrkflw CLI and TUI

API sketch

use wrkflw_executor::{execute_workflow, ExecutionConfig, RuntimeType};

let cfg = ExecutionConfig {
    runtime_type: RuntimeType::Docker,
    verbose: true,
    preserve_containers_on_failure: false,
    secrets_config: None,
    show_action_messages: false,
    target_job: Some("build".to_string()), // run a single job
};

let workflow_path = std::path::Path::new(".github/workflows/ci.yml");
let result = execute_workflow(workflow_path, cfg).await?;
for job in &result.jobs {
    println!("{}: {:?}", job.name, job.status);
}

Prefer using the wrkflw binary for a complete UX across validation, execution, and logs.