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>
(cherry picked from commit fbb4f4dec86541dd243e99816ef84b3a4d4741c2)
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>
(cherry picked from commit dc8a2b03987f1266ace9a7cdcba92f5e4ccdb8ed)
Using the syncronization primitive, we can avoid needing to create a
separate wait group.
This allows us to sidestep the issue where the wait group could be
completed, but the build invocation functions had not terminated - if
one of the functions was to terminate with an error, then it was
possible to encounter a race condition, where the result handling code
would begin executing, despite an error.
The refactor to use a separate error group which more elegantly handles
the concept of function returns and errors, ensures that we can't
encounter this issue.
Signed-off-by: Justin Chadwell <me@jedevc.com>
(cherry picked from commit 8b7aa1a168c303521cfb6613c52480cd71f1ef20)
This change has been introduced in e7b5ee7518703fb284fd9ece81abf71e4838f4d9
but we should not check context builders when removing inactive
ones.
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
(cherry picked from commit 6cd0c11ab11f016a8037e039a51eaf3a17207312)
So it doesn't show up in the History API.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
(cherry picked from commit be55b41427d5211cf12069714c95f5f2d8e184d9)
Delay loading the attestation data immediately, and only compute it upon
request. We do this using a deferred function which allows to define the
computation in the same place as before, but perform the computation
later.
With this patch, we ensure that the attestation data is only pulled from
the remote if it is actually referenced in the format string -
otherwise, we can skip it, for improved performance.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This refactor ensures that the attestations are not output in the JSON
output for "{{ json . }}", and additionally allows future refactors to
dynamically load the attestation contents, ensuring faster performance
when attestations are not used in the output.
Signed-off-by: Justin Chadwell <me@jedevc.com>
We should avoid erroring with attestations support compatability errors
when a user has specified --provenance=false.
A user may wish to enable --provenance=false that works across buildkit
versions, but currently it will fail on old versions - this patch fixes
this, to silently ignore the provenance flag for this check if it's set
to disabled.
Signed-off-by: Justin Chadwell <me@jedevc.com>
(cherry picked from commit 15a80b56b5d015baf40ff2393f424ff0bcc51d2b)
Signed-off-by: Justin Chadwell <me@jedevc.com>
full diff: https://github.com/moby/buildkit/compare/v0.11.0...v0.11.1
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 01e1c28dd9cec63c96139416e7a866cd659a90b5)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit c97500b11768a3ed8ff20388941b256be389dc84)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit b8285c17e606e10b77357cdb3e868f0798a834df)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
