heh, terraform is just ... special

  resource "nomad_job" "terrareg" {
    jobspec = <<EOHCL
  job "terrareg" {

but to be actually constructive, a fun trick is that one can patch this stanza in via the GL pipeline and thus allow local $(tofu plan) runs without needing, or running the risk of, live gitlab credentials

  variables:
    # Backend required for Gitlab state
    BACKEND_TF: |
      terraform {
        backend "http" {
        }
      }
  before_script:
  - echo "$BACKEND_TF" > backend.tf

it may also interest this audience that due to gitlab's in-container shell detection scheme, often a better entrypoint override is entrypoint: ["/usr/bin/env"] (assuming such a thing exists, of course)

Hey :)

That's a good idea for the backend - thank you!

And yes, I should have used the used a separate HCL file for the nomad_job - aside from being cleaner, it would have also avoided some horrific JSON encode that I had to use for an environment variable (think: `env { blah = eplace("\"", "\\\"", jsonencode(local.something))`), since I could just pass the jsonencode value straight to the value of the parameter, rather than getting Terraform to convert it to a string for the template.

Thanks for sharing this; happy to see the spreading of Nomad insights. I had once upon a time done this with GitLab and Kubernetes, but now that I switched to Nomad, I lost that... will explore this further.

I manage a lot of these sorts of templates... I "Terraform template" the "Nomad Job", which also sometimes has its own Nomad template stanzas. [1] Separating it all makes things easier to track, although I suspect that when you have that scaffolding set up, you don't need to look at it or modify it much.

If I know I want something JSON, then I include "_JSON" in the variable name and then it's clear I should have a `jsonencode` there. [2]

[1] https://github.com/neomantra/terraform-nomad-temporal/blob/m... [2] https://github.com/neomantra/terraform-nomad-temporal/blob/m...

I do completely agree - the main problem I had was that, I tried doing this whilst writing the blog post side-by-side and was aware that the more complex it became, the harder it would be to show it. If I'd use separate files for the HCL then I'd need to show them both (and I think adding a little bit of cognitive complexity to read). So then adding templates etc, would increase that more.

I know for the "creating a server", I just used a module, but all it's meant to say is "I created a machine" and how I did that probably wasn't that important (apart maybe any tiny fragments of useful information with the variables), so I left it as a module. Same with the nomad setup - but at the same time, for what I was trying to achieve, running `nomad agent -dev` would have sufficed, so was somewhat happy with skipping it and showing the module call as "nomad was setup".

So for the remainder, I tried to prefer simplicity and readability, rather than "this is the best way to write Terraform and dynamic modules".

But, I completely agree with you :) Given the nature of the project it's in the pipeline for - I can certainly saying that I like a good Terraform module ;)

Not really sure what's wrong with the Terraform example, other than the lack of use of the heredoc with hanging indents, which would correctly nest the job spec.

Hey this is very cool.

I did something similar with Kubernetes, work has some OSE clusters that will generate DNS for you, it works great and the devs love using it. It’s a little bespoke but its simple and gets a lot of attention.

Plus since the namespaces preexist the workloads, we spin them up for the entire branch lifetime (times out after n days). Makes everyones jobs a lot easier.

Anything that helps shift lifecycle requirements and testing left has huge impact on DX.

One thing that I haven't out how to do is allowing unauthenticated Gitlab users to view deployments/environments for public projects.

Not only is the "deployments" tab missing (which isn't the _end_ of the world), but the environment (with the link to the instance) isn't shown in pull requests until the user logs in.

Does anyone know if this is possible? I couldn't find much in Gitlab's docs

Think it is only possible with public projects

It's definitely a public project :)

Edit: Ah, I found it - it's the permissions for 'Operations'