Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for atlantis.yaml only from a specific branch #322

Closed
sstarcher opened this issue Oct 18, 2018 · 5 comments
Closed

Support for atlantis.yaml only from a specific branch #322

sstarcher opened this issue Oct 18, 2018 · 5 comments
Labels
feature New functionality/enhancement

Comments

@sstarcher
Copy link

Currently if we use an atlantis.yaml anyone who makes a PR can inject adhoc commands. It would be preferable if we could restrict the atlantis.yaml to say the master branch. Where a user could PR an atlantis.yaml, but it would have to be approved and merged before it would take effect.

This would limit the adhoc commands to needing to be approved by someone and merged instead of just anyone who can created a PR.

@osterman
Copy link

Sounds a little bit related to this discussion: #43

@sstarcher
Copy link
Author

It's similar, but does not accomplish the same thing. In my case I never want atlantis to run using a atlantis.yaml from the commited code.

I only want the atlantis.yaml to run from master even if someone changes it on their branch.

@lkysow
Copy link
Member

lkysow commented Apr 4, 2019

Server-side config should solve this. You can specify your commands on the server side and not allow repos to do anything.

@lkysow lkysow closed this as completed Apr 4, 2019
@lkysow lkysow added the feature New functionality/enhancement label Apr 9, 2019
@GabeL7r
Copy link

GabeL7r commented Jul 17, 2019

@lkysow I don't think server-side config solves this problem. We have a use case where we have multiple projects and each one may have different workspaces and/or workflows. Each project is owned by a different team and they should have the flexibility to customize their workflows, apply requirements or workspaces used. Using a server-side config would limit their ability to do this and involve another team to perform their updates.

Using repo side config grants them this flexibility. However, it allows a bad actor to change the config in their feature branch and bypass any protections in place. By restricting the repo side config to the master branch this would ensure that a PR has to be approved and merged before that configuration takes effect.

Granted, only trusted developers should have access to the repo but if a disgruntled employee decides to rage quit on the last day they could cause harm.

@FalconerTC
Copy link

I would also like to see this feature!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New functionality/enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants