support non-cloud providers and backends

[tongueroo]

• decouple backend detection from plugins
• expander backend detection that doesn't evaluate ERB

This is a 🐞 bug fix.
This is a 🙋‍♂️ feature or enhancement.
This is a 🧐 documentation change.

• I've added tests (if it's a bug, feature or enhancement)
• I've adjusted the documentation (if it's a feature or enhancement)
• The test suite passes (run bundle exec rspec to verify this)

Summary

Support for non-cloud providers and backends by decoupling the backend detection from terraspace plugins. The backend detection is simpler and will not run ERB on the detection pass. With the normal compile pass, it will run ERB.

Context

• Fixes [Documentation needed] Need help around using env variable for backend.tf for terraspace init #160
• Fixes Terraspace does not work for non-cloud providers #131
• Fixes terraspace init complains about backends (http) #132
• Related docs PR: backend examples terraspace-docs#21

Seems like folks are using the gitlab backend.

This allows folks to use the http backend or any other backend https://www.terraform.io/language/settings/backends/local

How to Test

Use a backend example like what @yisyang provided in #160 (comment) and @Grummfy boltops-tools/terraspace-docs#16 Example:

config/terraform/backend.tf:

terraform {
  backend "http" {
    address        = "<%= ENV['GITLAB_PROJECT_URL'] %>/<%= expansion(":ENV-:TYPE_DIR-:MOD_NAME") %>"
    lock_address   = "<%= ENV['GITLAB_PROJECT_URL'] %>/<%= expansion(":ENV-:TYPE_DIR-:MOD_NAME") %>/lock"
    unlock_address = "<%= ENV['GITLAB_PROJECT_URL'] %>/<%= expansion(":ENV-:TYPE_DIR-:MOD_NAME") %>/lock"
    username       = "<%= ENV['GITLAB_USER'] %>"
    password       = "<%= ENV['GITLAB_ACCESS_TOKEN'] %>"
    lock_method    = "POST"
    unlock_method  = "DELETE"
    retry_wait_min = 5
  }
}

You can set the env var defaults with the config/boot.rb hook.

config/boot.rb:

ENV['GITLAB_PROJECT_ID']   ||= 'your project id'
ENV['GITLAB_USER']         ||= 'gitlab-user'
ENV['GITLAB_ACCESS_TOKEN'] ||= 'gitlab-api-access-token'
ENV['GITLAB_PROJECT_URL']    = "https://gitlab.com/api/v4/projects/#{ENV['GITLAB_PROJECT_ID']}/terraform/state"

Note: Using :ENV-:TYPE_DIR-:MOD_NAME which includes env, stacks/modules as a prefix in the state path name to generalize. If you're sure that you're not going to be deploying app/modules directly, you can use the simpler :ENV-:MOD_NAME. Though like the shorter path, showing the generalized one just in case and to avoid possible people in the future venting 🤣 It does not include region because the http backend results in a generic expander being used. Once this is released and docs are merged in also, there is an example of how you add the region in the docs. You can also see this PR: boltops-tools/terraspace-docs#21 right now.

Example of state files on GitLab:

For backend variables, see: https://terraspace.cloud/docs/config/backend/variables/

Also, notice instead of the use of - instead of /. This is because the GitLab http backend urls are resource urls. Using / will mean a different url resource. So we have to use -. IE: :ENV-:TYPE_DIR-:MOD_NAME vs :ENV/:TYPE_DIR/:MOD_NAME

• GitLab Docs: GitLab managed Terraform State

Local Backend

Also, tested with local backend. Here's an example:

config/terraform/backend.tf

terraform {
  backend "local" {
    path = "<%= expansion('.terraform/state.tfstate') %>"
  }
}

The local statefile is stored at:

ls .terraspace-cache/dev/stacks/demo/.terraform/state.tfstate

Docs for this will also be in this docs PR boltops-tools/terraspace-docs#21

Version Changes

Minor