v1.3.6

🚀 Enhancements

Run `terraform init -reconfigure` when running `terraform workspace`. Fix infrastructure stack name in Spacelift processor @aknysh (#75)

what

• Run terraform init -reconfigure when running terraform workspace
• Fix infrastructure stack name in Spacelift processor

why

• When running terraform workspace in Spacelift, it requires to run terraform init, otherwise the following error gets thrown

│ Error: Backend initialization required, please run "terraform init"
│ 
│ Reason: Initial configuration of the requested backend "s3"

• The Spacelift infrastructure stack name (which is used as Spacelift ENV var ATMOS_STACK) is in the format {tenant}-{environment}-{stage}, the component name was appended to it by mistake

v1.3.5

🚀 Enhancements

Fix `terraform import` command. Add `terraform clean` command. Update spacelift processor @aknysh (#73)

what

• Fix terraform import command
• Add terraform clean command
• Update spacelift processor to use logical stack names and find all top-level stacks automatically by using atmos.yaml CLI config

why

• varfile was generated, but terraform import did not use the generated varfile in --var-file
• terraform clean command deletes varfile, planfile, .terraform folder, '.terraform.lock.hcl' file, and the folder that TF_DATA_DIR ENV variable points to (usage: atmos terraform clean <component> -s=<stack>)
• Make the Spacelift processor use the logical stack names (derived from the context) to generate Spacelift stack names and Spacelift folders. Support stack and component folders, tenant (and all attributes from the context), and complex imports (Globs, folders in imports). Make the Spacelift processor use atmos.yaml CLI config to be able to find all top-level stacks automatically. Maintain backwards compatibility with the old Spacelift stack processor logic (where a list of stack config files was provided).

references

• https://www.terraform.io/docs/cli/config/environment-variables.html#tf_data_dir

related

• Closes #70

terraform clean test

Deleting '.terraform' folder
Deleting '.terraform.lock.hcl' file
Deleting terraform varfile: tenant1-ue2-dev-test-component-override.terraform.tfvars.json
Deleting terraform planfile: tenant1-ue2-dev-test-component-override.planfile
Found ENV var TF_DATA_DIR=./test
Do you want to delete the folder './test'? (only 'yes' will be accepted to approve)
Enter a value: yes
Deleting folder './test'

v1.3.4

🚀 Enhancements

Add `--from-plan` flag to terraform apply/deploy commands. Add `describe config` CLI command @aknysh (#71)

what

• Add --from-plan flag to terraform apply/deploy commands
• Add describe config CLI command

why

• Allow using terraform planfile (previously generated with atmos terraform plan) in atmos terraform apply/deploy commands

atmos terraform plan test/test-component-override -s tenant1/ue2/dev
atmos terraform apply test/test-component-override -s tenant1-ue2-dev --from-plan
atmos terraform deploy test/test-component-override -s tenant1-ue2-dev --from-plan

• describe config command shows CLI configuration, processed and deep-merged from these locations

- system dir (`/usr/local/etc/atmos/atmos.yaml` on Linux, `%LOCALAPPDATA%/atmos/atmos.yaml` on Windows)
- home dir (~/.atmos/atmos.yaml)
- `atmos.yaml` in the current directory

atmos describe config -help
atmos describe config

atmos describe config --format=json
atmos describe config --format json
atmos describe config -f=json
atmos describe config -f json

atmos describe config --format=yaml
atmos describe config --format yaml
atmos describe config -f=yaml
atmos describe config -f yaml

references

• cloudposse/geodesic#734 (comment)

v1.3.3

🚀 Enhancements

Move packages from `internal` to `pkg` folder @aknysh (#69)

what

• Move packages from internal to pkg folder

why

• Use the packages in other projects (e.g. terraform-provider-utils)
• Packages in internal folder are private and not visible to other repos

v1.3.2

🚀 Enhancements

Update stack processor @aknysh (#68)

what

• Update stack processor
• Cache the YAML file contents and Glob matches in memory (sync map)

why

• Prevent concurrency issues when many gorotines call Glob to find import matches in the same folders
• Speed it up, especially when working on localhost and reading the YAML config files on the host from a Docker container (don't read the same files and the same glob matches more than once)
• The total speed up is about 10-20x

v1.3.1

🚀 Enhancements

Update `auto-release.yml` @aknysh (#67)

what

• Update auto-release.yml

why

• If we use the atmos modules in other repos (e.g. terraform-provider-utils, the release tag require v in the tag names, see https://golang.org/ref/mod#versions

1.3.0

Improvements and new features @aknysh (#66)

what

• Improvements and new features

why

• For terraform commands, put the additional arguments and flags at the end of the command. This allows to use, for example, -var=service_1_name=service-1-override-3 to override the variables defined in terraform and YAML config

atmos terraform deploy top-level-component1 -s tenant1/ue2/dev -var=service_1_name=service-1-override-3

• Add flags and logic to auto generate TF backend file

Writing backend config to file:
./examples/complete/components/terraform/test/test-component/backend.tf.json

Controlled by the CLI config:

    # Can also be set using `ATMOS_COMPONENTS_TERRAFORM_AUTO_GENERATE_BACKEND_FILE` ENV var, or `--auto-generate-backend-file` command-line argument
    auto_generate_backend_file: false

• Add remote_state_backend and remote_state_backend_type YAML config sections. They can be used to specify a different backend (different attributes, or even a completely different backend type) for remote state. It's useful for the privileged components where we use different attributes (e.g. role_arn or profile) during the cold-start and during the normal operations to get the remote state of the privileged components

      # Override backend for this component
      backend_type: static # s3, remote, vault, static, etc.
      backend:
        static:
          val1: 1
          val2: "2"
          val3: true
          val4: ""
          val5: null
      # Override remote state backend for this component
      remote_state_backend_type: static # s3, remote, vault, static, etc.
      remote_state_backend:
        static:
          val1: 1
          val2: "2"
          val3: true
          val4: ""
          val5: 5

The new remote_state_backend section in YAML is similar to the backend section - you can specify it in globals, stage globals, or override per component (which all gets deep-merged into the final remote state backend for the component). The two sections are separate and the attributes from them are not merged together

1.2.5

🚀 Enhancements

Update modules @aknysh (#65)

what

• Update modules

why

• The provider was using the atmos code but was modified in cloudposse/terraform-provider-utils#62 - sync atmos and utils provider

v1.2.4

🚀 Enhancements

Fix `goreleaser` @aknysh (#64)

what

• Fix goreleaser

why

• After updating the module name in go.mod to github.com/cloudposse/atmos (which is needed to be able to import atmos public packages in other repos), Go ldflags needs to be updated to use the full path github.com/cloudposse/atmos/cmd.Version to correctly update the CLI version during build

v1.2.3

🚀 Enhancements

Use format `v$MAJOR.$MINOR.$PATCH` for auto-release tags. Move public packages from `internal` folder @aknysh (#63)

what

• Use format v$MAJOR.$MINOR.$PATCH for auto-release tags
• Move public packages from internal folder

why

• Go mod requires a version number that starts with a v

A version identifies an immutable snapshot of a module, which may be either a release or a pre-release. 
Each version starts with the letter v, followed by a semantic version. 

• We need to import some atmos packagesintoterraform-provider-utils`, but Go "internal" packages can't not be imported by packages outside the source subtree in which they reside

To create such a package, place it in a directory named internal or in a subdirectory 
of a directory named internal. 
When the go command sees an import of a package with internal in its path, 
it verifies that the package doing the import is within the tree rooted 
at the parent of the internal directory

references

• https://golang.org/ref/mod#versions
• https://golang.org/doc/go1.4#internalpackages
• https://dave.cheney.net/2019/10/06/use-internal-packages-to-reduce-your-public-api-surface