Testing Terraform Providers Written in Go

Situation

In a previous article, I walked through setting up my environment to publish a Terraform HCX provider written in Go. In this article, I will dive into how to test changes made to the provider.

Task

Build and test a Terraform provider without publishing it to the Terraform registry. You do not want to publish a new version unless you are sure it is production-ready. It is not possible to delete a build from the Terraform registry without opening a support ticket.

I found the documentation on how to do this a bit confusing. This article details how I got everything working. You create a terraform.rc file to instruct Terraform to look somewhere other than the Terraform registry for a specific build.

Actions

1. Locate the correct folder to place terraform.rc. On Windows, you place it in your %APPDATA% directory. On Linux/Mac, you place it in your user account home folder.
2. Build the configuration

The filesystem mirror instruction tells Terraform to look for the binaries on your local workstation instead of the Terraform registry. On Linux/Mac, the file path uses standard /folder/path notation. On Windows, you have to escape the backslash as shown below.

The direct instruction tells Terraform to look at the Terraform registry for any other providers.

provider_installation {
  filesystem_mirror {
	path =  "C:\\users\\kremerpt\\git\\VMware\\terraform-provider-hcx"
	include  = ["registry.terraform.io/kremerpatrick/hcx"]
  }
  
  direct {
	include = ["registry.terraform.io/*/*"]
  }
}

3. Create a directory structure mirroring the Terraform registry. You can check your current OS and architecture with the following commands:

C:\Users\kremerpt\git\VMware\terraform-provider-hcx [main ≡ +1 ~2 -0 !]> go env GOOS
windows
C:\Users\kremerpt\git\VMware\terraform-provider-hcx [main ≡ +1 ~2 -0 !]> go env GOARCH
amd64

A go build command on my system will by default build a windows/amd64 binary.

Underneath the path that I configured in terraform.rc, I need to build out the following path: registry.terraform.io\kremerpatrick\hcx\0.4.6\windows_amd64. If my testing is successful, I will publish the binary as version 0.4.6, so I used that version in my folder structure.

4. Build the binary

I now need to build the binary - I place it in the correct folder and I make sure to use the naming convention that Terraform is expecting.

go build -o .\registry.terraform.io\kremerpatrick\hcx\0.4.6\windows_amd64\terraform-provider-hcx_v0.4.6.exe

5. After updating versions.tf to point to the newly built provider version, run terraform init

I expect this to look different from normal because I am not using a signed binary - the output shows that I installed an unauthenticated binary, but Terraform did accept it.

Initializing provider plugins...
- terraform.io/builtin/terraform is built in to Terraform
- Finding hashicorp/vsphere versions matching ">= 2.6.0"...
- Finding latest version of hashicorp/time...
- Finding kremerpatrick/hcx versions matching "0.4.6"...
- Finding terraform-providers/vmc versions matching "1.13.1"...
- Installing kremerpatrick/hcx v0.4.6...
- Installed kremerpatrick/hcx v0.4.6 (unauthenticated)

6. Perform testing, validate that the provider performs as expected.

7. If successful, after publishing the latest version to the Terraform Registry, remember to remove the filesystem mirror instruction from terraform.rc. Otherwise, you will continue to pull from your local filesystem.

Result

I was able to test a new version of the provider without publishing a version that may not be production-ready.