[HPR-837] Update validation options for undeclared variables

[nywilken]

In an effort to help users move from JSON to HCL2 templates the support for variable definitions files are being updated to ignore undeclared variable warnings on build execution. For legacy JSON template builds no warnings are displayed when var-files contain undeclared variables. So the behavior is sort of the same.

Since the preferred mode for HCL2 templates is to be explicit with variable declarations - they must be declared to be used - validation for undeclared variables still warns when running packer validate. A new flag has been added to the validate command that can be used to disable undeclared variable warnings.

Closes: #12109
Related to: #9822

Example packer validate run

~>  go run . validate -no-warn-undeclared-var -var-file command/test-fixtures/validate/var-file-tests/undeclared.pkrvars.hcl \
command/test-fixtures/validate/var-file-tests/basic.pkr.hcl
The configuration is valid.

~>  go run . validate -var-file command/test-fixtures/validate/var-file-tests/undeclared.pkrvars.hcl \
command/test-fixtures/validate/var-file-tests/basic.pkr.hcl
Warning: Undefined variable

The variable "unused" was set but was not declared as an input variable.
To declare variable "unused" place this block in one of your .pkr.hcl
files,
such as variables.pkr.hcl

variable "unused" {
  type    = string
  default = null

}

The configuration is valid.

Example packer build runs

~>  go run . build -var-file command/test-fixtures/validate/var-file-tests/undeclared.pkrvars.hcl \
command/test-fixtures/validate/var-file-tests/basic.pkr.hcl
file.chocolate: output will be in this color.

Build 'file.chocolate' finished after 744 microseconds.

==> Wait completed after 798 microseconds

==> Builds finished. The artifacts of successful builds are:
--> file.chocolate: Stored file: chocolate.txt

~>  go run . build -warn-on-undeclared-var -var-file command/test-fixtures/validate/var-file-tests/undeclared.pkrvars.hcl command/test-fixtures/validate/var-file-tests/basic.pkr.hcl
Warning: Undefined variable

The variable "unused" was set but was not declared as an input variable.
To declare variable "unused" place this block in one of your .pkr.hcl files,
such as variables.pkr.hcl

variable "unused" {
  type    = string
  default = null
}


file.chocolate: output will be in this color.

Build 'file.chocolate' finished after 762 microseconds.

==> Wait completed after 799 microseconds

==> Builds finished. The artifacts of successful builds are:
--> file.chocolate: Stored file: chocolate.txt

[lbajolet-hashicorp]

Overall LGTM, I do have some concerns relative to the naming of both the option and in the code, but the code looks good to me.

[lbajolet-hashicorp]

More a question than anything, is null a valid default value for a string?

[nywilken]

Yes, this does work. We could set the default value to an empty string but that may not immediately imply to the user that the variable is optional. We have the use of default = null documented as the preferred way to make a value of any type optional. So I went with that.

I've considered adding a comment to the example block to indicate that both type and the default value should be changed to reflect the actual value in the var-file. But that might be too much info. Thoughts?

[lbajolet-hashicorp]

No I think you're right, it may be a bit much, just stating they need to declare a variable block to make their template valid is good enough imo, that was just me asking a question out of curiosity, I didn't know that null was accepted for any type and was the preferred way to make a variable optional.
If that's documented and known, no issue in proposing null to be the default value, users can choose whatever else suits their need should they want to.
Besides it's just an example of what they need to add to their template, they'll have to change its contents 90% of the time because the default value is not required, different, or because the type is not string, so I don't think we need to worry too much about what's in there.

[nywilken]

Overall LGTM, I do have some concerns relative to the naming of both the option and in the code, but the code looks good to me.

I've re-rolled to account for the provided feedback. Feel free to review the updates when ready.

[lbajolet-hashicorp]

Just a last thing I left a comment for, other than that, LGTM!

[lbajolet-hashicorp]

No I think you're right, it may be a bit much, just stating they need to declare a variable block to make their template valid is good enough imo, that was just me asking a question out of curiosity, I didn't know that null was accepted for any type and was the preferred way to make a variable optional.
If that's documented and known, no issue in proposing null to be the default value, users can choose whatever else suits their need should they want to.
Besides it's just an example of what they need to add to their template, they'll have to change its contents 90% of the time because the default value is not required, different, or because the type is not string, so I don't think we need to worry too much about what's in there.

[lbajolet-hashicorp]

LGTM

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.