Does atmos pro allow applying each commit like in spacelift ? or does atmos pro only allow for applying on the default branch ?

Atmos Pro simply dispatches workflows that take whatever parameters you've given it. That said, our typical workflows frequently include component name, stack name, and some SHA. Meaning that on pull requests, we plan for the SHA of the pull request. On merges, we apply using the main branch SHA

Ah interesting

Yes, drift detection always runs on the main branch, but I'm not sure what you mean by "large blast radius." there are two different types of triggers: drift detection and GitHub events. A GitHub event is like an open, synchronized, or merged PR, which is compares 2 SHAs and dispatches all affected stacks between them Drift detection is a scheduled or manually dispatched event which runs always against the main branch (or default branch). It does not compare anything and instead just triggers each enabled instance (component + stack) independently

Let’s say there are 2 changes to s3-test-ue1-dev 1. Bob created PR #1 for s3-test-ue1-dev adds bucket key, merged and not applied 2. Alice created PR #2 for s3-test-ue1-dev adds an s3 lifecycle hook, merged and not applied 3. Drift detection detects 2 changes unapplied for s3-test-ue1-dev and creates an issue I don’t want a single apply to apply both PR 1 and PR 2. How can I allow Bob to apply the change in PR #1 using drift detection and allow Alice to apply the change in PR #2 using drift detection?

Oh, I believe I see what you're referring to. In the previous approach we had without Atmos Pro and only using GitHub Actions, we ran drift detection when a PR was merged. When there were detected changes, we would open an issue However, now with Atmos Pro, it's much simpler, and we aren't using GitHub issues anymore. The specified workflow is simply run when the PR is merged. In our case, that is apply Terraform. 1. In Atmos stack config, you map specific GitHub events to GitHub workflows 2. In GitHub, you set up GitHub Actions workflows to run on some of those events (PR opened, merged, etc) 3. In GitHub, GitHub Actions uploads the affected stacks DTO from GitHub Actions to Atmos Pro 4. Atmos Pro receives that list of affected stacks for a specific event, including the stack config mapping of GitHub event to workflow 5. Atmos Pro then dispatches that specific GitHub workflow for each affected stack So in the scenario above: 1. When PR1 is merged, the changes from PR1 are compared against the main branch at that time. GitHub Actions uploads that list of affected stacks to Atmos Pro 2. Atmos Pro ingests that list of stacks and dispatches the specified workflow for every single one, typically Terraform apply. 3. Then, when PR2 is merged, it does the exact same thing. the SHAs are compared when that PR is merged and affected stacks are uploaded to Atmos Pro 4. Atmos Pro then dispatches those workflows This means you may have workflows queued for s3-test-ue1-dev. The first from PR1, and the second from PR2. You can set up workflow concurrency if you'd like to cancel one and apply the second. But that's entirely configurable in the workflow itself However, regarding number three, drift detection has no knowledge of these PRs or current status. It just dispatches the detect workflows when it is triggered from the main branch. If there are unapplied changes, then they show up on the dashboard as unapplied, where you can then trigger remediation as you'd like

cc @Daniel Engel @Pablo Paez

FYI, we have a major improvement to the dashboard hopefully going out today