Documentation
¶
Overview ¶
Package pipeline provides the `@pipeline NAME ... @end` directive. The block is stored in meta["pipelines"] and compiled into a sub-action mounted on the resolver by the Materialize step, so later pipelines can reference it by name.
Typical use:
@pipeline safe_fetch
fetch -> validate
@end
{ url: "https://x" } -> safe_fetch
Index ¶
Constants ¶
const ID = "pipeline"
Variables ¶
var Directive = core.Directive{
Name: "pipeline",
Example: "@pipeline pack:route=\"POST /pack\"\n src -> dst\n@end",
Handler: handleDirective,
}
Directive parses `@pipeline NAME ... @end` and stores the block body in meta["pipelines"][NAME]. Inline modifiers after the name — `:key` or `:key=value`, with optional single/double-quoted values — are collected into meta["pipeline_modifiers"][NAME] and applied to the compiled sub-pipeline during materialization.
Each declared pipeline is mounted on the resolver as `pipeline.<name>` (the prefix is added only when the name has no dot), so a pipeline may reference another by its canonical name.
`@pipeline name` with no modifiers is valid and behaves exactly as it did before modifiers were supported.
var EndDirective = core.Directive{
Name: "end",
Example: "@pipeline p\n ...\n@end",
Handler: handleEnd,
}
EndDirective rejects a stray `@end`. It only fires when `@end` appears outside a `@pipeline` block, because the pipeline handler consumes its own terminator while scanning the body and never forwards it to the directive table. Outside a pipeline the fallback path is the macro primary, which reports `unknown macro @end` — a diagnostic that hides the actual problem. This handler replaces it with a message that names the missing opening directive.
Registered in Bundle().Directives so every top-level `@end` in any fixture is a registered directive; the native fixture contract test enforces that invariant across every embedded .nflow file.
Functions ¶
Types ¶
type AppliedModifier ¶ added in v0.14.0
type AppliedModifier struct {
Raw string
Source core.ModifierSource
}
AppliedModifier is a modifier together with the origin that produced it. Pipeline directive handlers build these so `nflow explain` can attribute every effective modifier to a pipeline or profile.
Source Files