Type mismatch with third-party library method parameter

[forstmeier]

Description

It looks like there's a conflict between this library and the bradleyfalzon/ghinstallation library:

cannot use integrationID (type int) as type int64 in argument to ghinstallation.NewAppsTransport

This pops up when I attempt to build my project which uses the go-githubapp library. I assume the fix here is to change the type of the value passed into those ghinstallation.NewAppsTransport and ghinstallation.New methods to be int64 to comply with that library's requirements? If so, I can open a PR to address it - just let me know!

[bluekeyes]

This looks like a recent breaking change introduced upstream: bradleyfalzon/ghinstallation#30. As a quick fix, I'd suggested pinning the dependency version to v0.1.2 or v0.1.3 in your dependency system, if possible.

If that's not possible, and as a long-term fix, updating this library makes sense, so a PR is welcome if you want. I think it might require the same breaking change to our API, since we use an int in the signature of NewClientCreator.

[forstmeier]

@bluekeyes Done. Let me know if you'd like that PR and I can definitely open it (with the knowledge that it's a breaking change as you mentioned).

[bluekeyes]

I looked into this more and I think upgrading bradleyfalzon/ghinstallation to v1.0.0 will also require adopting Go modules, because v1.0.0 uses versioned import paths for google/go-github, which dep does not support when the version only exists in the go.mod file.

We discussed modules a bit in #9, but didn't reach a conclusion. In addition to the problems raised on that issue, adopting modules here I think will require us to release major versions in lockstep with google/go-github going forward.

For now, I added a constraint on bradleyfalzon/ghinstallation in #29, which should at least help other people who are still using dep.