Support new GitHub Apps (formerly Integrations) API.

GitHub API Announcement:
https://developer.github.com/changes/2017-04-25-Integrations-Pre-Release/

This would be invaluable! The change for user-to-server requests appears to be adding the headers for the media type application/vnd.github.machine-man-preview+json. I have not looked deep into the library but how difficult would this change be for a new contributor to delve into?

Skimming the docs, this would be a fair amount of work to get this up and running, but would be a fantastic learning experience. 😃

The Integrations API has now been deprecated in favor of the new GitHub Apps API.
This issue should now focus on the latest GitHub Developer API announcement:
https://developer.github.com/changes/2017-05-22-github-apps-production-ship/

I think they were just renamed, not deprecated. But yes, it's called GitHub Apps now.

A month ago, we moved GitHub Integrations into pre-release, and today it's available for general release. As this new functionality is the preferred way to extend GitHub, we've renamed it GitHub Apps.

Edit: Never mind, some form of deprecation was involved too. I guess that makes sense, given that the rename would've been a breaking API change.

The Integrations API has been deprecated in favor of the GitHub Apps API.

@cyberdelia

Just on this, the Breaking Changes will need to be addressed, in particular, the integration specific events introduced in b0b867f by @cyberdelia will need to be renamed.

They are sending both events until November 22nd 2017, and I can see they're doing this on my own installations, receiving installation_repositories and integration_installation_repositories as well as installation and integration_installation.

I'm happy to take this on in time if others aren't. The first question would be exactly how go-github wants to handle this transition, considering both deprecated and new events appear to be supported at the moment, is the first stage simply to implement the new name and remove the old later? Or just a breaking change to rename the events?

Skimming the docs, this would be a fair amount of work to get this up and running, but would be a fantastic learning experience.

In case you hadn't seen it, I've been maintaining and using https://github.com/bradleyfalzon/ghinstallation with go-github for some time quite successfully.

In case you hadn't seen it, I've been maintaining and using https://github.com/bradleyfalzon/ghinstallation with go-github for some time quite successfully.

Do you think it's ready to be considered for addition to the README, in its own section? If so, want to send a PR that does that (and update both doc.go and README.md)?

Do you think it's ready to be considered for addition to the README, in its own section?

Yes, it's been tested for just over 6 months now without problems. My only real concern is that it only provides authentication as an installation workflow, not authentication as an integration, but that could be added at a later stage as a non-breaking change. I didn't add it previously because there was no use case for that flow other than fetching tokens to authenticate as an installation, but now there's a couple APIs

If so, want to send a PR that does that (and update both doc.go and README.md)?

I've sent through a minor one-liner, as I did begin to write a larger section which mostly just duplicated the docs already in https://github.com/bradleyfalzon/ghinstallation, so just pared it back to a minor note. Let me know in the PR if you'd like me to expand upon the docs though, happy to.

I'm happy to take this on in time if others aren't. The first question would be exactly how go-github wants to handle this transition, considering both deprecated and new events appear to be supported at the moment, is the first stage simply to implement the new name and remove the old later? Or just a breaking change to rename the events?

I'm currently receiving the error unknown X-Github-Event in message: installation_repositories from ParseWebhook, this is the new name of the event and as mentioned previously it's a duplicate event sent by GitHub to help migration (so the event was still sent).

Potential migration strategy:

Edit eventTypeMapping to rename integration_installation and integration_installation_repositories keys (not values) to installation and installation_repositories respectively.
Rename the types IntegrationInstallationEvent and IntegrationInstallationRepositoriesEvent

Considering both of those changes could be written as a simple (for example) gofmt -w -r 'IntegrationInstallationEvent -> InstallationEvent' ./internal/github/handlers.go, and it was a preview feature, a breaking change IMHO would be fine.

Another option could include keeping the old events but parsing to the new renamed type (eg installation_repositories event parses to InstallationRepositoriesEvent), so we don't return an error and parse the old event correctly, then leave it up to the user to decide which event they want to parse and which they want to ignore. We could then continue to keep the old and new types too to have a zero breaking change migration option, and just remove the old types when GitHub stops sending them.

Thoughts or other options?

Considering both of those changes could be written as a simple (for example) gofmt -w -r 'IntegrationInstallationEvent -> InstallationEvent' ./internal/github/handlers.go, and it was a preview feature, a breaking change IMHO would be fine.

Agreed. In general, for preview APIs, we should prefer breaking API to follow suit with any changes on GitHub side.

Another option could include keeping the old events but parsing to the new renamed type (eg installation_repositories event parses to InstallationRepositoriesEvent), so we don't return an error and parse the old event correctly, then leave it up to the user to decide which event they want to parse and which they want to ignore. We could then continue to keep the old and new types too to have a zero breaking change migration option, and just remove the old types when GitHub stops sending them.

Honestly, I'll leave it up to you to decide if it's worth doing that. My suspicion is that it's okay not to, since this is still within preview API territory (if I understand correctly). So it depends on whether the benefits justify the amount of extra work.

OK, leave it with me then, I'll make the breaking change as it's easy for clients to fix, and helps keep the history clearer (single one-liners, instead of giant copy/paste).

I think they were just renamed, not deprecated. But yes, it's called GitHub Apps now.

The old ones have been removed from the documentation, but they're still being sent along with the new ones according to https://platform.github.community/t/integration-installation-hook-event-name-changed-to-installation/1830

I confirmed that both are being sent with a test app yesterday.

Rename GitHub Apps installation and installation_repositories events.

doc: Add link to GitHub Apps authentication package. (#649)

Rename GitHub Apps installation and installation_repositories events.

doc: Add link to GitHub Apps authentication package. (google#649)

GitHub ignore deprecated integration installation events

Rename GitHub Apps installation and installation_repositories events.

doc: Add link to GitHub Apps authentication package. (google#649)

Navigation Menu

Repository navigation

Support new GitHub Apps (formerly Integrations) API. #627

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support new GitHub Apps (formerly Integrations) API. #627

Description

Activity

vogxn commented on May 17, 2017

gmlewis commented on May 17, 2017

gmlewis commented on May 25, 2017

dmitshur commented on May 25, 2017

bradleyfalzon commented on May 25, 2017

dmitshur commented on May 26, 2017

bradleyfalzon commented on May 26, 2017

bradleyfalzon commented on May 29, 2017

dmitshur commented on May 31, 2017

bradleyfalzon commented on May 31, 2017

kytrinyx commented on Jun 2, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions