Closed forstmeier closed 4 years ago
This looks like a recent breaking change introduced upstream: https://github.com/bradleyfalzon/ghinstallation/pull/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
.
@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).
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
.
Description
It looks like there's a conflict between this library and the
bradleyfalzon/ghinstallation
library: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 thoseghinstallation.NewAppsTransport
andghinstallation.New
methods to beint64
to comply with that library's requirements? If so, I can open a PR to address it - just let me know!