Use "../" for source value when testing

Terraform Terraform Cloud & Enterprise
#1

Although I have been using terraform for several years, I am just starting out using terraform cloud and update/test cycle seems overly complicated.
What I have gleaned is to update the code for an existing version is:

  1. remove the tag from github.com
  2. delete the module version from app.terraform.io
  3. remove the tag from my local repo
  4. publish the local changes to github
  5. add a local tag
  6. push the tag to github

I have to do these 6 steps every time I make any change, and want to test the change.
if i could use “…/” for my source instead of “app.terraform.io/myorg/mymodule/myprovider”
i could iterate the code/test cycle much faster.

Or is there a better way?

granted, once I have the module the way i want it, i could publish a version for good.

#2

You are never supposed to change what an existing version/tag points to - ever.

Versions being immutable is core to their very purpose and part of the implied contract between publisher and consumer.

You can. This is the correct approach.

(Though you have three dots not two here.)

#3

Hi @DonBower,

If you are asking about shared modules (as opposed to the root modules you would specify directly in workspace settings) then a pattern I would recommend is:

Inside the repository where you keep your module code, create a tests subdirectory.

Inside that directory, make one or more subdirectories representing different scenarios you need to test. For example, if your module has an option to enable or disable part of its functionality, you might have one scenario for it being enabled and another for it being disabled.

Inside each test scenario directory, write a module block with source = "../../" to refer to the shared module you are trying to test

Now you can test by applying each of your test scenarios:

  • terraform -chdir=tests/example init
  • terraform -chdir=tests/example apply
  • terraform -chdir=tests/example destroy

If you want to test how your module responds to a change then you can apply first before you make the change to establish a baseline state, then change the module and apply again to see the plan to update the existing objects.

This pattern will keep all of your test cases contained within your module’s own repository so that you can develop and test it independently of any workspace that might be using it, and so you can test it before you publish it in the registry.

#4

Thank you sir. This works out perfect.
I just need the workspace setup for local execution otherwise i get an AWS authentication error.