is anyone else experiencing Atlantis being unable to auto-merge gitlab PRs to
master which the gitlab API moved to the default branch of
main earlier this week?
Bah, looks like you can’t use the inbuilt Atlantis policy checks if using Terragrunt. Anyone else hit this or got it working? Failing when trying to run
terraform show which works when running
This policy set in /etc/atlantis/repos.yaml policies: owners: users: - cscott policy_sets: - name: terraform_version path: policies/terraform_version source: local appears to be failing since a ter…
policies: owners: users: - nishkrishnan policy_sets: - name: null_resource_warning path: <CODE_DIRECTORY>/policies/null_resource_warning source: local
^^ Looking at the conftest/OPA stuff in Atlantis, what can source be there? Does it need to be
Hmm, looks like these need to be local for now…
hey :wave: I’m trying to modify a resource that does not have support with Terraform yet - updating cognito user pool with custom email sender. I can do this with
aws cognito-idp update-user-pool --user-pool-id … . I have added awscli to atlantis image, that’s done, however what would be the best way of passing aws credentials without baking them into the image? Atlantis runs on Fargate at the moment
the fargate task execution role
add the permissions there
if you are running TF already then you probably have the permissions
I’ve been running terraform without issues however, aws cli requires credentials and profile to be configured , doesn’t it?
if it runs on an instance or task
Configure the AWS CLI to use a role defined in AWS Identity and Access Management (IAM).
[profile marketingadmin] role_arn = arn:aws:iam::123456789012:role/marketingadminrole credential_source = Ec2InstanceMetadata
Perfect, thank you @jose.amengual
This is a problem we encounter in certain places too, can’t pass Terraform cred providers down into null_resources, so turn your one liner command into a script and that script needs to assume the correct role.
does anyone know (or have ideas) how to fix atlantis (using the upstream fargate module) taking a long time when a lot of PRs are being executed from different repositories
like how to debug on the server, or how to redeploy?
at present we have quite a few PRs currently being planned/applied across a number of repos
when this happens we find that Atlantis slows down massively
not sure if increasing https://github.com/terraform-aws-modules/terraform-aws-atlantis/blob/master/variables.tf#L284-L288 would help?
Nope, don’t do that.
Atlantis uses a local BoltDB, more tasks isn’t what you want.
i thought that might be the case
Terraform configurations for running Atlantis on AWS Fargate. Github, Gitlab and BitBucket are supported - terraform-aws-modules/terraform-aws-atlantis
Beef up the Fargate task size CPU/mem
Makes a big difference
yeh makes sense
ecs_task_memory = 4096 ecs_task_cpu = 2048
Depends how many concurrent plan/apply you expect to run, how long is a piece of string
We also set
ATLANTIS_PARALLEL_POOL_SIZE to 50
what does that do?
I run on a m5.2xlarge (8 vCPU, 32gb mem) EC2 instance and often have hundreds of plans run in parallel.
i thought that only works when using workspaces?
There is a difference I believe between Atlantis workspaces and Terraform workspaces, if that is what you are thinking of
changes applied, lets see what this does to the speed, fingers crossed
If there is a repo level
atlantis.yaml file containing directories
dir2 and a PR comes in that affects the terraform module
dir3, atlantis will show a
0 / 0 approval check for the PR. This seems like a bug, no ?
The repo level atlantis.yaml for dir1 and dir2 version: 3 projects: - dir: dir1 - dir: dir2 A PR for only dir3 and I see this atlantis/apply — 0/0 projects applied successfully. atlantis/plan — 0/0…
and if you run atlantis plan manually it says no plans?
it says no plans
oh, not sure how to run atlantis manually. ill have to check that