This message was deleted.
# atlantis-community
s
This message was deleted.
s
any help with this? sometimes it merges sometimes it doesn't. any way to know why (or why not) it is doing that?
c
It will only merge if all affected projects are applied.
Or at least...that's supposed to be the behavior. Are the other ones no-ops?
Trying to think if I've ever seen this happen, but I don't think so -- on the other hand, I have
atlantis/apply
set as a required status check for merging in Github.
That might be something you want to flip on, since it should keep this from happening on the github end, rather than the Atlantis end.
s
for $reasons, a single PR has an ALB, target group and ASG. because the TG would be first, we do a plan and apply of the TG first. in two instances we have observed differing behavior, once it merged the entire PR when the
apply
for the TG completed and once it did not. a "do not merge" tag seems the simplest solution
c
Out of curiosity, why do you have those all in separate projects?
Or is that also $reasons 🙂
(Which I understand)
Just thinking if they shared a project the ordering should automatically get taken care of if you use outputs as parameters etc
s
$reasons == cascade effect of legacy approach; resources are created separately as much as possible and other resources look them up using
data
sources. of course, this is not true for "ALL" resources, but this combination is in this mode.
security groups
are also another bunch which are created separate.
c
Ooof. The branch protection status check is probably the easiest fix here, but consolidating those projects is probably in your best interest eventually.
(which you may already realize)
s
no, merging the projects is not an option. I think I'll try with a tag. jfyi, there is a pre step of rendering various elements; think terragrunt, but in Python, using Jinja2 templating. the ordered way of creating resources is the way which I foresee continuing for the recent future. I checked the ordered priority which Atlantis supports, but it would be trickier than the simple "do not merge" type of label on the PR. Thanks anyway!
c
No problem!