First draft, suggestions for improvements are welcome. The snippet
should serve as the idiomatic guide on how to get all pages for a given
resource (a common use case without an obvious solution, hence the docs
can be very helpful).
Includes additions to User, Organization, Repository, and Gist. Some
minor changes to existing fields based on changes in the v3 API (for
example, Gist.User became Gist.Owner). Most everything else is new
additions.
refs #103
This includes all of the methods mentioned in this blog post:
https://developer.github.com/changes/2014-03-18-paginating-method-changes/
as well as a handful of others I found. Sadly, this is a breaking
change for many of these methods because it changes the method
signature, but with yesterday's API change these methods are now broken
anyway. :(
instead of inspecting the JSON tags on the struct fields directly,
actually run it through JSON marshalling and unmarshalling, then compare
those results.
So it appears GitHub already supports multiple types of subscriptions:
repositories and threads. I'm leaving the data type simply as
'Subscription', but am updating the method names to avoid confusion,
since they're both part of the ActivitiesService.
depending on who people are using rate.Reset this may or may not be a
breaking change, since Timestamp supports all of the exported methods
from time.Time.
this is a breaking change, but this was only recently added so I'm not
too worried. This also seems the best way to handle sub-namespaces on
this method.
I changed my mind. This really is terribly verbose, and looking at the
design of the API, it seems unlikely GitHub would change the
subscriptions endpoint to include anything other that repositories. And
if they do... well, we'll deal with it.
(I kinda hate how long some of these names are... I'd much rather just
call them "subscriptions", but the API docs is pretty consistent about
calling them "repository subscriptions", so that's what we go with.
Maybe the intend to later add other kinds of subscriptions?)
This tool help to identify fields being returned by the GitHub API that
are not currently being mapped onto our Go data types. Some of these
may be deliberate omissions, so these checks should only be treated as
an aid in identifying these fields, not as an absolute list of fields to
be added.
The test public key used in these tests is a key that I just generated
specifically for this purpose. I deleted the associated private key, so
even if someone accidentally left this attached to their account, it
should have no effect. Of course, I have no way of actually proving
that I deleted the private key, so uh... yeah. All the more reason to
never run these integration tests using a "real" GitHub account, always
use a dedicated test account.