Question, does anyone here use atmos + checkov together in GitHub actions?

atmos docs generate is a game changer! used it for a new project and it works amazing!

Following the documentation it seems like !literal should be working here:

field_template: !literal |
  {%- if alertDef.entityLabels.channel is defined -%}
    {{ alertDef.entityLabels.channel }}
  {%- else -%}
    _sandbox
  {%- endif -%}

but I get error *Error:* template: templates-all-atmos-sections:624: function "alertDef" not defined, is there something wrong with my usage or a bug?

I tried with 1.210.0 & 1.216.0

I just upgraded to 1.115 and saw this: Preserve Directory Hierarchy in Terraform State Buckets. Yeah! For weeks, I've been telling myself I need to report that I have to override all components manually because it doesn't preserve the /. A small feature, but very valuable. Thanks :).

Has anyone ran into issue that prevents using atmos locals? More in the thread.

Hi all, I have a question on datasources/templates

I have this datasource defined:
settings:
templates:
settings:
gomplate:
datasources:
env:
url: "stacks/data/{{ .vars.environment }}.yaml"

And I use it as described in the documentation:
ami: '{{{{ (index (datasource "env").ami .vars.aws_region) }}}}'

It works great if aws_region contains directly a string value but is not working if it reference another variable, for example aws_region: {{ .vars.region }}
I have templates evaluation set to 3 and as far as I understood, in the first evaluation aws_region should be resolved to the actual value of region and ami to '{{ (index (datasource "env").ami .vars.aws_region) }}' so in the second evaluation it should be evaluated correctly with the value originally contained into region.
Am I assuming something wrong? Is there any way to make it works if I'm doing something wrong? Thanks in advance

Hey I just feel like I stumbled upon a very cool configuration that will help us migrate from static traditional terraform dirs in a progressive way.
In our current static terraform we only use a default workspace and set specific backend keys for each dir. Eventually we'll migrate these static root modules into components but until they are all migrated in I was worried it would be difficult to leverage the atmos !terraform.state YAML function to lookup outputs in the older terraform root modules.
Then I had a crazy idea. If could create a dummy component that essentially only contains a context.tf could I then setup a stack that points to the older root modules where each component inherits from dummy but then specifies it's backend to make !terrafofrm.state work. To my surprise this actually works amazingly well!
Here's what one of these dummy instances actually looks like (bogus account id swapped in):

components:
  terraform:
    vpc/us-east-1-development:
      metadata:
        enabled: false
        terraform_workspace: "default"
        component: dummy
        name: vpc/us-east-1-development
      backend:
        s3:
          key: infra/terraform/123456789012/vpc/us-east-1-development/terraform.tfstate

Then I can use this in another real component in the same stack:

      vars:
        vpc_id: !terraform.state vpc/us-east-1-development vpc_id

Thought I would share in case this helps anyone else move into atmos
The metadata.enabled is very cool cause that ensures my CI/CD does not try to plan/apply this dummy component as well!

Hi guys!
Apologies for the next rookie question - is the Makefile deprecated?

Hello, I'm looking how to tackle atmos terraform destroy with GitHub Actions.
With vanilla Terraform, resources are deleted when source code files are removed from the codebase.
With Atmos components that is not the case, as we need deep merged yaml to even run terraform in the first place.
I'm looking for ways how to carry out deletions when PR with deleted yaml files gets created.

Hello. I've been looking into atmos generate and it seems it can't be specified under the global terraform key (like backend or providers). Am I missing something or is there a reason it must only be specified under a component?
I guess if I wanted a file more globally generated I could try having all my components inherit from one that does the generation...

Have you ever wanted to auto commit fixes like terraform fmt and realized that GitHub Actions won't run on those changes? GitHub does this as a circuit-breaker to prevent commit loops.

The workaround used to suck: create a static PAT or create a new github app, then distribute/manage/rotate those secrets.

Well, not anymore.

Now you can use atmos pro commit https://atmos.tools/changelog/pro-commit

Hi there, just confirming planfile to Github artifacts in native CI is not implemented in 215 right?

🧪 ci is an experimental feature. Learn more <https://atmos.tools/experimental>
WARN CI hook handler failed event=after.terraform.plan
  error=
  │ failed to upload planfile: failed to upload planfile: not implemented: GitHub Artifacts upload requires running within GitHub Actions (ACTIONS_RUNTIME_TOKEN and ACTIONS_RESULTS_URL must be set)
  │ (1) forced error mark
  │   | "failed to upload planfile"
  │   | errors/*errors.errorString::
  │ Wraps: (2) key=dev-primary/argocd-apps/0509682841e9b66922a344abd606567815703ad3.tfplan.tar store=github/artifacts
  │ Wraps: (3) Failed to upload planfile to store
  │ Wraps: (4) failed to upload planfile: failed to upload planfile: not implemented: GitHub Artifacts upload requires running within GitHub Actions (ACTIONS_RUNTIME_TOKEN and ACTIONS_RESULTS_URL must be set)
  │     └─ Wraps: (5) failed to upload planfile: not implemented: GitHub Artifacts upload requires running within GitHub Actions (ACTIONS_RUNTIME_TOKEN and ACTIONS_RESULTS_URL must be set)
  │       └─ Wraps: (6) not implemented: GitHub Artifacts upload requires running within GitHub Actions (ACTIONS_RUNTIME_TOKEN and ACTIONS_RESULTS_URL must be set)
  │         └─ Wraps: (7) not implemented
  │       └─ Wraps: (8) failed to upload planfile
  │     └─ Wraps: (9) failed to upload planfile
  │ Error types: (1) *markers.withMark (2) *safedetails.withSafeDetails (3) *hintdetail.withDetail (4) *fmt.wrapErrors (5) *fmt.wrapErrors (6) *fmt.wrapError (7) *errors.errorString (8) *errors.errorString (9) *errors.errorString
ℹ Executing command: atmos terraform apply argocd-apps --from-plan -auto-approve
🧪 ci is an experimental feature. Learn more <https://atmos.tools/experimental>

Hello 👋 I'm working on getting aws-ssosync setup, and I I see you all recently released v2.0.0.

I can't find this version published to the open tufu registry. Is this version only meant to be usable with Atmos?

Hello guys! I'm trying to use the github-action-atmos-terraform-plan in a github actions pipeline that deploys resources to Google Cloud but it fails because it seems to only supports AWS authentication:

Run aws-actions/configure-aws-credentials@v4.0.2
  
Error: Source Account ID is needed if the Role Name is provided and not the Role Arn.

Is there a way to skip the AWS credentials configuration action and make it work with GCP instead? Or is there a another atmos-terraform-plan action for GCP?

Hey guys I have a question about atmos toolchain I know we have the .tool-versions file but do we need to set the version again when declaring them as a dependencies?

for example on the org/_default I have this:

dependencies:
  tools:
    atmos: 1.214.0
    terraform: 1.14.2
    tflint: 0.61.0

but I will prefer to manage version in 1 place and just declare the tool that is need it that way I don't have to remember and update this too hahaha

Just another friendly reminder: if you are waiting on a resolution to an issue you have opened, please check if there's an associated PR. If there is, it's probably held up on validation, and any help we can get to validate those pull requests will expedite merging and cutting a release.

Hello,
I'm asking because I didn't see about this in the Atmos documentation. Is it possible to add the Git commit and branch to the variables? This would allow us to tag resources and thus track the code that created or modified them. Do you think this is a good idea? And Then would you consider adding this feature to the Atmos core?

Hi guys!
Is there any article/documentation on how to move from Terraform to OpenTofu? (tf 1.5.7)

We added a batch deployment dashboard to Atmos Pro which is useful when PRs touch a lot of components and the normal mermaid-style diagrams cannot be shown due to comment-size limitations.

Hello! I'm looking for a way to switch identity depending on the component in a stack.

I have a default identity which I use store terraform state file, But the component that I'm trying to create should be on another account. I have tried using the component level identity selection, but it isn't working. it tries to create the component on the default identity no matter the config I tried.

❓️ Is there a way, to combine JIT and generating overrides files like this?
https://developer.hashicorp.com/terraform/language/files/override#merging-locals-blocks

Starting to dig into this feature
https://atmos.tools/stacks/generate

We've Updated the Atmos Native CI examples also to use containerized steps rather than run github-action-setup-atmos since it's way more performant.
https://github.com/cloudposse-examples/atmos-native-ci

We've added an example of using Atmos Native CI with GitHub Job Matrixes:
https://github.com/cloudposse-examples/atmos-native-ci-advanced

Hey guys, I have a question about ci.comments is there a ENV to disable this?
https://atmos.tools/cli/configuration/ci/comments

I like it and want it for most of my CI/CD workflows but I'm trying to do a custom drift detection workflow where I will not like this to be trigger but I don't see a way to disable this using an ENV like ATMOS_COMMENTS_ENABLED=FALSE

Yes, we are moving away from account map for all new engagements. For the next year, we need to straddle a world where both work, before we fully yank it out. We therefore use a providers.tf mixin that doesn't use account map.