Documentation ¶
Overview ¶
Package dynblock provides an extension to HCL that allows dynamic declaration of nested blocks in certain contexts via a special block type named "dynamic".
Index ¶
- func Expand(body hcl.Body, ctx *hcl.EvalContext, opts ...ExpandOption) hcl.Body
- func ExpandFunctionsHCLDec(body hcl.Body, spec hcldec.Spec) []hcl.Traversal
- func ExpandVariablesHCLDec(body hcl.Body, spec hcldec.Spec) []hcl.Traversal
- func FunctionsHCLDec(body hcl.Body, spec hcldec.Spec) []hcl.Traversal
- func VariablesHCLDec(body hcl.Body, spec hcldec.Spec) []hcl.Traversal
- type ExpandOption
- type WalkFunctionsChild
- type WalkFunctionsNode
- type WalkVariablesChild
- type WalkVariablesNode
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Expand ¶
func Expand(body hcl.Body, ctx *hcl.EvalContext, opts ...ExpandOption) hcl.Body
Expand "dynamic" blocks in the given body, returning a new body that has those blocks expanded.
The given EvalContext is used when evaluating "for_each" and "labels" attributes within dynamic blocks, allowing those expressions access to variables and functions beyond the iterator variable created by the iteration.
Expand returns no diagnostics because no blocks are actually expanded until a call to Content or PartialContent on the returned body, which will then expand only the blocks selected by the schema.
"dynamic" blocks are also expanded automatically within nested blocks in the given body, including within other dynamic blocks, thus allowing multi-dimensional iteration. However, it is not possible to dynamically-generate the "dynamic" blocks themselves except through nesting.
parent { dynamic "child" { for_each = child_objs content { dynamic "grandchild" { for_each = child.value.children labels = [grandchild.key] content { parent_key = child.key value = grandchild.value } } } } }
func ExpandFunctionsHCLDec ¶
ExpandFunctionsHCLDec is like FunctionsHCLDec but it includes only the minimal set of functions required to call Expand, ignoring functions that are referenced only inside normal block contents. See WalkExpandFunctions for more information.
func ExpandVariablesHCLDec ¶
ExpandVariablesHCLDec is like VariablesHCLDec but it includes only the minimal set of variables required to call Expand, ignoring variables that are referenced only inside normal block contents. See WalkExpandVariables for more information.
func FunctionsHCLDec ¶
FunctionsHCLDec is a wrapper around WalkFunctions that uses the given hcldec specification to automatically drive the recursive walk through nested blocks in the given body.
This is a drop-in replacement for hcldec.Functions which is able to treat blocks of type "dynamic" in the same special way that dynblock.Expand would, exposing both the functions referenced in the "for_each" and "labels" arguments and functions used in the nested "content" block.
func VariablesHCLDec ¶
VariablesHCLDec is a wrapper around WalkVariables that uses the given hcldec specification to automatically drive the recursive walk through nested blocks in the given body.
This is a drop-in replacement for hcldec.Variables which is able to treat blocks of type "dynamic" in the same special way that dynblock.Expand would, exposing both the variables referenced in the "for_each" and "labels" arguments and variables used in the nested "content" block.
Types ¶
type ExpandOption ¶
type ExpandOption interface {
// contains filtered or unexported methods
}
func OptCheckForEach ¶
func OptCheckForEach(check func(cty.Value, hcl.Expression, *hcl.EvalContext) hcl.Diagnostics) ExpandOption
type WalkFunctionsChild ¶
type WalkFunctionsChild struct { BlockTypeName string Node WalkFunctionsNode }
func (WalkFunctionsChild) Body ¶
func (c WalkFunctionsChild) Body() hcl.Body
Body returns the HCL Body associated with the child node, in case the caller wants to do some sort of inspection of it in order to decide what schema to pass to Visit.
Most implementations should just fetch a fixed schema based on the BlockTypeName field and not access this. Deciding on a schema dynamically based on the body is a strange thing to do and generally necessary only if your caller is already doing other bizarre things with HCL bodies.
type WalkFunctionsNode ¶
type WalkFunctionsNode struct {
// contains filtered or unexported fields
}
func WalkExpandFunctions ¶
func WalkExpandFunctions(body hcl.Body) WalkFunctionsNode
WalkExpandFunctions is like Functions but it includes only the functions required for successful block expansion, ignoring any functions referenced inside block contents. The result is the minimal set of all functions required for a call to Expand, excluding functions that would only be needed to subsequently call Content or PartialContent on the expanded body.
func WalkFunctions ¶
func WalkFunctions(body hcl.Body) WalkFunctionsNode
WalkFunctions begins the recursive process of walking all expressions and nested blocks in the given body and its child bodies while taking into account any "dynamic" blocks.
This function requires that the caller walk through the nested block structure in the given body level-by-level so that an appropriate schema can be provided at each level to inform further processing. This workflow is thus easiest to use for calling applications that have some higher-level schema representation available with which to drive this multi-step process. If your application uses the hcldec package, you may be able to use FunctionsHCLDec instead for a more automatic approach.
func (WalkFunctionsNode) Visit ¶
func (n WalkFunctionsNode) Visit(schema *hcl.BodySchema) (vars []hcl.Traversal, children []WalkFunctionsChild)
Visit returns the function traversals required for any "dynamic" blocks directly in the body associated with this node, and also returns any child nodes that must be visited in order to continue the walk.
Each child node has its associated block type name given in its BlockTypeName field, which the calling application should use to determine the appropriate schema for the content of each child node and pass it to the child node's own Visit method to continue the walk recursively.
type WalkVariablesChild ¶
type WalkVariablesChild struct { BlockTypeName string Node WalkVariablesNode }
func (WalkVariablesChild) Body ¶
func (c WalkVariablesChild) Body() hcl.Body
Body returns the HCL Body associated with the child node, in case the caller wants to do some sort of inspection of it in order to decide what schema to pass to Visit.
Most implementations should just fetch a fixed schema based on the BlockTypeName field and not access this. Deciding on a schema dynamically based on the body is a strange thing to do and generally necessary only if your caller is already doing other bizarre things with HCL bodies.
type WalkVariablesNode ¶
type WalkVariablesNode struct {
// contains filtered or unexported fields
}
func WalkExpandVariables ¶
func WalkExpandVariables(body hcl.Body) WalkVariablesNode
WalkExpandVariables is like Variables but it includes only the variables required for successful block expansion, ignoring any variables referenced inside block contents. The result is the minimal set of all variables required for a call to Expand, excluding variables that would only be needed to subsequently call Content or PartialContent on the expanded body.
func WalkVariables ¶
func WalkVariables(body hcl.Body) WalkVariablesNode
WalkVariables begins the recursive process of walking all expressions and nested blocks in the given body and its child bodies while taking into account any "dynamic" blocks.
This function requires that the caller walk through the nested block structure in the given body level-by-level so that an appropriate schema can be provided at each level to inform further processing. This workflow is thus easiest to use for calling applications that have some higher-level schema representation available with which to drive this multi-step process. If your application uses the hcldec package, you may be able to use VariablesHCLDec instead for a more automatic approach.
func (WalkVariablesNode) Visit ¶
func (n WalkVariablesNode) Visit(schema *hcl.BodySchema) (vars []hcl.Traversal, children []WalkVariablesChild)
Visit returns the variable traversals required for any "dynamic" blocks directly in the body associated with this node, and also returns any child nodes that must be visited in order to continue the walk.
Each child node has its associated block type name given in its BlockTypeName field, which the calling application should use to determine the appropriate schema for the content of each child node and pass it to the child node's own Visit method to continue the walk recursively.