wrkflw/crates/executor/README.md at 4a3c5b2e73452f29b668e6c5f817a992440f2439

mirror of https://github.com/bahdotsh/wrkflw.git synced 2026-05-18 05:05:35 +02:00

Files

Gokul 4a3c5b2e73 docs: catch up on everything that landed after v0.7.3 (#107 )

v0.7.3 was tagged back in August and then roughly fifty commits
happened. The docs, predictably, noticed none of this.

The README still advertised four TUI tabs when the TUI now has
seven, still listed three runtime modes when there are four, still
declared artifacts/cache/reusable-workflow outputs as "Not
Supported" when all three shipped in #88 and #94, and never
mentioned `wrkflw watch` or the `--event` / `--diff` /
`--changed-files` flags at all. `wrkflw-trigger-filter` and
`wrkflw-watcher` existed in the workspace without READMEs. Two of
the Rust examples referenced a `runtime` field on
`ExecutionConfig` that is actually called `runtime_type`, and
printed a `summary_status` field that doesn't exist. One
`run_wrkflw_tui` example was missing an argument. That kind of
thing.

While at it, BREAKING_CHANGES.md was labeling three entries as
"(v0.7.3)" when the underlying commits all landed *after* the
v0.7.3 tag — so calling them part of that release was, let's say,
a work of fiction. Relabel as "(Unreleased)" with a note up top
pointing at the next release.

New trigger-filter and watcher READMEs are deliberately short —
most users should hit that code through the CLI flags, not by
depending on the crates directly. No point padding them.

Nothing here is a code change. Just the docs finally telling the
truth about what's in the tree.

2026-04-21 23:43:11 +05:30

1.7 KiB

Raw Blame History

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.

1.7 KiB Raw Blame History

wrkflw-executor

API sketch

1.7 KiB

Raw Blame History