Several Atlantis servers

[ipeacocks]

I have 1 git repo and 3 different infrastructures in it (different AWS accounts), each env in separate directory.
Some resources in e.g. dev can be applied in dev network only (so atlantis instance needs to be in this network). The same logic for prod env and so on.

So I've thought to install 3 atlantis servers in dev, rc, prod, then connect it with the same git repo and each PR should spawn 3 hooks to each atlantis. On each change should answer only correct atlantis: for dev code changes - dev atlantis, for prod - prod one and so on.

I see that atlantis.yaml has dir option. Does repo.yaml have some equivalent? Hope I was clear.

[jamengual]

you can filter per dir in the repo side using a regex but since is the same repo the 3 servers will respond to any comment command you send so if you trigger a valid run for dev the other 2 atlantis servers will say, no valid workspace or another type of error and they will comment back I have been working on an implementation for this here https://github.com/runatlantis/atlantis/tree/multiserver but it is far from finished.

[jamengual]

if you can deal with error comments you can try maybe using a script to filter out the comments.
there is this too : https://github.com/czerasz/atlantis-org-applyer
and some other approaches that try to solve this issue, look for other issues raised.

[ipeacocks]

you can filter per dir in the repo side using a regex but since is the same repo the 3 servers

Which option do you mean? Could you name it?

[jamengual]

sorry , the server side config does not allow for a regex for directory, only per repo.

[msarvar]

Another option would be to use pre workflow hook. And generate your atlantis.yaml based on what server you're on.

[tinder-tder]

@ipeacocks you can also see #1345

[GenPage]

@ipeacocks Check out #1469. We use this flag to make Atlantis ignore the PR if there are no defined projects that match the modified files in the PR.

[Leooo]

one solution here

[nitrocode]

This may be implemented in the upcoming 0.22.0 release by PR #2805 and #2798. Try the latest 0.22.0 pre-release to see if it resolves this issue

cc @krrrr38