mirror of
https://github.com/bahdotsh/wrkflw.git
synced 2026-09-02 12:16:16 +02:00
The steps. word-boundary heuristic in evaluate_job_condition was checking for alphanumeric characters before "steps." to avoid false positives on env vars like "env.MY_STEPS_COUNT". It turns out that underscore is *not* alphanumeric, so "env._STEPS_CHECK" would incorrectly trigger the step-reference path and return false. While at it, the always() && failure() compound expression returning true got a proper comment explaining *why* that's intentional — we lack step-status context locally, so we'd rather over-run than silently skip steps. Not ideal, but honest. The DFS cycle detector in detect_cyclic_needs could report the same cycle multiple times depending on HashMap iteration order. Normalize cycles by rotating the node list to start at the lexicographically smallest node, then deduplicate via a HashSet. Same cycle from different entry points now gets reported exactly once.
wrkflw-executor
The execution engine that runs GitHub Actions workflows locally (Docker, Podman, or emulation).
- Features:
- Job graph execution with
needsordering and parallelism - Docker/Podman container steps and emulation mode
- Basic environment/context wiring compatible with Actions
- Job graph execution with
- Used by:
wrkflwCLI and TUI
API sketch
use wrkflw_executor::{execute_workflow, ExecutionConfig, RuntimeType};
let cfg = ExecutionConfig {
runtime: RuntimeType::Docker,
verbose: true,
preserve_containers_on_failure: false,
};
// Path to a workflow YAML
let workflow_path = std::path::Path::new(".github/workflows/ci.yml");
let result = execute_workflow(workflow_path, cfg).await?;
println!("workflow status: {:?}", result.summary_status);
Prefer using the wrkflw binary for a complete UX across validation, execution, and logs.