Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Preserve order of fields in generated HCL code #1467

Open
cwe1ss opened this issue Feb 23, 2024 · 2 comments
Open

[FEATURE] Preserve order of fields in generated HCL code #1467

cwe1ss opened this issue Feb 23, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@cwe1ss
Copy link

cwe1ss commented Feb 23, 2024

Is your feature request related to a problem? Please describe.
When generating HCL code using generate_hcl, Terramate always outputs fields in alphabetical order and without any empty lines. This makes it harder to read and inconsistent with manually created HCL files.

Describe the solution you'd like
Terramate should preserve the order of fields (and ideally also blank lines between fields) in generate_hcl.

Describe alternatives you've considered
No alternatives.

Additional context
See for example:

Probably related to #1213

@cwe1ss cwe1ss added the enhancement New feature or request label Feb 23, 2024
@mariux
Copy link
Contributor

mariux commented Feb 29, 2024

Thanks for reporting this. This is currently on purpose and quiet standard in code generation that the generated code is not matching the input in a 1:1 fashion. But we do have this in our backlog to allow configuring this behavior better by e.g. setting a "keep_order" flag. Sadly the HCL library is not very supportive here so this is not a trivial change.

The referenced issue for keeping the comments with their attributes and blocks is currently a higher priority as it affects the use of linting tools.

Let me give you some background, why we did not prioritized the order of attributes so far. We see the current behavior as a feature ;) which is maybe the most unsatisfying answer you can expect. But let me elaborate on why.

The generated code does currently not depend on how a user structures the code in the content block of the generate_hcl block. This has an enormous benefit when it comes to change detection if your generate blocks are outside of the stack. No matter how you refactor your code, the generated code will be constant and stable. If we would keep the attributes in order any refactoring of a module would trigger all affected stacks. In the worst case, e.g. when refactoring the backend code generation configuration, this might reach all stacks. So this refactor will trigger all stacks as being changed even though there are not actual changes except for the order of attributes. HCL itself does not have an order here and any order is considered the same.

We are also planning to add a .tmignore so you could actually mark files like *.md or even *.tm or *.tm.hcl as being ignored by the change detection.

Our goal here is to execute stacks only if we really know they will cause changes in the cloud when executed.

No matter what, for the sake of reviewability this request is totally valid and we will keep it open and wait for more votes on it or will prioritize it in the future.

If someone from the community would like to contribute to this, we are happy to align details and will also support this effort with whatever information is needed. Our main CLI developers are reachable in discord and are happy to help understanding the current state of HCL code generation in Terramate CLI if needed.

@g13013
Copy link

g13013 commented May 2, 2024

I think keeping the order and comments of the generated files is important. For example, if I want to generate this code

generate_hcl "resources.tf" {
  content {
    resource "null_resource" "main" {
      for_reach = {}
      
      attribute_1: value
      attribute_2: value
     // some comment
      x_attribute: value
    }
  }
}

the output will become

    resource "null_resource" "main" {
      attribute_1: value
      attribute_2: value
      for_reach = {}
      x_attribute: value
    }

I think this introduces confusion and inspection might be hard especially when dealing with a lot attributes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants