[v0.10] cherry-picks for v0.10.3 #1609
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Justin Chadwell <me@jedevc.com> (cherry picked from commit 48357ee)
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com> (cherry picked from commit 0e544fe)
Signed-off-by: Justin Chadwell <me@jedevc.com> (cherry picked from commit 07548bc)
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 dc8a2b0)
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com> (cherry picked from commit a8eb2a7)
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com> (cherry picked from commit fd58841)
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 fbb4f4d)
This comment was marked as resolved.
This comment was marked as resolved.
To give us the option later down the road of producing recommended OCI names in BuildKit (using com instead of vnd, woops), we need to update Buildx to be able to process both. Ideally, if a Buildx/BuildKit release hadn't been made we could just switch over, but since we have, we'd need to support both (at least for a while, eventually we could consider deprecating+removing the vnd variant). Signed-off-by: Justin Chadwell <me@jedevc.com> (cherry picked from commit 642f28f)
jedevc
approved these changes
Feb 16, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
com.docker.reference.*annotations #1617