v1.146.0

Configure and use GitHub auth token when executing `atmos vendor pull` commands @Listener430 @aknysh (#912)

what

• Use GitHub token when executing atmos vendor pull commands
• Intorduce environment variables GITHUB_TOKEN and ATMOS_GITHUB_TOKEN to specify a GitHub Bearer token for authentication in GitHub API requests
• Add custom GitHub URL detection and transformation for improved package downloading

why

• When pulling from private GitHub repos, GitHub has a rate limit for anonymous requests (which made atmos vendor pull fail when vendoring from private GitHub repositories)

description

In the case when either the ATMOS_GITHUB_TOKEN or GITHUB_TOKEN variable is configured with a GitHub Bearer Token, vendor files are downloaded with go-getter using the token. The token is put into the URL, and the requests to the GitHub API are not affected to anonymous users rate limits

test

github.com/analitikasi/Coonector.git is a private repo

 - component: "weather"
   source: "github.com/analitikasi/Coonector.git//quick-start-simple/components/terraform/{{ .Component }}?ref={{.Version}}"
   version: "main"
   targets:
     - "components/terraform/{{ .Component }}/{{.Version}}"
   tags:
     - demo

v1.145.0

Support Component Lock with `metadata.locked` @milldr (#908)

what

• Added support for metadata.locked with components

• Separate atmos CLI tests into many files: tests/test_cases.yaml --> tests/test-cases/*.yaml

why

• The metadata.locked parameter prevents changes to a component while still allowing read operations. When a component is locked, operations that would modify infrastructure (like terraform apply) are blocked, while read-only operations (like terraform plan) remain available. By default, components are unlocked. Setting metadata.locked to true prevents any change operations.

# Lock a production database component to prevent accidental changes
components:
  terraform:
    rds:
      metadata:
        locked: true
      vars:
        name: production-database

v1.144.0

Embed JSON Schema for validation of Atmos manifests inside Atmos binary @aknysh (#925)

what

• Embed the JSON Schema for validation of Atmos manifests inside Atmos binary
• Update docs

why

• Embedding the JSON Schema inside the Atmos binary allows keeping the Atmos code and the schema in sync, and does not force users to specify JSON Schema in atmos.yaml and monitor it when it needs to be updated

description

Atmos uses the Atmos Manifest JSON Schema to validate Atmos manifests, and has a default (embedded) JSON Schema.

If you don't configure the path to a JSON Schema in atmos.yaml and don't provide it on the command line using the --schemas-atmos-manifest flag, the default (embedded) JSON Schema will be used when executing the command atmos validate stacks.

To override the default behavior, configure JSON Schema in atmos.yaml:

• Add the Atmos Manifest JSON Schema to your repository, for example in stacks/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json

• Configure the following section in the atmos.yaml

# Validation schemas (for validating atmos stacks and components)
schemas:
  # JSON Schema to validate Atmos manifests
  atmos:
    # Can also be set using 'ATMOS_SCHEMAS_ATMOS_MANIFEST' ENV var, or '--schemas-atmos-manifest' command-line arguments
    # Supports both absolute and relative paths (relative to the `base_path` setting in `atmos.yaml`)
    manifest: "stacks/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json"
    # Also supports URLs
    # manifest: "https://atmos.tools/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json"

• Instead of configuring the schemas.atmos.manifest section in atmos.yaml, you can provide the path to
  the Atmos Manifest JSON Schema file by using the ENV variable ATMOS_SCHEMAS_ATMOS_MANIFEST or the --schemas-atmos-manifest command line flag:

ATMOS_SCHEMAS_ATMOS_MANIFEST=stacks/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json atmos validate stacks
atmos validate stacks --schemas-atmos-manifest stacks/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json
atmos validate stacks --schemas-atmos-manifest https://atmos.tools/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json

Summary by CodeRabbit

• Configuration Updates

  • Enhanced schema configuration flexibility in atmos.yaml
  • Added support for remote and embedded JSON schema locations

• Documentation Improvements

  • Updated CLI command documentation for stack validation
  • Added new sections explaining validation processes and schema management
  • Clarified usage of URLs for schema manifests in documentation

• Testing

  • Added new test for JSON schema validation

v1.143.0

Support Relative Path Imports @milldr (#891)

what

• Add support for relative paths in imports, when the path starts with ./ or ../
• Support all path types:

import:
  - ./relative_path
  - ../relative_path

or

import:
  - path: ./relative_path
  - path: ../relative_path

why

• Allow less path duplication and support simpler code

Test Cases as a Directory @milldr (#922)

what

• Added support for test cases as a directory rather than a single file

why

• We are adding many more tests and as such the single file is becoming unruly

v1.142.0

Introduce a centralized theming system for consistent UI styling @Cerebrovinny (#913)

what

• Introduced a centralized theming system for consistent UI styling
• Moved terminal colors to global constants
• Added theme-based color and style configurations

why

• Centralize color and style management across the application
• Make it DRY and consistent

v1.141.0

Update the descriptions of Atmos commands @samtholiya (#845)

what

• Update the descriptions of Atmos commands

why

• Improve clarity and specificity regarding Atmos commands functionality

v1.140.0

Add `--query` (shorthand `-q`) flag to all `atmos describe ` commands @aknysh (#920)

what

• Added --query (shorthand -q) flag to all atmos describe <subcommand> commands
• Updated CLI command documentation to reflect new querying functionality
• Added examples for new query-based commands

why

• Query (and filter) the results of atmos describe <subcommand> commands using yq expressions
• Before, an external yq or jq binary was required to query/filter the results of atmos describe commands. With the yq functionality now embedded in Atmos, installing the yq binary is not required

examples

atmos describe component vpc -s plat-ue2-prod --query .vars
atmos describe component vpc -s plat-ue2-prod -q .vars.tags
atmos describe component vpc -s plat-ue2-prod -q .settings
atmos describe component vpc -s plat-ue2-prod --query .metadata.inherits

atmos describe stacks -q keys  # this produces the same result as the native `atmos list stacks` command

atmos describe config -q .stacks.base_path

atmos describe workflows -q '.0 | keys'

atmos describe affected -q <yq-expression>

atmos describe dependents -q <yq-expression>

references

• https://mikefarah.gitbook.io/yq
• https://github.com/mikefarah/yq
• https://mikefarah.gitbook.io/yq/recipes
• https://mikefarah.gitbook.io/yq/operators/pipe

v1.139.0

`TF_CLI_ARGS_*` Handling @milldr (#898)

what

• Added logic and warning messages when the user specifies any TF_CLI_* environment variable, since this may conflict with Atmos behavior.
• Append any TF_CLI env vars to the determined TF_CLI env var for terraform shell

why

• When executing Terraform Shell, we should append generate var file to the (if) specified env var rather than overwriting it
• When executing Terraform, var files are already appended (merged). We should add a warning nonetheless

atmos terraform shell

atmos terraform plan

v1.138.0

Implement `atmos about` and `atmos support` commands @Cerebrovinny (#909)

what

• Implement atmos about and atmos support commands

why

• Help users to find information about Atmos and Cloud Posse support

Support

About

v1.137.0

Merge Atmos specific and terraform/helmfile help documentation @samtholiya (#857)

what

• Merge Atmos specific and terraform/helmfile help documentation

why

• Show the native terraform/helmfile commands and Atmos-specific terraform/helmfile commands

Separate Test Fixtures from Examples @milldr (#918)

what

• Move examples/tests to tests/fixtures

why

• Examples are intended to be just that, examples. We should not be including test usages with the examples