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)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.
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 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.
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
Edit: Ah, I found it - it's the permissions for 'Operations'