Less-imperious validation of variable error_message contents

[enspritz]

Proposal

We propose changing Nomad's validation of variable.validation.error_message and like to cheerily accept a non-empty string, thus vanishing a cultural / human-language barrier encoded in Nomad. For example:

len(strings.Trim(error_message)) >= 1

Background

Coming in with this variable declaration in a .nomad job file from a team with people for whom English is not their mother tongue:

variable "build_id" {
  description = "static-site Docker image build ID"
  type        = string
  validation {
    condition     = length(var.build_id) >= 1
    error_message = "ビルド番号を確認してください"
  }
}

(The Japanese translates to "Please check the build number" and is perfectly accepted by every member of our team).

The issue is with Nomad's validation treatment of error_message; given the above snippet, Nomad isn't having any of it:

$ nomad plan -var="build_id=12345" local-deploy.nomad

local-deploy:25,21-39: Invalid validation error message; Validation error message must be at least one full sentence starting with an uppercase letter ( if the alphabet permits it ) and ending with a period or question mark.

While I can sympathize with the desire to nudge teams towards greater reliability in operation, the current error_message validation effectively boils down to pointless resistance & cultural friction, a unnecessary stumbling block in an already complicated system.

Use-cases

Let us use whatever string we desire for error_message, without cultural / human-language assumptions. Simply enforcing a non-empty string is suitable IMHO. Thanks!

[tgross]

Hi @enspritz! It looks like this is coming from types.variables.go#L452-L478 which as you can see from the comment was copy-and-pasted from a previous version of Packer. Totally agreed that this is a lousy validation. Something that may be relevant for your team is that HCL will only accept utf-8 encoding and not something like Shift JIS, but it looks like you've got that solved-for already.

Marking this as accepted for roadmapping. I'd also be happy to review a PR for a fix if you were interested in submitting one.

[enspritz]

Hi @tgross ! Thanks for looking into this. I don't have the bandwidth ATM to ready a PR ---

[sharmaansh21]

@tgross @enspritz I can pick this up, if it's ok with you folks.

[jrasell]

Hi @sharmaansh21; we do not have a formal way to assign this issue to you, but we are not currently working on it internally, so please feel free to pick this issue up. If you have any questions, please do not hesitate to reach out to us via this issue. Thanks for showing interest!