
![banner](/img/inline-config.png)

When you configure a Cloud Build trigger via the Cloud Console, you have the
option of specifying the the `cloubuild.yaml` configuration as either a file
location on the repository or as an inline configuration.  I'm going to show you
how you can create a Cloud Build trigger with inline configuration using
Terraform. We're gonna make use of Terraform's [templatefile() function](https://developer.hashicorp.com/terraform/language/functions/templatefile).

Follow along with the [code available here](https://github.com/rogerthatdev/cloud-build-terraform/tree/main/inline-yaml).
{/*more*/}

## Simplest example
Here's a basic Cloud Build Trigger configured with a Cloud Source Repo I made 
somewhere else in this `.tf` file:

```
resource "google_cloudbuild_trigger" "simplest_inline" {
  project     = var.project_id
  location    = var.region
  name        = "01-simplest-inline-config-example"
  description = "This trigger is deployed by terraform, with an in-line build config."
  trigger_template {
    branch_name  = "^main$"
    invert_regex = false
    project_id   = var.project_id
    # I can't create a trigger without connecting a repo to the project, so I 
    # made a Cloud Source Repo and passed it along here
    repo_name    = google_sourcerepo_repository.placeholder.name
  }
  build {
    images        = []
    substitutions = {}
    tags          = []
    # This is a single step defined inline
    step {
      name = "ubuntu"
      args = [
        "echo",
        "hello world hey"
      ]
    }
    timeout = "600s"
  }
}
```

It's a single step, passed along to the `build` block. This trigger will have the following Cloud Build config 
configured inline:

```yaml
steps:
  - name: ubuntu
    args:
      - echo
      - hello world hey
timeout: 600s

```


## Use a yaml.tftpl file

You can acheive the above configuration using a Terraform template file that 
looks like the familiar cloudbuild.yaml file:

```
# 02-simple.cloudbuild.yaml.tftpl
steps:
  - name: ubuntu
    args:
      - echo
      - hello world hey
timeout: 600s

```

I can pass along values for the `step` block using a local value:

```
locals {
  # we bring in the yaml content via yamldecode() and templatefile()
  simple_config_02 = yamldecode(templatefile("${path.root}/cloudbuild/02-simple.cloudbuild.yaml", {}))
}

resource "google_cloudbuild_trigger" "simple_inline_02" {
  project     = var.project_id
  location    = var.region
  name        = "02-simple-inline-config-example"
  description = "This trigger is deployed by terraform, with an in-line build config."
  trigger_template {
    branch_name  = "^main$"
    invert_regex = false
    project_id   = var.project_id
    repo_name    = google_sourcerepo_repository.placeholder.name
  }
  build {
    images        = []
    substitutions = {}
    tags          = []
    # The single step gets values for name and args from the yaml brought in via
    # the local value above. This works because there's only one step.
    step {
      name = local.simple_config_02.steps[0].name
      args = local.simple_config_02.steps[0].args
    }
  }
}
```
When deployed, the trigger will have the same in-line configuration as the 
example above:
```
steps:
  - name: ubuntu
    args:
      - echo
      - hello world hey
timeout: 600s

```
To pass along values for more than one step, I'll use a dynamic block.


## The dynamic `step` block

Here's a new template file with two steps:

```
# 03-multi-step-dynamic.cloudbuild.yaml.tftpl
steps:
  - name: ubuntu
    args:
      - echo
      - hello world hey
  - name: ubuntu
    args:
      - echo
      - peace out world
timeout: 600s

```
And here's our trigger configuration:

```
locals {
  # once again: we bring in the yaml content via yamldecode() and templatefile()
  simple_config_03 = yamldecode(templatefile("${path.root}/cloudbuild/03-multi-step-dynamic.cloudbuild.yaml", {}))
}

resource "google_cloudbuild_trigger" "simple_inline_03" {
  project     = var.project_id
  location    = var.region
  name        = "03-simple-inline-config-example"
  description = "This trigger is deployed by terraform, with an in-line build config."
  trigger_template {
    branch_name  = "^main$"
    invert_regex = false
    project_id   = var.project_id
    repo_name    = google_sourcerepo_repository.placeholder.name
  }
  build {
    images        = []
    substitutions = {}
    tags          = []
    # This is the dynamic block that will create a step block for each step in
    # the cloud build config file defined in the locals block above. This will
    # with as many steps as the build config file may have.
    dynamic "step" {
      for_each = local.simple_config_03.steps
      content {
        args = step.value.args
        name = step.value.name
      }
    }
  }
}
```
I used a `for_each` in a dynamic block to dynamically create a `step` block for 
each step in the template file. 

## Values for template variables 
There are a couple of ways to pass along values for variables you might want to 
use in a Terraform template file. The first one is by passing values through the 
`templatefile()` function:
```
locals {
  # You can pass values for variables in the yaml config via the second 
  # parameter of the templatefile() function:
  simple_config_04 = yamldecode(templatefile("${path.root}/cloudbuild/04-multi-step-dynamic-with-vars.cloudbuild.yaml", { "variable_here" = "WORLD", "another_variable" = "MARS" }))
}
```

Here's the template file for reference:

```
# 04-multi-step-dynamic-with-vars.cloudbuild.yaml.tftpl
steps:
  - name: ubuntu
    args:
      - echo
      - hello ${variable_here} hey
  - name: ubuntu
    args:
      - echo
      - peace out ${another_variable}
timeout: 600s

```

This results in the following Cloud Build config inline:

```
steps:
  - name: ubuntu
    args:
      - echo
      - hello WORLD hey
  - name: ubuntu
    args:
      - echo
      - peace out MARS
timeout: 600s
```
If you want to use a built-in variable in this configuration, like 
`$PROJECT_ID` or `$SHORT_SHA` you have escape the `$` character by adding an 
extra `$` (eg: `$$PROJECT_ID` AND `$SHORT_SHA`)

## Using the `substitutions` parameter

A better option for passing values to variables is the substitutions parameter. 
To do this, I have to escape the `$` character where I want variables:

```
# 05-multi-step-dynamic-with-subs.cloudbuild.yaml.tftpl
steps:
  - name: ubuntu
    args:
      - echo
      - hello $${variable_here} hey
  - name: ubuntu
    args:
      - echo
      - peace out $${another_variable}
timeout: 600s
```
Now when I bring in the template I don't need to supply any values via the 
`templatefile()` function:
```
locals {
  # Pass no values to the templatefile() function:
  simple_config_05 = yamldecode(templatefile("${path.root}/cloudbuild/05-multi-step-dynamic-with-subs.cloudbuild.yaml.tftpl", {}))
}
```
I instead add values in the substitutions parameter:
```
resource "google_cloudbuild_trigger" "simple_inline_05" {
  project     = var.project_id
  location    = var.region
  name        = "05-multi-step-dynamic-with-subs"
  description = "This trigger is deployed by terraform, with an in-line build config."
  trigger_template {
    branch_name  = "^main$"
    invert_regex = false
    project_id   = var.project_id
    repo_name    = google_sourcerepo_repository.placeholder.name
  }
  build {
    images        = []
    # This is where you'll supply the values for your variables
    substitutions = {
      variable_here = "WORLD"
      another_variable = "MARS"
    }
    tags          = []
    # This is the same dynamic block used in trigger 03 and 04 above
    dynamic "step" {
      for_each = local.simple_config_05.steps
      content {
        args = step.value.args
        name = step.value.name
      }
    }
  }
}
```
And with that, a trigger will be configured with the following in-line 
configuration:

```
steps:
  - name: ubuntu
    args:
      - echo
      - 'hello ${variable_here} hey'
  - name: ubuntu
    args:
      - echo
      - 'peace out ${another_variable}'
timeout: 600s
substitutions:
  another_variable: MARS
  variable_here: WORLD
```

providing ad-hoc cloud build config via terraform

Cloud Build Trigger with Inline YAML via Terraform


![banner](/img/buildform.png)

CI/CD can get pretty complicated. There are a lot of moving pieces and a lot of automation. But as they say, the only way to eat an elephant is one bite at a time. So here’s a first nibble.
{/*more*/}

## How basic are we talking here?

We’re going to use Cloud Build to run Terraform for us in our Google Cloud Project. And when I say a *very basic example*, I mean a **very** basic example. This won’t be anything you’ll use in production, but this will be the start of a series of posts that build towards a more intricate solution, discussing some important concepts and considerations along the way.

## My friend Terraform and my buddy Cloud Build

Those already familiar with Terraform already know the 3 magic commands we use to deploy resources to Google Cloud, or any other cloud provider out there: `terraform init` to initialize, followed by `terraform plan` to preview, and `terraform apply` to deploy. Manually running these commands is useful for learning Terraform or managing your own personal infrastructure in the Cloud, but in practice you’re going to need to learn how to automate Terraform. Let some robots do it for you. There plenty of ways to do that. Using Cloud Build is just one.

Cloud Build is Google Cloud’s serverless CI/CD platform. You give it a yaml configuration with some instructions and it can build, test and deploy your software. I won’t get into any more details than that — [the documentation](https://cloud.google.com/build/docs) does a much better job than I can.

## Where to begin?

First you’ll need a directory to work out of (a root Terraform module) with 2 files in it (for now): `cloudbuild.yaml` and `main.tf`. You can go and create these yourself, or just clone [this branch in this repository](https://github.com/rogerthatdev/cloud-build-terraform/tree/v1) that has the files already pre-written for you.

You’ll also need a Google Cloud Project with the [Cloud Build API](https://console.cloud.google.com/apis/library/cloudbuild.googleapis.com) enabled. When you enable the Cloud Build API, your project will generate a default Cloud Build service account that looks like this:

`98476438052@cloudbuild.gserviceaccount.com`

This service account automatically has the Cloud Build Service Account IAM role assigned to it, allowing it to do all the Cloud Build things it needs to be able to do, like manage Google Cloud Storage buckets and access Artifact Registry. You can see a full list of permissions [right here](https://cloud.google.com/build/docs/cloud-build-service-account#default_permissions_of_service_account).

## Tell Terraform what to do

Terraform gets its instructions from `.tf` files. For the sake of simplicity, let’s use this `main.tf` file I copied and pasted from one of [Hashicorp’s documentation pages](https://registry.terraform.io/providers/hashicorp/random/latest/docs/resources/string):

```
# main.tf 

resource "random_string" "random" {
  length           = 16
  special          = true
  override_special = "/@£$"
}

output "random_string" {
    value = random_string.random.id
}
```

There’s nothing fancy to see here. It just creates a random string resource and spits its value out as output.

## Tell Cloud Build what to do

Cloud Build accepts yaml configuration files. Here is a simple one that will execute those 3 magic Terraform commands:

```
# cloudbuild.yaml

steps:
  - id: 'terraform init'
    name: 'hashicorp/terraform:1.0.0'
    script: terraform init
  - id: 'terraform plan'
    name: 'hashicorp/terraform:1.0.0'
    script: terraform plan
  - id: 'terraform apply'
    name: 'hashicorp/terraform:1.0.0'
    script: terraform apply --auto-approve
```

The id field is the name that will show up in the logs, and the name field is the public image that it will build and use to execute the provided command.

You can kick off a Cloud Build job by running `gcloud builds submit .` in your working directory. It will automatically look for a `cloudbuild.yaml` file and create a Cloud Build job that will execute the provided instructions. You can see the progress as output in your terminal or head over the [Cloud Build History page](https://console.cloud.google.com/cloud-build/builds) where you’ll see your job’s status and output:

![screenshot of build details](/img/builddetails.png)

And there you have it! Cloud Build executing Terraform! That’s all there is to it!

## Wait a second, there must be more to it

Okay, actually there’s a lot more to it. While we did indeed run Terraform with Cloud Build we didn’t actually deploy any infrastructure (or anything useful for that matter). There are some things that we need to consider.

## Permissions

Cloud Build creates a default service account with [those default Cloud Build service account permissions](https://cloud.google.com/build/docs/cloud-build-service-account#default_permissions_of_service_account) assigned to it. Any additional permissions that this service accounts needs will depend on the cloud resources that you want your Terraform to create. If you’re managing resources across lots of different Google Cloud services, then the Cloud Build service account will inevitably accumulate excessive permissions, resulting in a potential security risk. Yuck.

## Terraform state file

You’ll notice that the Terraform state file is no where to be found. The state file that would have been generated to your local disk had you ran `terraform` apply locally only existed temporarily in the container that Cloud Build ran the command from. If this Terraform had created a cloud resource, you would have no way to update its parameters using a second `terraform apply` or destroy it using `terraform destroy`. Ugh.

## That `--auto-approve` flag

If this were an automated pipeline, we probably wouldn’t be running `apply` automatically after `plan`. Without approvals, reviews, or staging environments in place, we can’t really make sure our infrastructure doesn’t fall apart after each terraform job. Yikes.

## Key takeaways

- Enabling the Cloud Build API will create a default Cloud Build service account in your project. Cloud Build jobs run using this service account by default.
- Cloud Build’s instructions are provided as steps listed in a yaml file, each one with it’s own output that show up in the build logs. If the Terraform creates any cloud resources, the service account will need the appropriate permissions to manage those resources.
- Without any remote state configured, the state file will only exist temporarily and then get lost in the abyss.

## Well, what next?

While limited in its utility, this example can serve as a starting point for your own exploration around the considerations I mentioned above. Service account impersonation will definitely play a role in ironing out the permissions (here’s a blog about Terraform and service account impersonation I published [here](https://cloud.google.com/blog/topics/developers-practitioners/using-google-cloud-service-account-impersonation-your-terraform-code)), while Terraform’s support for [remote state files on Google Cloud Storage](https://developer.hashicorp.com/terraform/language/settings/backends/gcs) will give us the persistent state that we need to keep our infrastructure updated safely. As for the lack of approvals and reviews, there are unlimited ways to design your pipeline to accommodate such requirements with features like [gating builds on approvals](https://cloud.google.com/build/docs/securing-builds/gate-builds-on-approval). I won’t leave you high and dry though. I will post a follow up soon with another bite of our elephant for us to explore.

Cloud Build Trigger with Inline YAML via Terraform

Terraform using Google Cloud Build