https://www.runatlantis.io/ logo
Join Slack
Powered by
This message was deleted.
# atlantis-community
s
This message was deleted.
t
Another item that comes to mind is allowing 
atlantis apply
based on configuration, either within atlantis or via codeowners.
p
for github you can use gh-team-allowlist
t
I’m use gitlab, i’m aware of this pull request to add gitlab group support, i’m thinking i’m wanting finer grain control. Basically apply constraints/allowlists by path. From the documentation 
gh-team-allowlist
applies to all of atlantis right?
p
yes, no paths
t
Would the project be open to accepting it as a feature? I’m early into using atlantis and will likely implement something like this as a step within the apply where i exit non-zero to test the idea. The original problem i’m trying to solve is preventing teams from apply other teams merge requests within a monorepo.
p
yes we will be open but we will require plenty of tests and support to be VCS agnostic (as.much as possible )
it will be an enhancement to the current implementation
o
@Tiago Meireles you can use CODEOWNERS for that
p
that is possible in github
o
In Gitlab too
p
ohhh cool, I didn't know that
t
CODEOWNERS limits who can approve the change in github/gitlab, but from testing it doesn’t restrict who can merge in.
o
Do you mean a situation when someone can plan changes in MR/PR before approval?
Or you use approval mechanism for planning and would like to control changes also on merge?
t
No. I want to limit who can run 
atlantis apply
after mergeability requirements are meet.
o
If 
atlantis apply
requires MR approval, you may add “require approval from CODEOWNERS”
But your code should be organised accordingly
if you have aaa bbb ccc you may organise approval of CODEOWNERS of any of those, if changed aaa and bbb - approval from CODEOWNERS aaa and bbb will be needed
if just ccc - approval of ccc CODEOWNER will be needed
if request approved by CODEOWNER - it can be applied by atlantis
However if you have MR with changes in aaa - it shouldn’t provide a possibility to modify resources of bbb/ccc
I mean it shouldn’t provide such possibility by design
It’s actual question… I’m working with Terragrunt and have monorepo and something like
Copy code
aaa
bbb
ccc
_common
where _common contains some glue code and changes in _common may affect aaa, bbb and ccc
t
I’m referring to running the 
atlantis apply
, at that point the codeowner requirements are fulfilled, anyone with repo access can run the 
atlantis apply
. I’d like to limit who can run 
atlantis apply
by path.
o
hm…
t
e.g. prevent 
aaa
from 
atlantis apply
a merge request for a 
bbb
path, after 
bbb
codeowners have already approved the merge request.
o
Looks complex
You’re trying to separate duties inside MR
🤔
Probably that could be done using policies
t
Can policy check run during the apply step? I was under the impression from the docs that it runs during the plan step.
Open in Slack
PreviousNext
Powered by