This adds the following constraints to the new features:
- Explicit renaming with the `name` property is *only* permitted when
used with the `matrix` property.
- Group does not support either `name` or `matrix` (we may choose to
relax this constraint over time).
- All generated names must be unique.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Previously, the name property could not be set in the body of a bake
target and could only be set for a label. This patch allows the body to
override the values of label fields, though the default is still the
label.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This patch allows high level clients to define an EvalContext method
which can derive a new context given a block and the base parent
context.
This allows users of the package to intercept evaluation before it
begins, and define additional variables and functions that are bound to
a single block.
Signed-off-by: Justin Chadwell <me@jedevc.com>
With changes to the lazy evaluation, the evaluation order is no longer
fixed - this means that we can follow long and confusing paths to get to
an error.
Because of the co-recursive nature of the lazy evaluation, we need to
take special care that the original HCL diagnostics are not discarded
and are preserved so that the original source of the error can be
detected. Preserving the full trace is not necessary, and probably not
useful to the user - all of the file that is not lazily loaded will be
eagerly loaded after all struct blocks are loaded - so the error would
be found regardless.
Signed-off-by: Justin Chadwell <me@jedevc.com>
With changes made to allow lazy evaluation, we were early exiting if an
undefined name was detected, either for a variable or a function.
This had two key implications:
1. The error messages changed, and became significantly less
informative.
For example, we went from:
> Unknown variable; There is no variable named "FO". Did you mean "FOO"?, and 1 other diagnostic(s)
To
> Invalid expression; undefined variable "FO"
2. Any issues in our function detection from funcCalls which cause JSON
functions to be erroneously detected cause invalid functions to be
resolved, which causes new name resolution errors.
To avoid the above problems, we can defer the error from an undefined
name until HCL evaluation - which produces the more informative errors,
and does not suffer from incorrectly detecting JSON functions.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This patch adds support for block-based interpolation, so that
properties of blocks can be referenced in the current block and across
other blocks.
Previously, order-of-evaluation did not matter for blocks, and could be
evaluated in any order. However, now that blocks can refer to each
other, we split out this dynamic evaluation order into a separate
resolveBlock function.
Additionally, we need to support partial block evaluations - if block A
refers to property X of block B, when we should only evaluate property
X, and not the entire block. This ensures that we can safely evaluate
blocks that refer to other properties within themselves, and allows
sequences that would otherwise be co-recursive. We take special care in
this logic to ensure that each property is evaluated once *and only*
once - this could otherwise present inconsistencies with stateful
functions, and could risk inconsistent results.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Body.JustAttributes cannot distinguish between blocks and attributes for
JSON files, so the variable block could be included in the list of
attributes returned.
This patch ensures that JSON and HCL files behave the same way by
removing all known block types first, from the provided config schema
and then from a generated definitions schema.
Fixes#1051
Signed-off-by: Justin Chadwell <me@jedevc.com>
This fix adds a restriction `[a-zA-Z0-9_-]+`
for target name. This is pretty much the same as the
container name restriction in moby.
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
