HCL2: Is it me or is the example wrong


Looking at Local Values - HCL Configuration Language | Nomad by HashiCorp

# Local values can be interpolated elsewhere using the "local." prefix.
job "${local.name_prefix}_loadbalancer" {
  # ...

Then, tried to replicate, but it results inn error:

locals {
  name = "${var.project}.${var.service_name}"

job "${local.name}" {
# ...

Error getting job struct: Error parsing job file from job.nomad:
job.nomad:58,6-8: Invalid string literal; Template sequences are not allowed in this string. To include a literal “$”, double it (as “$$”) to escape it.

Did I miss anything?

Hi @resmo,

It isn’t you, the example is wrong. I will raise a PR to fix this documentation shortly. This issue is tracked on GitHub is you wanted to read additional details.

jrasell and the Nomad team


…my thoughts exactly… Whaaat am I missing here… :slight_smile:

Yes, you can’t use variables in the ‘job’ name field (which would be a nice feature…).

I had high hopes when I saw this example, but sadly it doesn’t work :wink:

I template my jobfiles using terraform instead, because of this

If I understood correctly this will land eventually natively in HCL2. But, like you, this is the reason I template the Nomad job file too… :upside_down_face:

My 0.02:

I have been actively reducing the number of “templatization” passes. For me there was Jinja2, terraform (templatefile), Nomad’s HCL2.

For now, I have settled on: Jinja2-ized “.nomad” file and a one-liner nomad_job Terraform resource.

Note: If I need to use the template block inside the Nomad job, I change the delimiter characters to [[ and ]] so as not to interfere with the outer Jinja’s {{ and }}.

This has the benefit that I get to see the actual Nomad job file without the intermediate Terraform template and the double $$ escaping.

Q: Why Jinja? A: Legacy toolchain.
In my opinion, the outer Jinja could be replaced with Levant.