Defaulting -hcl2-strict=true is a breaking change

[adeschamps]

Nomad version

Nomad v1.2.3

Operating system and Environment details

Arch Linux

Issue

It was suggested in #11164 (comment) that the -hcl2-strict parameter should default to false and be configurable via an environment variable in order to not break the parsing of existing jobs/var-files which contain undeclared variables. However, this wasn't addressed before #11284 was merged; that PR originally defaulted to false but it was changed to true in 91061ae.

Reproduction steps

Executing the following without setting -hcl2-strict=false using a vars.hcl file that contains variables not declared in job.nomad:

nomad job validate -var-file=vars.hcl job.nomad

Expected Result

The job should validate successfully (this was the case before v1.2.0)

Actual Result

An "Undefined variable" error is returned.

---

The feature is a fine one, but unfortunately it caused a breaking change in a minor release. In our system, we typically define common variables for a region in a file, even if they're used only by some of the jobs deployed in that region; that is, we relied on the behaviour of -hcl2-strict=false.

I personally would prefer -hcl2-strict=false to be the default, although I've seen discussions here that argue the other way. Barring that, allowing this to be configured via an environment variable would allow us to maintain the previous behaviour with fewer changes to our scripts and workflow.

[tgross]

@adeschamps it looks like this is coming from b52f42d which landed in 1.2.0. Unfortunately the 1.2.0 Upgrade Guide doesn't call this out, so that's absolutely a documentation fix we need. While I can see an argument for it either way, we definitely intended for strict to be the default behavior.

it caused a breaking change in a minor release

Just for clarity, we make breaking changes in "minor" releases with some frequency (although we're always forward-compatible at the data store level). I don't think we have a public versioning stance, but generally speaking we backport patches to two minor versions (and honestly you may see us refer to those as "major" versions just because we're an application not a library so semver doesn't really apply here). Ex. fixes for 1.2.3 got backported to 1.1.9 and 1.0.15.

[github-actions]

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