This message was deleted.
# atlantis-community
s
This message was deleted.
c
I'm assuming that's not what
ATLANTIS_GH_APP_SLUG
changes.
p
are you using the new options for multi server?
executable_name, config name etc?
c
Hrm. I don't think so. Let me take a look.
We aren't using those at the moment, would those change this at all?
Is executable name going to change that component?
Because we don't really worry too much about the actual atlantis commands, it's the status checks that's the issue atm.
I should take that back, we're using the config name thing so we can have separate config files, but not changing the executable name atm.
Hrm. Actually, is this something that can be solved with ATLANTIS_SILENCE_VCS_STATUS_NO_PLANS? If we can just have atlantis-nonprod not give any status check for prod changes, for instance, that would be fine, the problem now is that it will just sign off on prod changes because nothing is changing.
p
there is basically features that were added a few releases ago that made it easier for using multiple atlantis server with the same repo
the idea of the atlantis executable is that when you do
atlantis-prod plan
only the prod atlantis response back, the rest will discard the command
and options like this : ATLANTIS_SILENCE_VCS_STATUS_NO_PLANS will help with the noise
silence-no-projects too etc
c
Yeah, we have silence no projects, but the problem is that the Atlantis server that has no projects in the PR will still respond about the
atlantis/apply
status check and Github only looks at the last one to respond for whether it's the right one it's looking for.
That's the thing I'm wondering if ATLANTIS_SILENCE_VCS_STATUS_NO_PLANS will fix
p
yes that is why that is for
👍 1
c
Okay, awesome.
p
but you combine that with the executable name too
c
Does the executable name change the status check name?
p
mmm good question, I believe it does
you will have to test it , I do not remember
c
Really. Okay, we can give that a try then.
Thanks!
👍🏽 1