#help (2024-03)

you need to quote the Go templates, use either single or double quotes

without the quotes, the yaml is invalid

It seems to me that both double and single quoting leads to the templated section being single quoted with the literal template as a value (as seen with a describe command).

here are working excamples:

https://atmos.tools/core-concepts/stacks/templating

https://github.com/cloudposse/atmos/blob/master/examples/quick-start/stacks/orgs/acme/_defaults.yaml#L18

it produces

    atmos_component: vpc
    atmos_manifest: orgs/acme/plat/dev/us-east-2
    atmos_stack: plat-ue2-dev
    terraform_workspace: plat-ue2-dev

I think I’ve been looking at the first one.

i don’t see the final values quoted. What yaml are you using?

relevant snippet (thanks for responding btw ):

      settings:
        setting_a: "a"
      vars:
        var_a: "{{ .settings.setting_a }}"

and it’s not that the final values are quote its that the value seems to just be the literal template var_a: '{{ .settings.setting_a }}'

hmm, what Atmos version are you using?

i’m def not seeing the issue

looks like 1.57.0

need to use 1.66.0

before that, Go templates were not supported, and that’s why those are literal values

https://github.com/cloudposse/atmos/releases/tag/v1.66.0

thanks! works now

super

also you prob have figured it out, circular deps in templates are not supported (e.g. template a references template b, b references c, c references a). Atmos (at least currently) does only once pass to process the templates

Good tip, thanks! Had Golang templating existed before and just the utilization by stack manifests is new to 1.66.0? Looks quite helpful

Go templates existed before only in imports. Now they are supported in stack manifests in 1.66.0

but note that those are completely different methods

imports are special because they are used to process the manifests to actually find a component in a stack

so you can’t just use templates in imports. You need to specify “context” with already defined values because imports are processed first before processing the component in the stack

ah okay, interesting.

for imports, Go templates are like this https://atmos.tools/core-concepts/stacks/imports#go-templates-in-imports

import is the special section where you can’t use Go templates without providing the static context

that’s b/c of the multi-phase processing. When you execute atmos terraform apply vpc -s plat-ue2-prod, Atmos does the following to find the component in the stack in all those stack manifest files:

1. Read all top-level stack manifests (defined in atmos.yaml in the stacks.included_path excluding those from the stacks.excluded_paths)
2. Process Go templates in all the imports (using the static context since no other section (vars, settings, etc.) is know yet for the component
3. Read all the imported files and merge them into a map (first deep-merging phase)
4. Deep-merge all Atmos sections (vars, settings etc.) from all scopes (Org, tenant, account, region, base component, component) into a final map of all components in all stacks (second deep-merging phase)
5. Find the component in the stack (or throw an error if not found)
6. And finally, process the Go templates in the component in all other sections except import (import is not used here since evrything was already imported and deep-merged)

Is there a canonical Atmos section to put info in a mixin that might be used for vars in a component? I don’t want to put the info in vars b/c I don’t want it added every time I reference the mixin and may want to process the info a bit while assigning it. Maybe metadata makes sense? Maybe using another mixin is the better approach though.

no, metadata is a static section with a predefined schema https://atmos.tools/reference/schemas. https://atmos.tools/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json

but settings is a free-form map, you can put anything in there and then get it back in the Go templates or from the command atmos describe component

ah okay, so it’s not like terraform or helm settings only. thanks that helps.

you can define anything in settings, make it a separate component, or a separate base abstract component, then import it or inherit from it in other components (https://atmos.tools/core-concepts/components/inheritance)

cool, thanks for all the info

let’s use atmos for all Atmos-related questions