Skip to main content

Crate noetl_executor

Crate noetl_executor 

Source
Expand description

§noetl-executor — shared utilities and types for CLI + worker

Hosts the type definitions, template rendering, condition evaluation, capability validation, and event-emission shape that the NoETL CLI’s noetl run --runtime local path AND the noetl-worker NATS daemon share.

§What this crate is

A utilities-and-types crate. See Appendix H of the global hybrid cloud blueprint at https://noetl.dev/docs/architecture/noetl_global_hybrid_cloud_grid_distributed_architecture_blueprint and especially § H.10 (the tree-walker vs pull-model finding) for the architectural rationale.

§What this crate is NOT

A control-loop crate. The CLI keeps its recursive tree walker in repos/cli/src/playbook_runner.rs — that shape is the natural fit for local YAML execution. The worker keeps its NATS pull loop. These control loops are fundamentally different; attempts to unify them produce more abstraction than they remove.

§Module layout

  • playbook — Pydantic-like YAML playbook types (R-1.1 PR-2a).
  • template — render_template, render_template_with_result, get_json_path, json_to_rhai, rhai_to_json_string (R-1.1 PR-2b).
  • condition — evaluate_condition, evaluate_rhai_condition (R-1.1 PR-2b).
  • capabilities — validate_capabilities + ValidationReport (R-1.1 PR-2b).
  • runtime — ExecutionContext, CredentialResolver trait (R-1.1 PR-1, kept; concrete CLI / worker contexts live in their own crates).
  • events — ExecutorEvent, EventSink trait, NoopSink, EventEmitter helper (R-1.1 PR-1).
  • tools_bridge — adapter layer onto the noetl-tools registry (R-1.1 PR-2c-1 onwards). Wires Tool::Rhai / Tool::Shell / Tool::Http / Tool::DuckDb through the registry; supplies pure helpers (prepare_sub_playbook_vars, resolve_auth_to_bearer, auth_context_updates, format_sink_payload, json_to_csv) for the inline tool kinds (Tool::Playbook / Tool::Auth / Tool::Sink) that stay in the CLI by design per § H.10.
  • worker — worker-only abstractions: worker::source contains the Command struct + CommandSource trait. The CLI does NOT consume these; they exist for the worker’s NATS pull loop.

§Stability

0.1.x is pre-production. Public API churns through R-1.1’s sub-PRs and stabilises around R-1.3 (worker depends on the crate). Treat as internal until then; the crate ships with publish = false.

Re-exports§

pub use runtime::CredentialResolver;
pub use runtime::ExecutionContext;

Modules§

capabilities
Capability validation — checks whether a playbook’s required executor.requires.{tools, features} set is satisfied by a runtime’s advertised crate::playbook::RuntimeCapabilities.
condition
Condition evaluation — simple template-style equality / contains / truthy checks (evaluate_condition) and full Rhai expression evaluation (evaluate_rhai_condition).
events
Event emission — pluggable sink that captures the events the executor produces during one execution.
playbook
Pydantic-like YAML playbook types.
runtime
Per-execution runtime context shared between sources, dispatch, and event emission.
template
Template rendering — {{ workload.var }} / {{ step.result }} / {{ result.path }} substitution with a minimal filter set.
tools_bridge
Bridge from the CLI’s YAML-parsed crate::playbook::Tool enum onto the noetl_tools registry’s dispatch API.
worker
Worker-only abstractions.

Structs§

EventEmitter
Re-exports for downstream crates (the CLI and the worker) so they can import from the crate root. Trait alias used by the dispatch loop — wraps a sink and a pre-computed execution_id so callers don’t have to thread it through every call site.

Traits§

EventSink
Re-exports for downstream crates (the CLI and the worker) so they can import from the crate root. Pluggable sink the executor emits ExecutorEvents through.