In 1.210.0 we released Native CI support in atmos. It's 🧪 experimental in terms of maturity, but this is what will soon replace our github actions. ✅ GitHub Status Checks ✅ GitHub Job Summaries ✅ GitHub Outputs ✅ Atmos Toolchain (automatically install opentofu or almost any tool you need) ✅ GitHub OIDC That means this one command:

atmos terraform plan mycomponent -s dev-us-east-1

Can do the following: 1. Authentic with OIDC 2. Install all tools like opentofu 3. Initialize the backend 4. Run Terraform 5. Post Status Checks 6. Post Job Summary Coming soon: • Planfile storage & retrieval: GitHub Artifacts • Comment Support https://atmos.tools/changelog/native-ci-integration https://atmos.tools/cli/configuration/ci

Nice work! Will take it for a spin! I guess the current GHA's for plan and apply are obsolete now. This does mean we still need the "affected" and "drift" pipelines? This is a very nice idea btw!! kudos

output:
    enabled: true
    variables:
      - has_changes
      - has_additions
      - has_destructions
      - plan_summary

So we're building in native support for matrices into atmos describe affected.

atmos describe affected --format=github

nice sales pitch 😉 looks nice, but we are not there yet. Also SAAS solution are always complicated with a pci-dss regulated customer.

Also SAAS solution are always complicated with a pci-dss regulated customer.

There's always self-hosted

people always get nervous when you see "contact sales" 😆

I'm wondering what the workflow should be regarding backend automated provisioning when, during a pull request, we run a tf plan with a read only role on a new production stack for the first time, i.e. with no backend available yet.

workflow should be regarding backend automated provisioning when, during a pull request, we run a tf plan with a read only role on a new production stack for the first time, i.e. with no backend available yet.

Wouldn't this work for you? https://atmos.tools/changelog/automatic-backend-provisioning-on-init

it's what we do, and we link them to projects in TF cloud. Works like a charm

I think it would not: "read-only" role. In a pull request, our pipeline runs "tf plan" on all stable environments. Of course, with a read-only role. The read-write role is only granted for tf apply on push event when the pull request is merged. So, when a pull request declares a new stack for a fully new deployment of something in a new account (let's say for example, first deployment on the prod account of a new product which had so far only be developed and tested up to staging), tf init and tf plan run as read-only, which prevent them to provision the state bucket in that account.

So you are not only talking about the TF backend file but also the bucket and permissions that go along with it? That sounds to me like an "init" or prepare environment step you do before running the plan which you could do under a different role.

Exactly 🙂 But as this PR I mention is the first time the new "instance" appears, I see no other related place or workflow (not in atmos workflow meaning) which could auto-provision the bucket. There is no "prepare step" possible in that model where a R/W role is granted on prod before the PR is merged. So... This leads us to provisioning the state buckets at account creation time (our intent is to have one state bucket per account), i.e. not using atmos auto-provisioning feature in the PR/stacks where I would have wanted it.

Could you describe your ideal backend (bucket) architecture?

Not sure which info you'd want from me here. We intend to use a single state bucket per account. The bucket is not needed before running tf plan in that account, which is what our pull_request event triggered pipeline would do, and in that context, it's not allowed to provision it. I don't see how atmos can solve this, it's not even related to atmos, but rather to how we designed our pipelines. Note that I'm mixing 2 things: • The current pure terraform pipeline we have currently built and behaves as I described • The future pipeline based on atmos + Atmos Pro which does not exist yet, and which I hope will be able to do the same but I still have to find that out

So make a very small module or "stack" you run first. Only purpose to provision the backend

So make a very small module or "stack" you run first

No, the pipeline needs to run tf plan successfully anyway to allow merging and running tf apply 🙂

Personally I think the infra you need to run your pipelines / plans / etc should not be part of the workload. Should already be there

As I wrote, the conclusion to this is that I now adopt your opinion 😄