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 installation as a GitHub App #418

Closed
chrisob opened this issue Jan 9, 2019 · 18 comments
Closed

Support installation as a GitHub App #418

chrisob opened this issue Jan 9, 2019 · 18 comments
Labels
feature New functionality/enhancement

Comments

@chrisob
Copy link
Contributor

chrisob commented Jan 9, 2019

Currently, Atlantis can be installed on GitHub by separately:

  1. Creating a CI user
  2. Configuring a personal access token
  3. Manually configuring a webhook for each organization/repository

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.

@nikovirtala
Copy link
Contributor

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.

@pratikmallya
Copy link
Contributor

pratikmallya commented Jan 17, 2019

Manually configuring a webhook for each organization/repository

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?

@chrisob
Copy link
Contributor Author

chrisob commented Jan 17, 2019

@pratikmallya Good to know, that makes it a little bit easier :)

these steps could be more easily managed from a single place

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.

@pratikmallya
Copy link
Contributor

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.

@pratikmallya
Copy link
Contributor

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 :-)

@lkysow
Copy link
Member

lkysow commented Jan 17, 2019

Atlantis seems pretty dumb

😪

@lkysow
Copy link
Member

lkysow commented Jan 17, 2019

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.

@chrisob
Copy link
Contributor Author

chrisob commented Jan 17, 2019

@lkysow

we then need to add oauth callback ability, and the ability to start Atlantis without credentials

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:)...

@pratikmallya
Copy link
Contributor

pratikmallya commented Jan 17, 2019

to enterprise orgs running their own GitHub EE, where creating a CI user isn't always straightforward.

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

@kipkoan
Copy link
Contributor

kipkoan commented Jan 18, 2019

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...

@smiller171
Copy link

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.

@lkysow lkysow added the feature New functionality/enhancement label Apr 4, 2019
@cliffchapmanrbx
Copy link

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.

@timhirsh
Copy link

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.

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.

@pratikmallya
Copy link
Contributor

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.

@unRob
Copy link
Contributor

unRob commented Mar 6, 2020

@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!

@etwillbefine
Copy link

etwillbefine commented Apr 29, 2020

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!

@unRob
Copy link
Contributor

unRob commented Aug 6, 2020

This landed with #1088 🎉

@lkysow
Copy link
Member

lkysow commented Aug 6, 2020

Right, this can be closed now.

@lkysow lkysow closed this as completed Aug 6, 2020
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.

10 participants