mirror of
https://github.com/bahdotsh/wrkflw.git
synced 2026-05-18 05:05:35 +02:00
4a3c5b2e73
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.
554 B
554 B
wrkflw-runtime
Runtime abstractions for executing steps in containers, on the host, or in a local sandbox.
- Container management primitives used by the executor (Docker, Podman)
- Emulation mode helpers (run on host without containers)
- Secure emulation runtime: sandboxed host processes with filesystem and network restrictions for running untrusted workflows without a container runtime
Example
// This crate is primarily consumed by `wrkflw-executor`.
// Prefer using the executor API instead of calling runtime directly.