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

1.2.2

🚀 Enhancements

Fix `go.mod` module name. Make all imports absolute paths @aknysh (#62)

what

• Fix go.mod module name
• Make all imports absolute paths
• Fix test

why

• To be able to import modules from atmos in other Go repos (e.g. terraform-provider-utils)
• Otherwise, the following errors gets thrown

module declares its path as: atmos
          but was required as: github.com

1.2.1

🚀 Enhancements

Update stacks processor @aknysh (#59)

what

• Update stacks processor

why

• Correctly handle the case when the provided stack name matches not only a top-level YAML config file, but also a file in the (excluded) catalog (it was finding the matching catalog file (by the suffix) and then throwing the error that the stack does not exist). Now it correctly excludes all the paths defined in excluded_paths CLI config. In the stack config in the image below, atmos terraform plan test/test-component-override -s=tenant1-ue2-dev correctly excludes the file tenant1-ue2-dev.yaml in the catalog and only finds the file tenant1/ue2/dev.yaml as the top-level stack

• Process all imports in the order they are defined. Don't process imports concurrently in gorotines since the behaviour is not deterministic (whatever gorotine finishes last, the result of its import processing will be used as the final result in deep-merging). Using concurrent execution with gorotines makes it marginally (not noticeable) faster, but makes the final deep-merged result unpredictable. Now these imports

import:
  - globals/tenant1-globals
  - globals/ue2-globals
  - catalog/terraform/top-level-component1
  - catalog/terraform/test-component
  - catalog/terraform/test-component-override
  - catalog/terraform/vpc
  - catalog/terraform/tenant1-ue2-dev

vars:
  stage: dev

are processed in the same order as they are defined, and the final result for a variable is always taken from the last import catalog/terraform/tenant1-ue2-dev

1.2.0

Improvements and new features @aknysh (#58)

what

• Improvements and new features

why

• atmos terraform apply made 100% compatible with terraform apply:

  • does not run terraform plan
  • atmos terraform apply does not use planfile (by default)
  • atmos terraform apply will ask for the confirmation to apply
  • atmos terraform apply -auto-approve will apply without asking for the confirmation to apply
  • The above behavior can be overridden. If apply_auto_approve config (or ENV var ATMOS_COMPONENTS_TERRAFORM_APPLY_AUTO_APPROVE ) is set to true, atmos terraform apply will not ask for the confirmation to apply regardless of whether the -auto-approve is specified or not

• atmos terraform deploy:

  • behaves like atmos terraform apply -auto-approve
  • does not run terraform plan
  • If deploy_run_init config (or ENV var ATMOS_COMPONENTS_TERRAFORM_DEPLOY_RUN_INIT, or --deploy-run-init command-line argument) is set to true, atmos terraform deploy will first run terraform init to initialize modules. Otherwise, it will not run terraform init, and atmos terraform init will need to be run first at least once

  ATMOS_COMPONENTS_TERRAFORM_DEPLOY_RUN_INIT=false atmos terraform deploy top-level-component1 -s tenant1-ue2-dev
  ATMOS_COMPONENTS_TERRAFORM_DEPLOY_RUN_INIT=true atmos terraform deploy top-level-component1 -s tenant1-ue2-dev
  

  atmos terraform deploy top-level-component1 -s tenant1/ue2/dev --deploy-run-init=false
  
  Using command line argument '--deploy-run-init=false'
  

  ATMOS_COMPONENTS_TERRAFORM_DEPLOY_RUN_INIT=false atmos terraform deploy top-level-component1 -s tenant1/ue2/dev --deploy-run-init=true
  
  Found ENV var ATMOS_COMPONENTS_TERRAFORM_DEPLOY_RUN_INIT=false
  Using command line argument '--deploy-run-init=true'
  

• Log level control:

  • If ENV var ATMOS_LOGS_VERBOSE is set to false (default), the CLI will not print all the information about the config, stacks and component (and how it searches them), but will just output the essential info for each command

    ATMOS_LOGS_VERBOSE=true atmos terraform deploy top-level-component1 -s tenant1-ue2-dev
    

• Check if terraform commands require user interaction, but running in a scripted environment (where a tty is not attached or stdin is not attached)

• Use logical context to generate terraform workspaces and file names for planfile and varfile:

  • Instead of using the physical paths derived from the provided stack names to generate terraform workspaces and the names of planfile and varfile (which the old variant-based atmos did as well), find the logical context for the specified component in the specified stack (from the deep-merged vars). The logical context consist of tenant (if used), environment and stage, and is controlled by the name_pattern: "{tenant}-{environment}-{stage}" CLI config
  • This makes it completely independent of the folder structure where the YAML stack config files are defined - don't use the physical structure, look at the logical structure
  • Bonus:
    • You will be able move around the top-level YAML config files (that are not imported into other stacks) to any folder at any level (under stacks parent folder) "on-the-fly" , or change the names of the folders, WITHOUT needing to change anything - terraform workspace remains the same, the CLI will find the context from the deep-merged vars, and it just works
    • You can also move around the YAML config files even if they are already imported into other stacks, you will just need to update the import paths, but all CLI commands will continue working without making any changes to terraform state

1.1.0

Add `terraform generate backend` command @aknysh (#57)

what

• Add terraform generate backend command
• Fix terraform workspace calculation for derived components

why

• Generate backend files for components from YAML config
• Works with catalog (when YAML config for a component is defined in a catalog file for a component and imported into a top-level stack)
• The old atmos used the format <stack-derived-component for workspaces of derived components

test

atmos terraform generate backend test/test-component-override -s tenant1-ue2-dev


Processing and merging configurations in the following order: system dir, home dir, current dir, ENV vars
No config found in /usr/local/etc/atmos/atmos.yaml
No config found in /Users/andriyknysh/.atmos/atmos.yaml
Found config in /Users/andriyknysh/Documents/Projects/Go/src/github.com/cloudposse/atmos/atmos.yaml
Processed config /Users/andriyknysh/Documents/Projects/Go/src/github.com/cloudposse/atmos/atmos.yaml

Stack 'tenant1-ue2-dev' matches the stack name pattern '{tenant}-{environment}-{stage}'

Final CLI configuration:
components:
  terraform:
    base_path: ./examples/complete/components/terraform
    apply_auto_approve: false
  helmfile:
    base_path: ./examples/complete/components/helmfile
    kubeconfig_path: /dev/shm
    helm_aws_profile_pattern: '{namespace}-{tenant}-gbl-{stage}-helm'
    cluster_name_pattern: '{namespace}-{tenant}-{environment}-{stage}-eks-cluster'
stacks:
  base_path: ./examples/complete/stacks
  included_paths:
  - '**/*'
  excluded_paths:
  - globals/**/*
  - catalog/**/*
  - '**/*globals*'
  name_pattern: '{tenant}-{environment}-{stage}'


Found config files:
- tenant1/ue2/dev.yaml
- tenant1/ue2/prod.yaml
- tenant1/ue2/staging.yaml
- tenant2/ue2/dev.yaml
- tenant2/ue2/prod.yaml
- tenant2/ue2/staging.yaml

Searching for stack config where the component 'test/test-component-override' is defined
Found stack config for component 'test/test-component-override' in stack 'tenant1/ue2/dev'


Component backend config:

{
  "terraform": {
    "backend": {
      "s3": {
        "key": "terraform.tfstate",
        "profile": "eg-gbl-root-terraform",
        "region": "us-east-2",
        "workspace_key_prefix": "test-component",
        "acl": "bucket-owner-full-control",
        "bucket": "eg-ue2-root-tfstate",
        "dynamodb_table": "eg-ue2-root-tfstate-lock",
        "encrypt": true
      }
    }
  }
}

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

1.0.0

what

• Rewrite atmos in Go
• Add more generic CLI config in YAML
• Allow running CLI commands from any folder
• Allow using stack folders (add examples of this)
• Allow using component folders (add examples of this)
• Improve examples
• Build atmos binary for all operating systems and architectures

why

• Go is a general purpose language and it's better suited for long-time maintenance of the CLI
• Component and stack folders will allow to better organize the project and config structures
• Add examples that can be run and tested without any additional steps

GoReleaser

commands to test the example

go run atmos version
go run atmos terraform plan test/test-component-override -s tenant1/ue2/dev
go run atmos terraform plan test/test-component-override -s=tenant1-ue2-dev
go run atmos terraform plan test/test-component-override -s tenant1/ue2/dev --stacks-dir=./examples/complete/stacks
go run atmos terraform validate test/test-component-override -s tenant1/ue2/dev
go run atmos terraform output test/test-component-override -s tenant1/ue2/dev
go run atmos terraform graph test/test-component-override -s tenant1/ue2/dev
go run atmos terraform show test/test-component-override -s tenant1/ue2/dev
go run atmos helmfile diff infra/infra-server -s tenant1/ue2/dev
go run atmos --config-dir ./examples/complete/stacks --terraform-dir ./examples/complete/components/terraform terraform workspace test/test-component-override --stack=tenant1/ue2/dev
go run atmos --config-dir=./examples/complete/stacks --terraform-dir=./examples/complete/components/terraform terraform workspace test/test-component-override --stack tenant1/ue2/dev
go run atmos terraform workspace test/test-component-override --stack=tenant1/ue2/dev --config-dir ./examples/complete/stacks --terraform-dir ./examples/complete/components/terraform
go run atmos terraform varfile test/test-component-override -s tenant1/ue2/dev
go run atmos terraform varfile test/test-component-override -s tenant1/ue2/dev -f ./varfile.json
go run atmos --config-dir ./examples/complete/stacks --terraform-dir ./examples/complete/components/terraform terraform write varfile test/test-component-override --stack=tenant1/ue2/dev
go run atmos terraform write varfile test/test-component-override --stack=tenant1/ue2/dev --config-dir ./examples/complete/stacks --terraform-dir ./examples/complete/components/terraform 
go run atmos --config-dir ./examples/complete/stacks terraform write varfile test/test-component-override --stack=tenant1/ue2/dev --terraform-dir ./examples/complete/components/terraform 
go run atmos describe component test/test-component-override -s tenant1/ue2/dev
go run atmos describe component test/test-component-override -s tenant1-ue2-dev
go run atmos describe component infra/infra-server -s tenant1/ue2/dev
go run atmos describe component infra/infra-server -s tenant1-ue2-dev

0.22.0

feat(terraform-output): add support for args @mikedizon (#55)

what

• Adds the ability to add --args to atmos terraform output

why

• Allows us to view the value of a specific output within a module. Useful for sensitive outputs.

references

• closes #54

0.21.3

🚀 Enhancements

Fix `terraform deploy` @aknysh (#50)

what

• Fix terraform deploy
• Send args to terraform plan

why

• Was missing