1

I understand that CI/CD variables can be used in HCL by counting on the fact that having them declared them with a TF_VAR_ prefix in the environment will enable me to look them up as input variables, then use them in the .tf file where I need them.

I did:

  • set my variable via the UI in the GitLab project, as TF_VAR_ibm_api_key, then masked it.
  • write a variable block for it in main.tf
  • call it where I need it in the same file main.tf
  • tried including the variable in variables.tf, same result
  • read the documentation from gitlab and from terraform, but I'm not getting this right.

This is my main.tf file:

variable ibm_api_key {
}

terraform {
  required_version = ">= 0.13"
required_providers {
    ibm = {
    source = "IBM-Cloud/ibm"
    }
 }
}

provider "ibm" {
  ibmcloud_api_key = var.ibm_api_key
}

Expected behavior: the variable is passed from the CI/CD and added to the HCL code.

Current behavior: during ´plan´, the job falls with error code 1

$ terraform plan
var.ibm_api_key
  Enter a value: ╷
│ Error: No value for required variable
│ 
│   on main.tf line 1:
│    1: variable ibm_api_key {
│ 
│ The root module input variable "ibm_api_key" is not set, and has no default
│ value. Use a -var or -var-file command line argument to provide a value for
│ this variable.
╵

  • although logically it can't seem to be the issue, I tried formatting the variable call as string interpolation, like:

    provider "ibm" { ibmcloud_api_key = "${var.ibm_api_key}" } naturally to no avail.

  • although logically it can't seem to be the issue, I tried defining a type for the variable:

    variable ibm_api_key { type = string } naturally to no avail.

  • In order to check if variables are passed from the CI/CD settings to the gitlab runner's environment, I added a variable that is neither protected nor masked, and assigned string inserted a double check:

    • echo ${output_check}
    • echo ${TF_VAR_ibm_api_key}

which does not result in an error, but are not being printed either. Only the "echo" commands appear in the output.

$ echo ${output_check}
$ echo ${TF_VAR_ibm_api_key}
Cleaning up project directory and file based variables 00:01
Job succeeded
WildWilyWilly
  • 121
  • 11
  • 1
    So if you were to echo that variable before running `terraform plan`, would it display anything? Of course, don't post it here. – Marko E Oct 16 '22 at 09:41
  • 1
    `variable "ibm_api_key" is not set` means that Terraform can't read `TF_VAR_ibm_api_key` environment variable. The problem is most likely inside Gitlab CI/CD configuration. Try to run simple bash script `echo ${TF_VAR_ibm_api_key}` and check if env is accessible. In other way you may try to add var type `variable ibm_api_key { type = string }`, but I not sure if that is causing the problem – rzlvmp Oct 16 '22 at 12:09
  • I followed rzlvmp's suggestion and published its result. The problem was elsewhere but it was useful advice nonetheless -- I had already done it but didn't specify it – WildWilyWilly Oct 17 '22 at 08:19

2 Answers2

5

Providers typically have intrinsic environment variables configured in their schema and/or associated bindings for authentication. This situation is, according to the provider authentication documentation, no different. You can authenticate the provider with an IBM API key from the GitlabCI project environment variables settings with:

IAAS_CLASSIC_API_KEY="iaas_classic_api_key"
Matthew Schuchard
  • 25,172
  • 3
  • 47
  • 67
1

The error was in the CI/CD settings. The variables were set to be exclusively passed to protected branches. I was pushing my code to an unprotected one, which prevented variables being passed. When merging the code to a protected branch, the variables showed up correctly. Variables are also correctly imported to Terraform, with the expected exclusion of the TF_VAR_ prefix.

TL;DR If you're having this issue in GitLab's CI/CD check your CICD variables' setting for protected branches, and if the branch you're pushing to corresponds to that setting.

WildWilyWilly
  • 121
  • 11