https://cloudposse.com logo
Join Slack
Powered by
<@UB2EH889X> absolutely loving v1.210.0 as far. On...
# atmos
j
@Erik Osterman (Cloud Posse) absolutely loving v1.210.0 as far. Only one thing I need to fix: I need the CI templates to hide the terraform warnings.
Screenshot 2026-03-18 172028.png
I am working on making a custom template from atmos/pkg/ci/plugins/terraform/templates at main · cloudposse/atmos that simply doesn't reference 
.Warnings
but wondering if there was a more effective/code way of doing this
e
@Igor Rodionov can you Self assign a task to add docs for how to customize the template?
🙌 1
In my opinion, it would be better to preserve the warnings and instead address the cause, either using a 
generate
block to define the 
variable
or fixing the inheritance.
r
Or some kind of pr label that could hide/expose warnings, maybe ?
j
Since most of the components in my catalog are sourced from "external" root modules that don't follow the SweetOps paradigm, something that generates context on the fly would be necessary. However, it would need to be flexible enough to omit definitions (e.g. don't include 
name
or 
tags
if the root module already defines those).
e
Omitting would be one approach.
Being explicit as the other. 😃
In the catalog configuration for the components that don't follow the convention, you could add the generate block. Then those components from then on are handled.
It would be done on a case-by-case basis, but something like Claude would cut through this like butter.
Copy code
components:
  terraform:
    vpc:
      generate:
        "<http://compatibility.tf|compatibility.tf>": |
          variable "name" {}
Alternatively, do not use 
var.*
for the `name_template`; instead use 
settings.context
and pass variables explicitly
These are all, of course, opinions, and there's no right or wrong way. We come from a background, a Cloud Posse of using environment variables for everything (pre atmos). What we hated was having too many global variables, because we never knew what was consuming them.
So we abandon environment variables almost entirely because we want to know exactly what needs what. And to scope it to where it's used. This is why I don't like suppressing the warnings, it's telling us we are actually passing configuration that's not consumed. And that just like linting in programming, helps reduce the likelihood of errors and misconfiguration.
All of that is a long-winded way of saying: don't set things globally if they aren't truly global. 😃
m
Problem I have with the warnings is that whole plans also seems to be attached to it :S
j
I also feel like it's ok to see terraform warnings locally and in plan summary, but not in the templates. Think of it along the lines of setting log levels to error instead of warning. You might need them to debug but may not want to see them all the time
2 Views
Open in Slack
PreviousNext
Powered by