Keep atmos from templating stacks when running describe affected

[abermudez-wcg]

Describe the Feature

This feature should add the --process-templates flag to the atmos describe affected command.

Expected Behavior

I want to be able to execute atmos describe stacks --process-templates=false and not have the templates be processed.

Use Case

In our use-case, atmos describe stacks --process-templates=false allows me to aggregate and dynamically create workflows for all stacks I want to plan and apply via atmos terraform without processing the templates and requiring connection to the target cloud. A --process-templates=false flag to atmos describe affected would allow us the option to no process the templates in the stacks.

Describe Ideal Solution

I would like to see atmos describe affected --process-templates=false

Alternatives Considered

No response

Additional Context

No response

[aknysh]

@abermudez-wcg thank you for opening the issue.

We have the flag already added to the atmos describe component and atmos describe stacks commands.

https://atmos.tools/cli/commands/describe/stacks/#flags

We've been discussing this (if we need the --process-templates flag for atmos describe affected), and did not add it b/c the result of the command depends on the templates being processed.

For example:

components:
   terraform:
     my-component:
       vars:
         a: '{{ (atmos.Component c1 s2).outputs.a'
         b: '{{ (atmos.Component c2 s2).settings.b'

w/o processing the templates, the component my-component might never be detected as affected even if the outputs from the components c1 and c2 change. In this case, the variables will always be the same (the template strings).

While we can add the flag to the command, it would work only in some cases. In many other cases, the command would manifest itself as working incorrectly, bringing up more questions, which would make the command with the flag unusable in almost all the cases when using templates.

Please let me know what you think about this?

[abermudez-wcg]

This makes sense. I'd rather have the tool work consistently always and not have a list of caveats for certain cases and/or scenarios. Thanks.