Add Github Enterprise support

[nessamurmur]

Not sure what else might need to be done to get this working... but the integration test works for me when configured for our Github Enterprise instance. Here's a screen shot of the results from that:

NOTE: We have a self-signed cert... not sure what the best way to handle that would be for you guys...

[brynary]

Thanks! We are actually considering moving away from the GitHub comment notifications, now that GH supports multiple PR statuses, because we believe the latter is a better user experience.

Would the PR statuses meet your needs? If so, can we update this PR to only provide the status-based updates (therefore, it won't need either of the two boolean/checkbox checkbox fields we ask for currently).

Thanks!

[calavera]

Thanks @niftyn8!!

I'm not sure if we want to go this way or use the repository url to check whether you're using GitHub Enterprise or github.com. Check the meta endpoint out https://developer.github.com/v3/meta

The self signed certificate will be a problem for sure, since we don't have a way to handle that right now. We've had similar issues in the past and it's something that we should address somehow. //cc @noahd1

[nessamurmur]

We are actually considering moving away from the GitHub comment notifications, now that GH supports multiple PR statuses, because we believe the latter is a better user experience.

Would the PR statuses meet your needs?

Totally, that sounds great. Happy to make that change myself or leave it to y'all, you just tell me.

I'm not sure if we want to go this way or use the repository url to check whether you're using GitHub Enterprise or github.com.

Am I understanding correctly you're saying you're not sure if there should be two seperate Github classes, one for Github proper and one for Enterprise, or if GitHubPullRequests should take a base URL and use the /meta endpoint to determine the base API url?

Thinking the latter actually might be better. Was just looking for a short path with this PR. Let me know if you'd like me to make some changes or if you want to take it from here.

Thanks!

[brynary]

RE: the self-signed certificate. My gut would be to add a boolean configuration option titled "Verify SSL certificate" (defaults to true). Users who have self-signed certs can turn it off at their own risk.

@niftyn8 If I understand correctly, I think Calavera was commenting not on implementation, but on whether functionally we want to represent this as two different integrations (GitHub.com and GH:E) to end-users, or whether we would auto-detect the difference behind the scenes.

@calavera given an arbitrary Git host (e.g. scm.example.com), we don't actually even know if it's a GitHub (vs. BitBucket, etc.), so I think this is a simpler way to go (at least for now).

[nessamurmur]

Ah cool. Thanks for the clarification.

Again, let me know if I can do anything to help move everything forward and get stuff off y'all's plates.

Appreciate the help!

[brynary]

@niftyn8 can you please update this PR to?:

• Remove the checkboxes for comment vs. PR status (it will always do PR status)
• Add a checkbox for SSL certificate verification (default true). The code will need to set the proper verify mode on the HTTPS client.

[nessamurmur]

Hey @brynary let me know if this looks good. Disabling SSL Verification this way worked well for us using the github pull request test.

[nessamurmur]

Do you think it makes more since to have a checkbox defaulted to checked for SSL Verification or have a "Disable SSL Verification" checkbox that's defaulted to unchecked and only disable if it gets checked?

[gdiggs]

Closing this in favor of #80