mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-10-09 03:20:56 +00:00
Fabro runs its workflows on Petri. The six Petri packages and the testkit are pinned by revision in the workspace manifest under `petri_*` keys, and `fabro-petri` is the one crate that depends on them. The crate's tests run the `hello` bundle in memory on the stub registry and a command-only workflow on the host sandbox; both skip without the sandbox-driver host plugin, and the sandbox-plugins CI job requires it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| src | ||
| tests | ||
| Cargo.toml | ||
| README.md | ||
fabro-petri
Fabro's adapters over Petri, the workflow engine Fabro runs its workflows on.
Layering rule
Only this crate imports Petri. The workspace Cargo.toml pins the Petri
packages by revision under petri_* keys, and fabro-petri is the only
member that lists them as dependencies. Every other Fabro crate reaches the
engine through what this crate exports. A Petri pin move is therefore a change
to this crate and the lockfile, nothing else.
What it holds
Every adapter the integration plan describes lands here: the run store over Fabro's SQLite database, then the platform adapters (hooks, interviews, secrets, output storage, run tools, the event projection).
How it is tested
Integration tests live under tests/:
runs.rsruns thehellobundle in memory throughRuntime::standard()with the Fabro frontend and the model-free stub registry, then a command-only workflow on the host sandbox through the real step registry. The sandbox test skips, and says why, when thesandbox-driver-hostplugin executable is not onPATH.
Run them with:
ulimit -n 4096 && cargo nextest run -p fabro-petri