Skip to main content

Module store

Module store 

Source
Available on crate feature templates only.
Expand description

Registration + materialization of pipeline templates (#444).

Pure orchestration over crate::serve::history::RunHistory’s template methods and crate::params; no HTTP, no clap, no MCP shapes — the three front-ends are thin adapters over the two entry points here.

Structs§

LaunchOutcome
The outcome of a launch: which version is now live, and what it replaced.
MaterializedConfig
A template rendered for one trigger: a config document with every ${param.*} bound, ready to hand to the ordinary run path.
RegisterRequest
A registration, before validation.

Enums§

Materialize
Where the materialized config is going — which decides whether load-time directives may be resolved here.

Functions§

launch
Launch a version: make it stable, so unpinned callers start using it.
list_with_state
Every registered template’s latest version, each carrying its release state.
materialize
Fetch a template version and bind the supplied params into a runnable config document.
promote
Point a named environment channel at a version, moving it if already set.
register
Validate a submitted config and append it as a new template version.
resolve_store_url
Connect a template store from a URL: memory, sqlite:<path>, or a postgres://… URL. Same grammar (and same build-feature requirements) as catalog.url and faucet serve --history, so one store can hold run history, the dataset catalog, and the template registry together.
resolve_version
Resolve a VersionSelector to the exact version to act on.
rollback
Roll back to the previously launched version — launch of previous, named for the thing you actually want to find under pressure.
set_deprecated
Retire (Some) or revive (None) a template.
template_state
The template’s full release state (status, stable / previous / newest, channel pointers). Errors only if the registry itself is unreadable.

Type Aliases§

TemplateStore
The registry handle. Any RunHistory backend will do — faucet serve passes its own --history store so templates live beside run records; the CLI connects one from --store / the config’s catalog: block.