RE: This is interesting, as I figured TFC being a remote build box would not pass that from the local machine to the remote machine. I will test this out and report back.
It’s good that you double-checked. I tested incorrectly. Think was reusing the TFC project which already had the GOOGLE_CREDENTIALS set from previous runs. 
Using the CLI-workflow doesn’t magically somehow pass the application_default_credentials.json. For TFC, you pretty much have to set GOOGLE_CREDENTIALS.
RE: TS_ENV=global vs TS_ENV=dev and ignore stacks
One way to handle this is to set the config.all.ignore_stacks setting:
config/env/dev.rb
Terraspace.configure do |config|
config.all.ignore_stacks = [“stack1”, “stack2”]
end
config/env/global.rb
Terraspace.configure do |config|
config.all.ignore_stacks = [“stack3”, “stack4”]
end
Docs: Config Reference - Terraspace
Note, there are ways to remove the duplication for dev.rb and prod.rb with ruby. Just explaining the concept for now.
- There’s also the
config.all.include_stacksoption. See: Add all.include_stacks option and fix all.ignore_stacks option when building dependency graph by tongueroo · Pull Request #85 · boltops-tools/terraspace · GitHub - Also, another improvement that will added is to be able to reference outputs from stacks of different envs.
This post discusses it Prevent modules to be deployed in one environment - #2 by tung
RE: I just stumbled upon the documentation for Multiple Provider Configurations within Terraform itself. This might help solve a major chunk of the multi-region stuff.
Yup, it’s possible to use provider aliases for multi-regions. In that case, the GOOGLE_REGION env var won’t matter because the regions are more “hardcoded”. There are trade-offs worth noting. While it’s pretty cool that both regions can be deployed with a single terraform apply, they’re coupled. So if you deploy 1 region, you must deploy both. If one region is down, the terraform apply would fail. You could use a variable to control the regions, but the code gets more complicated.
Terraspace allows you to deploy to each region independently. Generally, prefer the ability to be able to deploy to each region independently. And to have a higher-level script to deploy to both at the same time. So you get the best of both worlds. Ultimately, it’s up to you on which approach you think is a better fit for your needs. Often, the quickest way to reach a decision is to build a minimal project and try it out.