Bug introduced in 2.2.0? Tfvars Processing

Terraspace
,
1

Hi

We seem to be hitting an issue with an erb templated tfvars file that we didn’t have previously in 2.1.7.

We now get the following output from a plan:

NameError: undefined local variable or method `customer_name' for 

 #<Terraspace::Compiler::Erb::Context:0x000055fd14cf91c8>
 Did you mean?  customer_settings                                                                                                                                                                                        
 Error evaluating ERB template around line 11 of: /tmp/terraspace/rewrite/app/stacks/0001b-pre_reqs/tfvars/base.tfvars:
 6   ############################
 7   # Loop - for each environment  block
 8   ############################
 9   <%# customer_data['environments']&.each do |environment_name, environment_data| %>
 10
 11     account_id_<%= customer_name %>_<%= environment_name %> = <%= output("0001a-account_factory.account_id_#{customer_name}_#{environment_name}") %>
 12                                                                                                                                                                                                                      
 13   ############################
 14   # End Loop - for each environment  block #
 15   ############################
 16   <%# end %>

Compared to a working plan in 2.1.7

The code for the base.tfvars that it is trying to render is:

############################
\# Loop - for each customer block 
############################

<% deployment_settings['accounts']&.each do |customer_name, customer_data| %>

  ############################
  \# Loop - for each environment  block 
  ############################
  <% customer_data['environments']&.each do |environment_name, environment_data| %>

    account_id_<%= customer_name %>_<%= environment_name %> = <%= output("0001a-account_factory.account_id_#{customer_name}_#{environment_name}") %>

  ############################
  \# End Loop - for each environment  block
  ############################
  <% end %>

############################
\# End Loop - for each customer block
############################
<% end %>

As you can see, the variable customer_name clearly comes from the
<% deployment_settings['accounts']&.each do |customer_name, customer_data| %>
line but in the trace, the erb “each” statements are remarked.

Regards
Martyn

2

I see. This is due to a tfvars processing optimization introduced in 2.2

Released a fix by adding a config.build.dependency_words setting so folks can go back to the previous unoptimized behavior if needed.

In short, adding this should fix the issue for you

config/app.rb

Terraspace.configure do |config|
  config.build.dependency_words = "*"
end
3

Wow! Amazing turnaround @tung!
I’ll try that now.

4

That works perfectly. Thanks @tung.

On a separate note, as a consequence of this bug I tried running an older version of terraspace however, I noticed that, when I went to create a new project it automatically installed the latest gem for terraspace?

Is there a way around this as? I’m thinking of a situation where there is an issue preventing us using a version need to run an old version (very temporarily in this case). As we’re using Azure build agents, the projects are recreated and then the project content pulled in.

Are there any flags that we can set to ensure it creates the project with a specific version?

Regards
Martyn

5

Yes. When generating a new project, it’ll pin Terraspace to the latest version in the Gemfile. No current flags to set a specific terraspace version in the generated Gemfile. Unsure if an option is worth for a specific terraspace version makes sense right now :man_shrugging:t2:

You could rewrite the generated Gemfile to pin the terrapspace version specifically required. Example:

Gemfile

source "https://rubygems.org"
gem "terraspace", "2.2.2"

You should also make sure that the version in the Gemfile with either a terraspace shim or prepending bundle exec

6

I suspect that as long we can switch the version back it doesn’t overly matter. I might have to add some code to our pipelines to rewrite the Gemfile and then bundle exec but am happy it’s working.

Thanks
Martyn