Releases: cloudposse/atmos
v1.83.1
Auto completion for zsh devcontainer @osterman (#639)
## what - Add autocompletion while you typewhy
- Better DX (less typing)
demo
Add docker image @osterman (#627)
## what - Add a docker image for Atmos - Bundle typcal dependencies - Multi-architecture build for ARM64 and AMD64why
- Make it easier to get up and running with Atmos
Introduce License Check @osterman (#638)
## whatCheck for approved licenses
why
Avoid accidentally introducing code that is non-permissively licensed
Fix Codespace url @osterman (#637)
## what- Update to Codespace URL for
main
branch
why
- It was pointed to an older
reorg
branch
Reorganize Documentation For a Better Learning Journey @osterman (#612)
## what - Rename top menu items to "Learn" and "Reference" - Move community to the left, remove discussions and add contributing - Introduce sidebar sections, so that content is further left-justified - Consolidate Terraform content into one section to tell a better story about how to use Terraform with Atmos.why
- Reorganize Atmos Docs to better help developers on their learning journey
Note
- Dependency Review action is failing. Might be something new with the action.
actions/dependency-review-action#786
🚀 Enhancements
Don't copy unix sockets in `atmos describe affected` command @aknysh (#640)
## what- Don't copy unix sockets when executing
atmos describe affected
command - Fix some links (left over after renaming
examples/quick-start
toexamples/quick-start-advanced
)
why
- Sockets are not regular files, and if someone uses tools like git-fsmonito and executes
atmos describe affected
command, the following error will be thrown:
open .git/fsmonitor--daemon.ipc: operation not supported on socket
v1.83.0
Update `atmos describe affected` command @aknysh (#635)
## what- Update
atmos describe affected
command - If
--upload=true
flag is passed, includedependents
for alldependents
(even an empty list), and include thesettings
section for all the dependent components
why
- Make the API schema consistent on the server that processes the result of
atmos describe affected --upload=true
command
v1.82.0
Add `--upload` flag to `atmos describe affected` command @aknysh (#631)
## what- Add
--upload
flag toatmos describe affected
command - Update docs
why
If the --upload=true
command-line flag is passed, Atmos will upload the affected components and stacks to a specified HTTP endpoint.
The endpoint can process the affected components and their dependencies in a CI/CD pipeline (e.g. execute terraform apply
on all the affected components in the stacks and all the dependencies).
Atmos will perform an HTTP POST request to the URL ${ATMOS_PRO_BASE_URL}/${ATMOS_PRO_ENDPOINT}
, where the base URL is defined by the ATMOS_PRO_BASE_URL
environment variable, and the URL path is defined by the ATMOS_PRO_ENDPOINT
environment variable.
An Authorization header Authorization: Bearer $ATMOS_PRO_TOKEN
will be added to the HTTP request (if the ATMOS_PRO_TOKEN
environment variable is set) to provide credentials to authenticate with the server.
NOTE: If the --upload=true
command-line flag is passed, the --include-dependencies
and --include-settings
flags are automatically set to true
, so the affected components will be uploaded with their dependencies and settings (if they are configured in Atmos stack manifests).
The payload of the HTTP POST request will be a JSON object with the following schema:
{
"base_sha": "6746ba4df9e87690c33297fe740011e5ccefc1f9",
"head_sha": "5360d911d9bac669095eee1ca1888c3ef5291084",
"repo_url": "https://github.com/cloudposse/atmos",
"repo_host": "github.com",
"repo_name": "atmos",
"repo_owner": "cloudposse",
"stacks": [
{
"component": "vpc",
"component_type": "terraform",
"component_path": "examples/quick-start/components/terraform/vpc",
"stack": "plat-ue2-dev",
"stack_slug": "plat-ue2-dev-vpc",
"affected": "stack.vars",
"included_in_dependents": false,
"dependents": [],
"settings": {}
}
]
}
where:
-
base_sha
- the Git commit SHA of the base branch against which the changes in the current commit are compared -
head_sha
- the SHA of the current Git commit -
repo_url
- the URL of the current repository -
repo_host
- the host of the current repository -
repo_name
- the name of the current repository -
repo_owner
- the owner of the current repository -
stacks
- a list of affected components and stacks with their dependencies
v1.81.0
Introduce Atmos `Go` template functions. Add `atmos.Component` function to read values from other Atmos components including outputs (remote state) @aknysh (#628)
## what- Introduce Atmos
Go
template functions - Add
atmos.Component
template function to read values from other Atmos components including outputs (remote state) - Update docs
why
-
Atmos now supports custom
Go
template functions similar to Sprig and GomplateIn
Go
templates in Atmos stack manifests, you can use the following functions and datasources:
description
The atmos.Component
template function allows you to read any Atmos section or any attribute from a section for an Atmos component in a stack, and use it in Go
templates in Atmos component configurations.
Usage
{{ (atmos.Component "<component>" "<stack>").<section>.<attribute> }}
Arguments
-
component
- Atmos component name -
stack
- Atmos stack name -
section
- Atmos section name. Any section returned by the CLI commandatmos describe component
can be used. A specialoutputs
section is also supported to get the outputs (remote state) of Terraform/OpenTofu components.NOTE: Using the
outputs
section in theatmos.Component
command is an alternative way to read the outputs (remote state) of a component in a stack directly in Atmos stack manifests instead of using theremote-state
module and configuring Terraform/OpenTofu components to use theremote-state
module as described in Component Remote State -
attribute
- attribute name (field) from thesection
.attribute
is optional, you can use thesection
itself if it's a simple type (e.g.string
). Any number of attributes can be chained using the dot (.
) notation. For example, if the first two attributes are maps, you can chain them and get a field from the last map:{{ (atmos.Component "<component>" "<stack>").<section>.<attribute1>.<attribute2>.<field1> }}
Specifying Atmos stack
stack
is the second argument of the atmos.Component
function, and it can be specified in a few different ways:
-
Hardcoded stack name. Use it if you want to get an output from a component from a different (well-known and static) stack. For example, you have a
tgw
component in a stackplat-ue2-dev
that requires thevpc_id
output from thevpc
component from the stackplat-ue2-prod
:components: terraform: tgw: vars: vpc_id: '{{ (atmos.Component "vpc" "plat-ue2-prod").outputs.vpc_id }}'
-
Use the
.stack
(or.atmos_stack
) template identifier to specify the same stack as the current component (for which theatmos.Component
function is executed):{{ (atmos.Component "<component>" .stack).<section>.<attribute> }} {{ (atmos.Component "<component>" .atmos_stack).<section>.<attribute> }}
For example, you have a
tgw
component that requires thevpc_id
output from thevpc
component in the same stack:components: terraform: tgw: vars: vpc_id: '{{ (atmos.Component "vpc" .stack).outputs.vpc_id }}'
-
Use the
printf
template function to construct stack names using static strings and dynamic identifiers:{{ (atmos.Component "<component>" (printf "%s-%s-%s" .vars.tenant .vars.environment .vars.stage)).<section>.<attribute> }} {{ (atmos.Component "<component>" (printf "plat-%s-prod" .vars.environment)).<section>.<attribute> }} {{ (atmos.Component "<component>" (printf "%s-%s-%s" .settings.context.tenant .settings.context.region .settings.context.account)).<section>.<attribute> }}
For example, you have a
tgw
component deployed in the stackplat-ue2-dev
. Thetgw
component requires thevpc_id
output from thevpc
component from the same environment (ue2
) and same stage (dev
), but from a different tenantnet
(instead ofplat
):components: terraform: tgw: vars: vpc_id: '{{ (atmos.Component "vpc" (printf "net-%s-%s" .vars.environment .vars.stage)).outputs.vpc_id }}'
NOTE: By using the
printf "%s-%s-%s"
function, you are constructing stack names using the stack context variables/identifiers. For more information on Atmos stack names and how to define them, refer tostacks.name_pattern
andstacks.name_template
sections inatmos.yaml
CLI config file
Examples
The following configurations show different ways of using the atmos.Component
template function to read values from different Atmos sections directly in Atmos stack manifests, including the outputs of other (already provisioned) components.
# Global `settings` section
# It will be added and deep-merged to the `settings` section of all components
settings:
test: true
components:
terraform:
test:
metadata:
# Point to the Terraform/OpenTofu component
component: "test"
vars:
name: "test"
test1:
metadata:
# Point to the Terraform/OpenTofu component
component: "test1"
vars:
name: "test1"
test2:
metadata:
# Point to the Terraform/OpenTofu component
component: "test2"
vars:
name: "test2"
# Use the `atmos.Component` function to get the outputs of the Atmos component `test1`
# The `test1` component must be already provisioned and its outputs stored in the Terraform/OpenTofu state
# Atmos will execute `terraform output` on the `test1` component in the same stack to read its outputs
test1_id: '{{ (atmos.Component "test1" .stack).outputs.test1_id }}'
tags:
# Get the `settings.test` field from the `test` component in the same stack
test: '{{ (atmos.Component "test" .stack).settings.test }}'
# Get the `metadata.component` field from the `test` component in the same stack
test_terraform_component: '{{ (atmos.Component "test" .stack).metadata.component }}'
# Get the `vars.name` field from the `test1` component in the same stack
test1_name: '{{ (atmos.Component "test1" .stack).vars.name }}'
v1.80.0
Add `--include-settings` flag to `atmos describe affected` command @aknysh (#624)
## what- Add
--include-settings
flag toatmos describe affected
command - Update docs
why
- If the
--include-settings=true
flag is passed,atmos describe affected
will include thesettings
section for each affected component in the stack. Thesettings
sections is a free-form map used to pass configuration information to Atmos Integrations. Having thesettings
section in the output will allow the integrations to parse it and detect settings for the corresponding integration
v1.79.0
Fix an issue with the `component_info` output from the `atmos describe component` command. Add `assume_role` property to Atmos JSON Schema S3 backend @aknysh (#621)
## what- Fix an issue with the
component_info
output from theatmos describe component
command - Add
assume_role
property to Atmos JSON Schema S3 backend
why
-
The issue with the
component_info
output from theatmos describe component
command was introduced in the previous PRs (different order of execution when evaluationGo
templates in Atmos stack manifests) -
Support the recommended
assume_role
property in S3 backends. Assuming an IAM Role can be configured in two ways. The preferred way is to use the argumentassume_role
, the other, which is deprecated, is with arguments at the top level (e.g.role_arn
)
references
Update github actions documentation @goruha (#606)
## what * Update github actions documentationwhy
- Document the latest gitops
references
- DEV-491: Update Atmos.tools documentation for GitHub Actions to use atmos.yaml
Fix tests @goruha (#619)
## what * Fix tests * Fix documentationwhy
- Because branch
master
renamed tomain
Go auto release workflows @goruha (#586)
# What * Use go auto-release workflow `cloudposse/.github/.github/workflows/shared-go-auto-release.yml@main` * Remove `.goreleaser.yml`. Now will use https://github.com/cloudposse/.github/blob/main/.github/goreleaser.yml * Drop `auto-release.yaml`. Now will use https://github.com/cloudposse/.github/blob/main/.github/auto-release.yml and https://github.com/cloudposse/.github/blob/main/.github/auto-release-hotfix.ymlWhy
- Consolidate go releases workflow pattern
- Closes #579
v1.78.0
Update `atmos validate stacks` command @aknysh (#611)
what
- Update
atmos vendor pull
command - Update
atmos validate stacks
command - Add
--include-dependents
flag toatmos describe affected
command - Update docs
why
-
When executing
atmos vendor pull
, Atmos creates a temp directory to clone the remote repo into.
Atmos usesgo-getter
to download the sources into the temp directory. When cloning from the root of a repo w/o using modules (sub-paths),go-getter
does the following:- If the destination directory does not exist, it creates it and runs
git init
- If the destination directory exists, it should be an already initialized Git repository (otherwise an error will be thrown)
For more details, refer to
- If the destination directory does not exist, it creates it and runs
-
Don't check for duplicate abstract components in the same stack from different stack manifests. Abstract components are never provisioned and serve as blueprints for real components. This is an update (follow up) to the previous PRs:
-
The
--include-dependents
flag allows including dependencies for the affected components
If the command-line flag --include-dependents=true
is passed to the atmos describe affected
command, and there are other components that depend on the affected components in the stack, the command will include a dependents
property (list) for each affected component. The dependents
property is hierarchical - each component in the list will also contain a dependents
property if that component has dependent components as well.
For example, suppose that we have the following configuration for the Atmos components component-1
, component-2
and component-3
in the stack plat-ue2-dev
:
components:
terraform:
component-1:
metadata:
component: "terraform-component-1"
vars: {}
component-2:
metadata:
component: "terraform-component-2"
vars: {}
settings:
depends_on:
1:
component: "component-1"
component-3:
metadata:
component: "terraform-component-3"
vars: {}
settings:
depends_on:
1:
component: "component-2"
In the above configuration, component-3
depends on component-2
, whereas component-2
depends on component-1
.
If all the components are affected (modified) in the current working branch, the atmos describe affected --include-dependents=true
command will produce the following result:
[
{
"component": "component-1",
"stack": "plat-ue2-dev",
"stack_slug": "plat-ue2-dev-component-1",
"included_in_dependents": false,
"dependents": [
{
"component": "component-2",
"stack": "plat-ue2-dev",
"stack_slug": "plat-ue2-dev-component-2",
"dependents": [
{
"component": "component-3",
"stack": "plat-ue2-dev",
"stack_slug": "plat-ue2-dev-component-3"
}
]
}
]
},
{
"component": "component-2",
"stack": "plat-ue2-dev",
"stack_slug": "plat-ue2-dev-component-2",
"included_in_dependents": true,
"dependents": [
{
"component": "component-3",
"stack": "plat-ue2-dev",
"stack_slug": "plat-ue2-dev-component-3"
}
]
},
{
"component": "component-3",
"stack": "plat-ue2-dev",
"stack_slug": "plat-ue2-dev-component-3",
"included_in_dependents": true
}
]
The component-1
component does not depend on any other component, and therefore it has the included_in_dependents
attribute set to false
. The component-2
and component-3
components depend on other components and are included in the dependents
property of the other components, and hence the included_in_dependents
attribute is set to true
.
When processing the above output, you might decide to not plan/apply the component-2
and component-3
components since they are in the dependents
property of the component-1
component. Instead, you might just trigger component-1
and then component-2
and component-3
in the order of dependencies.
v1.77.0
Update `atmos validate stacks` command @aknysh (#611)
what
- Update
atmos validate stacks
command - Improve stack validation error messages
why
-
When checking for misconfiguration and duplication of components in stacks, throw errors only if the duplicate component configurations in the same stack are different (this will allow importing the base default/abstract components into many stack manifest files)
-
The
atmos validate stacks
command check the following-
All YAML manifest files for YAML errors and inconsistencies
-
All imports: if they are configured correctly, have valid data types, and point to existing manifest files
-
Schema: if all sections in all YAML manifest files are correctly configured and have valid data types
-
Misconfiguration and duplication of components in stacks. If the same Atmos component in the same Atmos stack is defined in more than one stack manifest file, and the component configurations are different, an error message will be displayed similar to the following:
The Atmos component 'vpc' in the stack 'plat-ue2-dev' is defined in more than one top-level stack manifest file: orgs/acme/plat/dev/us-east-2-extras, orgs/acme/plat/dev/us-east-2. The component configurations in the stack manifests are different. To check and compare the component configurations in the stack manifests, run the following commands: - atmos describe component vpc -s orgs/acme/plat/dev/us-east-2-extras - atmos describe component vpc -s orgs/acme/plat/dev/us-east-2 You can use the '--file' flag to write the results of the above commands to files (refer to https://atmos.tools/cli/commands/describe/component). You can then use the Linux 'diff' command to compare the files line by line and show the differences (refer to https://man7.org/linux/man-pages/man1/diff.1.html) When searching for the component 'vpc' in the stack 'plat-ue2-dev', Atmos can't decide which stack manifest file to use to get configuration for the component. This is a stack misconfiguration. Consider the following solutions to fix the issue: - Ensure that the same instance of the Atmos 'vpc' component in the stack 'plat-ue2-dev' is only defined once (in one YAML stack manifest file) - When defining multiple instances of the same component in the stack, ensure each has a unique name - Use multiple-inheritance to combine multiple configurations together (refer to https://atmos.tools/core-concepts/components/inheritance)
-
notes
- This is an improvement of the previous release https://github.com/cloudposse/atmos/releases/tag/v1.75.0. The previous release introduced too strict checking and disabled the case where the same component in the same stack was just imported into two or more stack manifest files (this type of configuration is acceptable since the component config is always the same in the stack manifests since it's just imported and not modified)
v1.76.0
Add Atmos manifest lists merge strategies @aknysh (#609)
what
- Add Atmos manifest lists merge strategies
- Update docs
Settings
section in CLI Configuration
why
-
Allow using the following list merge strategies in Atmos stack manifests:
-
replace
- Most recent list imported wins (the default behavior). -
append
- The sequence of lists is appended in the same order as imports. -
merge
- The items in the destination list are deep-merged with the items in the source list. The items in the source list take precedence. The items are processed starting from the first up to the length of the source list (the remaining items are not processed). If the source and destination lists have the same length, all items in the destination lists are deep-merged with all items in the source list.
-
The list merging strategies are configured in atmos.yaml
CLI config file in the settings.list_merge_strategy
section
settings:
# `list_merge_strategy` specifies how lists are merged in Atmos stack manifests.
# Can also be set using 'ATMOS_SETTINGS_LIST_MERGE_STRATEGY' environment variable, or '--settings-list-merge-strategy' command-line argument
# The following strategies are supported:
# `replace`: Most recent list imported wins (the default behavior).
# `append`: The sequence of lists is appended in the same order as imports.
# `merge`: The items in the destination list are deep-merged with the items in the source list.
# The items in the source list take precedence.
# The items are processed starting from the first up to the length of the source list (the remaining items are not processed).
# If the source and destination lists have the same length, all items in the destination lists are
# deep-merged with all items in the source list.
list_merge_strategy: replace
v1.75.0
Improve `atmos validate stacks` and `atmos describe affected` commands @aknysh (#608)
what
- Improve
atmos validate stacks
andatmos describe affected
commands - Update docs
why
-
atmos validate stacks
now detects if the same component in the same stack are defined in more than one Atmos stack manifest files. If such a misconfiguration is detected, the following error is shown:the Atmos component 'vpc' in the stack 'plat-ue2-dev' is defined in more than one top-level stack manifest file: orgs/acme/plat/dev/us-east-2, orgs/acme/plat/dev/us-east-2-extras. Atmos can't decide which stack manifest to use to get configuration for the component in the stack. This is a stack misconfiguration.
-
atmos describe affected
now has better error messages and also executesatmos validate stacks
before detecting the affected components and stacks. This prevents the issue when the same component in the same stack is defined in more than one stack manifest file, and the command used one file from the current local branch and the other file from the target branch, resulting in drift in affected components and stacks. Since this is a stack misconfiguration and is not permitted,atmos describe affected
will display the error and exit -
alias
: Multiple Provider Configuration in Atmos ManifestsAtmos allows you to define multiple configurations for the same provider using a list of provider blocks and the
alias
meta-argument.The generated
providers_override.tf.json
file will have a list of provider configurations, and Terraform will use and override the providers as long as the aliased providers are defined in the Terraform component.For example:
components: terraform: vpc: providers: aws: - region: us-west-2 assume_role: role_arn: "role-1" - region: us-west-2 alias: "account-2" assume_role: role_arn: "role-2"