compose-go v1.13.0 supports the new additional_contexts to allow passing
additional build context during build, so we should map this to bake's
contexts property.
Signed-off-by: Justin Chadwell <me@jedevc.com>
compose-go v1.13.0 supports the new dockerfile_inline to allow including
a dockerfile inline in the compose definition, so we should map this to
bake's dockerfile-inline property.
Signed-off-by: Justin Chadwell <me@jedevc.com>
When resolving remote contexts locally in bake, then we need to ensure
that we properly unpack the contents of that context to the root
directory, instead of leaving it in the subdirectory.
Otherwise, any files will be found in the wrong location. Along with
this change, we also need a change to the dockerfile location lookup to
ensure that it is found at the root instead of in the subdirectory.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This adds an env var which can be used to pass in a path to a file to
read a buildkit source poliy from.
This is applied to any build is executed with the env set.
It is also applied to bakes (which are calling build behind the scenes).
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
The updateContext function may make modifications to the build inputs,
creating either an SSH URL, or an SSH llb.State. In these cases, we need
to ensure that we appropriately expose the client's default agent.
Previously, we would only expose it if the remote context was a git URL,
however, we need to also ensure that if the input was used to override
the context (in the case of ReadRemoteFiles), that we expose the agent
here as well.
Signed-off-by: Justin Chadwell <me@jedevc.com>
BuildKit's gitutil package behaves slightly differently than moby's
urlutil, so we should rely on BuildKit's gitutil when detecting URLs to
avoid cases of accidentally producing invalid build requests that can
confuse users.
Signed-off-by: Justin Chadwell <me@jedevc.com>
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>
Previously, when directly modifying the args map when reading targets,
we could end up in a scenario where bake tests that compare arg maps
would fail if SOURCE_DATE_EPOCH was set in the environment.
This patch prevents this failure by setting the SOURCE_DATE_EPOCH at the
command level (which isn't injected into tests as well), ensuring that
we test correctly even when SOURCE_DATE_EPOCH is set in the environment.
Signed-off-by: Justin Chadwell <me@jedevc.com>
We can perform all attestation processing, handling how the sbom and
provenance arguments interact on the client, while applying defaults on
the server.
Additionally, this allows us to start pulling fields out of CommonOpts.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Strongly typing the API allows us to perform all command line parsing
fully on the client-side, where we have access to the client local
directory and all the client environment variables, which may not be
available on the remote server.
Additionally, the controller api starts to look a lot like
build.Options, so at some point in the future there may be an
oppportunity to merge the two, which would allow both build and bake to
execute through the controller, instead of needing to maintain multiple
code paths.
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>
Justin Chadwell