We would like to run terraform test inside a Terraform Cloud workspace.
Whilst plan and apply work fine, it looks like test is treated differently, and errors out complaining about missing provider credentials. This makes me think it’s not running in the workspace, but rather on my machine (which indeed does not have the provider credentials configured).
I saw that there is a way to configure tests for private registries, but this doesn’t suit us for two reasons: (a) We are moving our modules from private to public, to share with the community. (b) The registry still wouldn’t have access to the provider credentials.
What we need is a way to force terraform test to run inside a workspace. Is this possible?
Hi @afrazo, unfortunately there is currently no way to trigger Terraform test runs against Terraform Cloud workspaces.
terraform test isn’t well suited to executing against workspaces because the provider credentials would be shared with your live infrastructure that would mean the test might interfere with your production services. Within a workspace you have long running infrastructure, while the testing framework is designed to create and destroy infrastructure in isolation.
Note, that it is possible to upload environment variables and Terraform variable definitions for tests within the private registry so you might be able to supply provider credentials that way.
You could submit a feature request for this via Github, highlighting how you’d imagine terraform test would work within a workspace without sharing credentials with production infrastructure.
We’ve actually provisioned accounts solely for this purpose, so we wanted the CRUD operations to happen there. I’ll describe it more by submitting a feature request, you suggested.
Couple of questions though:
It sounds like the testing framework would still need credentials to somewhere, so I’m not sure what the difference would be in the workspace doing it, and the testing framework doing it?
We’re open sourcing our modules, and have moved them to the public registry. Will what you suggested only work in a private registry?
It sounds like the testing framework would still need credentials to somewhere, so I’m not sure what the difference would be in the workspace doing it, and the testing framework doing it?
The private registry functionality exists for maintaining and publishing providers and modules, while the workspaces are designed to hide away the complexities of state management and provide additional features around the long term maintenance of long running infrastructure. The testing framework itself is mainly targeted towards modules, allowing module authors to test their modules in a more targeted way than simply building another Terraform configuration that uses them.
With that in mind, we launched the testing integration into the private registry and not workspaces. Our recommendation for testing long running infrastructure is to maintain a testing or development environment that matches the production environment and deploy changes into the testing environment first. The testing framework isn’t particularly suited to the kind of incremental changes that typically get deployed via workspaces.
Within the private registry you should be able to provide credentials and variables to the test command in the same way as workspaces provide credentials to the plan and apply commands that they execute.
We’re open sourcing our modules, and have moved them to the public registry. Will what you suggested only work in a private registry?
Yes, we haven’t added support for testing to the public registry.
Note, that Terraform Cloud workspaces and the public registry are also not integrated. I think it sounds like your plan would to be create a dedicated workspace for executing the test files (if that were supported) while separately publishing the modules into the public registry. You should be able to take this same approach within the private registry, with publishing your modules to a private registry first (with tests executing), then once the private registry has deployed them with tests passing, separately deploy them to the public registry.
I would agree that this isn’t ideal, and in a perfect world the public registry would be able to execute the tests as well as the private registry. This is something to bring up in a feature request, we can use that as a signal to increase priority for this internally. Getting feature requests directly from users is a way for us to see and measure the demand for a given feature before committing to working on it.
Hopefully that has cleared things up! Happy to answer any other questions!