noetl_executor/lib.rs
1//! # `noetl-executor` — shared utilities and types for CLI + worker
2//!
3//! Hosts the type definitions, template rendering, condition
4//! evaluation, capability validation, and event-emission shape that
5//! the NoETL CLI's `noetl run --runtime local` path AND the
6//! `noetl-worker` NATS daemon share.
7//!
8//! ## What this crate is
9//!
10//! A **utilities-and-types** crate. See Appendix H of the global
11//! hybrid cloud blueprint at
12//! <https://noetl.dev/docs/architecture/noetl_global_hybrid_cloud_grid_distributed_architecture_blueprint>
13//! and especially § H.10 (the tree-walker vs pull-model finding)
14//! for the architectural rationale.
15//!
16//! ## What this crate is NOT
17//!
18//! A **control-loop crate**. The CLI keeps its recursive tree
19//! walker in `repos/cli/src/playbook_runner.rs` — that shape is the
20//! natural fit for local YAML execution. The worker keeps its
21//! NATS pull loop. These control loops are fundamentally different;
22//! attempts to unify them produce more abstraction than they remove.
23//!
24//! ## Module layout
25//!
26//! - [`playbook`] — Pydantic-like YAML playbook types (R-1.1 PR-2a).
27//! - [`template`] — `render_template`, `render_template_with_result`,
28//! `get_json_path`, `json_to_rhai`, `rhai_to_json_string` (R-1.1 PR-2b).
29//! - [`condition`] — `evaluate_condition`, `evaluate_rhai_condition`
30//! (R-1.1 PR-2b).
31//! - [`capabilities`] — `validate_capabilities` + `ValidationReport`
32//! (R-1.1 PR-2b).
33//! - [`runtime`] — `ExecutionContext`, `CredentialResolver` trait
34//! (R-1.1 PR-1, kept; concrete CLI / worker contexts live in their
35//! own crates).
36//! - [`events`] — `ExecutorEvent`, `EventSink` trait, `NoopSink`,
37//! `EventEmitter` helper (R-1.1 PR-1).
38//! - [`tools_bridge`] — adapter layer onto the `noetl-tools` registry
39//! (R-1.1 PR-2c-1 onwards). Wires `Tool::Rhai` / `Tool::Shell` /
40//! `Tool::Http` / `Tool::DuckDb` through the registry; supplies pure
41//! helpers (`prepare_sub_playbook_vars`, `resolve_auth_to_bearer`,
42//! `auth_context_updates`, `format_sink_payload`, `json_to_csv`)
43//! for the inline tool kinds (`Tool::Playbook` / `Tool::Auth` /
44//! `Tool::Sink`) that stay in the CLI by design per § H.10.
45//! - [`worker`] — worker-only abstractions: [`worker::source`]
46//! contains the `Command` struct + `CommandSource` trait. The CLI
47//! does NOT consume these; they exist for the worker's NATS pull
48//! loop.
49//!
50//! ## Stability
51//!
52//! `0.1.x` is pre-production. Public API churns through R-1.1's
53//! sub-PRs and stabilises around R-1.3 (worker depends on the
54//! crate). Treat as internal until then; the crate ships with
55//! `publish = false`.
56
57#![allow(dead_code)]
58
59pub mod capabilities;
60pub mod condition;
61pub mod events;
62pub mod playbook;
63pub mod runtime;
64pub mod template;
65pub mod tools_bridge;
66pub mod worker;
67
68/// Re-exports for downstream crates (the CLI and the worker) so they
69/// can import from the crate root.
70pub use events::{EventEmitter, EventSink};
71pub use runtime::{CredentialResolver, ExecutionContext};