|Discuss the Atlantis (<http://runatlantis.io||runatlantis.io>)|
**Archive: ** https://archive.sweetops.com/atlantis/
Probably want to squash some of those commits
nothing secret in there but actually I do not know how to delete some
I tried, it became a huge mess
I should have done it before I created the PR
Hey all - I have a couple of questions for this channel around management of Atlantis.
- Right now we’re the Terragrunt IAC repo pattern for all of our infrastructure. This has expanded quite quickly due to how awesome the self-service of Atlantis has been for us. However, maintaining such a busy repo with trunk-based deployment has started to become a bit of a worry. Has anyone had any thoughts about splitting up repos or abandoning this pattern in favour of workspaces?
- With the way that the Terraform operations are being handled with Atlantis - if another PR of the same repo is merged into master, is there any recommended approach to getting those merged changes added into any open Atlantis PRs? We’re consistently rebasing the feature branches with master during lengthly PR’s. We’re looking at Github actions etc and potentially set up a PoC to try workspaces but wanted to the opinion of others who have experienced a similar situation?
Interesting, at my company we have about 20 eng who touch infra code in a monorepo with trunk-based deployment with about 500 modules and haven’t experienced too much trouble.
You should only need to rebase if another PR affected the same modules or otherwise would affect
output values from dependencies of the module you are running on, which brings up two questions:
- Are your modules maybe too large that multiple devs frequently are changing them at the same time? This should happen now and then, but if you have small enough modules shouldn’t be a constant thing
- If you really are having multiple devs touch the same modules all the time, how would having smaller repos help? You’d just move the problem of touching file X into whichever smaller repo manages file X Is it maintaining the atlantis.yaml that’s worrying you maintenance wise, or something else?
Have people here integrated checkov into their atlantis workflows? or do they utilize github actions?
checkov to atlantis but not through a github action
i added it to via atlantis workflow so it comments the output of checkov’s scan of the tf plan directly in the PR
that’s my thinking, was thinking of running it before the plan
done similar with conftest/OPA
also it helps not to rely on dev teams having to configure github actions
did you use a script and a
-run command to run checkov/conftest in the workflow?
@barak might have some tips
Hey @zeid.derhally, haven’t tried it with atlantis. Sounds like a great fit. @RB (Ronak) (Cloud Posse) do you mind sharing a sample conf? I would be happy to add it to checkov’s docs
cc: @Matt Johnson
Basic terraform cicd setup using atlantis. Contribute to nitrocode/atlantis-terraform-module development by creating an account on GitHub.
awesome, now I can copy paste
that’s not the current one we’re using but it’s an example of how to adopt checkov and tflint and add additional ones like tfsec, opa, etc
thanks @RB (Ronak) (Cloud Posse)
@barak has joined the channel
can Atlantis perform a rolling upgrade style upgrade using the upstream AWS terraform module on Fargate?
On itself? No, it cannot lobotomies itself AFAIK
Does anyone use Atlantis + Terraform Cloud, or is it more of a one or the other situation? I haven’t looked at the cloud much, as it wasn’t around when I set up all our infra code
IMHO it’s one or the other. I wanted to give TC a go, but Atlantis just handles far more at this point and isn’t as opinionated.