-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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 installation as a GitHub App #418
Comments
I like this idea a lot. Creating such kind ci/machine users with personal access tokens or using developers personal access tokens for CI does not comply with the least privilege principle which we are trying to implement. Not only an Atlantis problem, though. |
You can setup an organization to send webhooks to atlantis and whitelist the repos you want it to run on. Does running as an app provide any other benefit? |
@pratikmallya Good to know, that makes it a little bit easier :)
Other than this ⬆️ , it also eliminates the need to create a CI/technical user entirely (which, if using a self-hosted GHEE, some organizations make it very hard to create technical users). IMO, GH apps make managing bots a lot easier, as you can do it all in one place, as opposed to managing webhooks and bot permissions separately. |
They require refactoring the code to use ruby to handle requests from github. I don't think it is impossible, but it makes the architecture of the app needlessly complex without offering significant benefits IMO. |
Github apps are really nice if you want a feature rich application that integrates nicely with github. Atlantis seems pretty dumb (which is a good thing) so it doesn't seem like it could offer much benefit. Also, atlantis works across github, bitbucket etc. so this would be a github only thing too :-) |
😪 |
AFAIK official GitHub apps require a permanent callback URL. Since each user installs their own Atlantis, this won't work since the callback URL needs to change for each installation. Instead, we could have users manually create a new Github app similar to how Terraform Enterprise works (https://www.terraform.io/docs/enterprise/vcs/github.html), however we then need to add oauth callback ability, and the ability to start Atlantis without credentials (since it comes later) and a bunch of other complexity. So IMHO given that the current installation method seems to work, I'm not sure this is worth the effort. |
If you're referring to the authentication flow to get a JWT token, I can see where that could introduce some complexity in existing code. As a counter-argument, I think adding this feature would make Atlantis more attractive to enterprise orgs running their own GitHub EE, where creating a CI user isn't always straightforward. BUT I also can understand the desire to keep Atlantis "dumb" (:rofl:)... |
Hmm, I've used Github EE at two BigCorps so far and yes both had some issues getting a CI account but they werent a huge blocker. Also remember that Enterprises probably pay for TFE instead anyways; I think atlantis is more for smaller/medium size companies that can't afford TFE and/or like the customizability of atlantis over TFE |
Or can’t justify the cost of TFE (even if they are a larger company), or want to contribute to the open source community... |
I think there's some benefit to doing things the "right" way. Atlantis isn't a user, it's an application. Given that's the case, it makes much more sense to authenticate it ass an app than as a user. Additionally, authenticating as a user means Atlantis will cost me money (though not a large amount) where it wouldn't if authenticating as an app. |
Bumping this hard, each user account in our GitHub Enterprise appliance costs money, and with multiple teams running their own Atlantis that starts adding up quickly. I've implemented a GitHub App using C# and not making use of the Octokit.NET library as it doesn't have full support for the app features I needed. It took me less than a day to get it communicating properly. It should be relatively straightforward to migrate Atlantis to use a GitHub App connection instead of a user account. Please reconsider the priority of this feature. |
This is the case for me. We have a single CI user and that rate limit is shared across all use cases that require a personal access token (Atlantis being just one of many). Having the ability to use a GitHub app and generate JWT's allows each use case to have a separate rate limit. |
As an early naysayer I wanted to say that after a year I do see the benefit of doing this : ) and have changed my opinion to yes, this is really required. Installing atlantis is probably the biggest barrier to its usage. Since apps that interact with Github seem to be configured as Github Apps, it certainly makes a lot of sense to deploy atlantis as a Github App. The only counterpoint would be that atlantis supports other VCS (not just Github) so this would introduce a Github-only mode of deployment. |
@pratikmallya We're evaluating replacing a bunch of python scripts with Atlantis and would love to see this issue addressed. Just to get an idea of feasibility I whipped up unrob/atlantis#1, but this is the first time I interact with this codebase and I'm not sure this is an approach worth iterating on, so any guidance or feedback would be appreciated! |
Just run into a proof of concept implementation as well. For me it was pretty easy to use go-github with auth for apps (https://github.com/bradleyfalzon/ghinstallation) maybe that helps to speed up things (see mentioned PR above). Would love to see this feature merged! |
This landed with #1088 🎉 |
Right, this can be closed now. |
Currently, Atlantis can be installed on GitHub by separately:
If Atlantis could be installed as a GitHub App, these steps could be more easily managed from a single place (the GitHub Apps settings page).
Additionally, if the webhook is created on the org level, it would be possible to configure which repos Atlantis will operate on on the fly using the app's GitHub settings without having to stop Atlantis to change the
--repo-whitelist
value.The text was updated successfully, but these errors were encountered: