#atmos-dev - April 2025

@Haitham I updated and merged this PR https://github.com/cloudposse/atmos/pull/1173, you mentioned you were waiting on it to continue on other PRs, now you should be unblocked

@Vinny did you address all comments in https://github.com/cloudposse/atmos/pull/1036 (regarding the handling of error codes)? Is it ready for final review?

@Erik Osterman (Cloud Posse) @Andriy Knysh (Cloud Posse) please review https://github.com/cloudposse/atmos/pull/1091

Accidently in this pr
https://github.com/cloudposse/atmos/pull/1076
we added a golden file without resolving merge conflict:
Blaming atmos/tests/snapshots/TestCLICommands_atmos_vendor_pull_custom_detector_credentials_leakage.stderr.golden at main · cloudposse/atmos

it is a golden file... i am just curious how did it even pass the test 😅

@Haitham we tried to use atmos terraform clean yesterday and discovered it doesn’t support components in subfolders. We should probably change our approach to use all configured components since component paths can be customized. In other words using the fully deepmerged stack configuration.

Would there be interest in accepting a patch to auto-clean generated files before/after any atmos command?
We ran into an issue today where an engineer ran atmos, then selected terraform plan for a component/stack, and the plan was partially generated using an incorrect provider configuration.

Just FYI:
Github actions are stuck
cc: @Erik Osterman (Cloud Posse)

@Dan Miller (Cloud Posse) hi, thanks for sharing the feedback on docs generate. Have looked through the comments and briefly discussed wtih @Erik Osterman (Cloud Posse), I guess the minor ones (logs, idents, admonition etc) are easy to fix, and there's one items that might required some clarification at your end. Could you please take a look at #3 below ?
1. atmos generate generate issue is due to the way cobra handles aliases. Agreed with Erik to take the alias out for now.
2. mutiple targets - could be done, in this case instead of a hardcoded readme subcommand we make it an argument, this will allow to have multiple targets. So we could have readme, or component1 or component2 virtually anything as an argumant to docs genrate as well as section in atmos.yaml. The bigger challenge here is how to document it properly so people aren't confused.
3. On defining the input with stack config. The way it currently works: we have a template and a readme.yaaml with a pretty much the same set of keys. So gomplate runs throguh the template and puts the values from the yaml file. In the proposed yaml you list docs and readme and template name sections. They are currntly taken from the atmos.yaml and in your proposaal you suggest to put them into the reame.yaml? Could you please elaborate a little bit what kind of problem you are trying to address?

 docs:
  readme:
    name: "template"
    # Canonical GitHub repo
    github_repo: "cloudposse-terraform-components/template"
    # Short description of this project
    description: |-
      Description of this component
    usage: |-
      **Stack Level**: Regional or Test47

      Here's an example snippet for how to use this component.

yaml
      components:
        terraform:
          foo:
            vars:
              enabled: true
      
    include:
      - "docs/terraform.md"
    tags:
      - terraform
      - terraform-modules
      - aws
      - components
      - terraform-components
      - root
      - geodesic
      - reference-implementation
      - reference-architecture
    # Categories of this project
    categories:
      - terraform-modules/root
      - terraform-components
    # License of this project
    license: "APACHE2"
    # Badges to display
    badges:
      - name: "Latest Release"
        image: "<https://img.shields.io/github/release/cloudposse-terraform-components/template.svg?style=for-the-badge>"
        url: "<https://github.com/cloudposse-terraform-components/template/releases/latest>"
      - name: "Slack Community"
        image: "<https://slack.cloudposse.com/for-the-badge.svg>"
        url: "<https://slack.cloudposse.com>"
    references:
      - name: "Cloud Posse Documentation"
        description: "Complete documentation for the Cloud Posse solution"
        url: "<https://docs.cloudposse.com>"
      - name: "Reference Architectures"
        description: "Launch effortlessly with our turnkey reference architectures, built either by your team or ours."
        url: "<https://cloudposse.com/>"
    related:
    - name: "Cloud Posse Terraform Modules"
      description: Our collection of reusable Terraform modules used by our reference architectures.
      url: "<https://docs.cloudposse.com/modules/>"
    - name: "Atmos"
      description: "Atmos is like docker-compose but for your infrastructure"
      url: "<https://atmos.tools>"
    contributors: [] # If included generates contribs

4. atmos generate docs to build all docs options - ok, this can be done

@Erik Osterman (Cloud Posse) @Andriy Knysh (Cloud Posse) I will begin work today on !exec
We need to make some changes to the YAML-functions( which call processCustomTags). Specifically, processCustomTags functions should be moved to an intermediate package. This will allow both the config and exec packages to call them without causing circular dependency issues. This approach helps us avoid duplicating code in the config and exec packages.

https://linear.app/cloudposse/issue/DEV-2885/fix-command-for-atmos-terraform-generate-varfile#comment-47215e56

Need to confirm this
cc: @Jeremy G (Cloud Posse)

For pr: Config Core library by samtholiya · Pull Request #1174 · cloudposse/atmos
While my patch coverage percentage is 90.xx%
Just because i removed some old code the coverage of utils.go dropped by 2.75% and codecov is complaining based on our thresholds.

Can we ignore this?

How can I run atmos go test locally so I can fix them before pushing to the PR?

Hi Team
I was just wondering if setting the ATMOS_BASE_PATH
Should set the workdir of atmos according to me but looks like that is not happening because if i go to the dir then i get screenshot2 (ignore the error it is just because i did not setup the redis)

Or I am missing something

add pager to describe config command by samtholiya · Pull Request #1203 · cloudposse/atmos
cc: @Erik Osterman (Cloud Posse) @Andriy Knysh (Cloud Posse)

Ready for review.
Fortunately not as big of a pr than others 😅

@Erik Osterman (Cloud Posse) @Andriy Knysh (Cloud Posse) please review https://github.com/cloudposse/atmos/pull/1202
For config package when run yaml functions (!env or !exec) if return error I log it on debug and continue
or should we return error

https://github.com/cloudposse/atmos/pull/1174
Need help ... why codecov have problem.. now coverage reduction is also 1.99 which is bellow 2% threshold

@Andriy Knysh (Cloud Posse) @Erik Osterman (Cloud Posse) please review https://github.com/cloudposse/atmos/pull/1202/

@Andriy Knysh (Cloud Posse) @Erik Osterman (Cloud Posse) please review https://github.com/cloudposse/atmos/pull/1195

This is ready for review too https://github.com/cloudposse/atmos/pull/963 The acceptance test are failing for some failing yamls I have not touched

@Andriy Knysh (Cloud Posse) this has no more unresolved comments from what I can tell https://github.com/cloudposse/atmos/pull/1202

@Erik Osterman (Cloud Posse) @Andriy Knysh (Cloud Posse) https://github.com/cloudposse/atmos/pull/1195
I resolved all comment and also add required test case

Hey Team
I have noticed we are using os.Setenv and os.Unsetenv for tests.
It is better that we use t.Setenv instead. This function ensures that env is unset after the test and is scoped in the tests so it is better.

Also similarly we can use t.Chdir

Hey team
I am thinking to have one more thing related to atmos

What do you think about developing an extension for vs code that helps user in validating and providing suggestions for atmos.yaml.

This would help users in easily configuring atmos.yaml.

Just like we have extensions that help with docker.yaml


Having good helping tools help users in easy adoption

Hey team,
If i understand correct
We do not support our new !import in vendor configs do we?
Just want to double check 😅