This change improves consistency by adding missing ",omitempty"
option where they belong. This makes it so that `nil` values get
omitted when/if marshaled to JSON. Non-nil values are always
included.
With the release of GitHub Apps (was GitHub Integrations), GitHub
have renamed the integration_installation and integration_installation_repositories
event to installation and installation_repositories respectively.
This is a breaking change for those using this API, and can be fixed with:
gofmt -w -r 'IntegrationInstallationEvent -> InstallationEvent' [path ...]
gofmt -w -r 'IntegrationInstallationRepositoriesEvent -> InstallationRepositoriesEvent' [path ...]
Closes#627.
Updates #434.
The `Event.Payload` function can fail in instances when it receives invalid
json. (example: when parsing a webhook that is set to application/x-www-form-urlencoded)
If this happens, we shouldn't panic but instead return an error to let the
caller know about the failure.
Added in a new function, `Event.ParsePayload` to take its place and depreciated
the old function.
* #514: added inviter to Invitation for orgs and teams invite
* #514: go fmt
* #514: removed prints
* #514: changed time data types and included them in test
* #514 Added Org List Pending Invitations
* #514 removed typos in error handling
* #514: Modified to pointer time.Time in Invitation
* #514: Set up Naming conventions for multi words, pointer to bool
* #514: multi word variable format
* #514 : used User instead of new struct
* #514 : removed Inviter struct
* #514: Added quotes to list values in comment
* implementation of webhooks for project, projectcard and project column
* Added Changes in event types
* Added Comment for variables populated by webhook
* #530: Made all Changes struct inline
* #530: Modified Changes Structs to include the full names of Changes
* #530 : Review comments from gmlewis fixed
* #530 : Fixed Consistency issues with GitHub docs #562
* #530:generator code
This is a large breaking API change. It is unavoidable and necessary
to resolve#526. This breaking change is part of bump to libraryVersion 3.
It adds ctx context.Context as first parameter to all endpoint methods,
including Do.
Updating for this API change should be easy and the compiler will help
catch instances that need to be updated. For example:
main.go:193: not enough arguments in call to gh.Activity.MarkRepositoryNotificationsRead
have (string, string, time.Time)
want (context.Context, string, string, time.Time)
...
You should pass the available context as first parameter. If your code
does not have context.Context available and you want to maintain previous
normal behavior, use context.Background(). Don't pass nil context; use
context.TODO() instead if you wish to delay figuring out the best context
to use. Then you can address the TODO at a later time.
Refer to documentation of package context at https://godoc.org/context
for more information.
This commit also changes ./tests/fields to use context.Background()
instead of deprecated oauth2.NoContext.
Resolves#526.
This is a breaking API change. However, it removes things that were
deprecated and shouldn't be used anymore (including something that's
available in standard library).
Next commit will be a large breaking API change anyway (which we need
to do in order to resolve#526 in a reasonable way), so it makes more
sense to get rid of the deprecated things instead of updating their API.
http.StatusUnprocessableEntity was added in Go 1.7, and so we can use it
instead of own equivalent constant. Anyone who was previously using it
should switch to using http.StatusUnprocessableEntity as well. Consider
this commit to deprecate StatusUnprocessableEntity and remove it in one.
Helps #526.
This change is a proposal and is open for discussion.
Also fixed a couple locations that were returning nil
instead of returning the valid err.
Change-Id: I62da2980c76d6220ce2ef12e6a1e64b60769ab01
Note that this is an API-breaking change but should have minimal
impact on users of this package due to the nice inference
properties of the Go programming language.
Bumped `libraryVersion` to `2` due to API-breaking change as
discussed in #376.
Fixes#180.
Change-Id: Ib386135e6b8f306d1f54278968c576f3ceccc4e7
this is a breaking change for a handful of Option structs that were
defining the Page option directly (they now embed ListOptions).
finishes fixing #56
This provides somewhat reasonable string representations of GitHub
structs. This is specifically designed for this library and takes a
number of shortcuts where it can, so is not suitable as a general
purpose solution. That said, I am exporting this function because it is
useful for things like printing out slices of GitHub structs, as can be
seen in examples/example.go.
I am certainly open to suggestions for what exactly the stringified
output should look like. Currently, I think I've found a reasonable
compromise between fmt's "%v" and "%s" output.
Like a51d6b4303, this change makes me sad, mainly because it is a
breaking change for all clients, and makes common tasks like reading
data out of structs slightly more work, with no direct benefit. Notably,
developers will need to make sure and check for nil values before trying
to dereference these pointers. Sadly, the change is still necessary, as
is more fully explained in issue #19. We can make the nil pointer
checks a little easier by adding some Get* funcs like goprotobuf does.
I spent a lot of time over the last few weeks exploring this change
(switching fields to pointers) versus the much larger change of using
protocol buffers for all GitHub data types. While the goprotobuf
library is very mature and feature-rich (it's used heavily inside of
Google), it's the wrong tool for this task, since we're not actually
using the proto wire format. While it does address the immediate
concern in #19, it makes way too many other things terribly awkward.
One of the biggest drawbacks of this change is that it will make the
string output from fmt.Printf("%v") next to useless, since all pointer
values are displayed as their memory address. To handle that, I'll be
writing a custom String() function for these structs that is heavily
inspired by goprotobuf and internals from go's fmt package.
The truth is, this change makes me sad. It's a breaking change
for all clients and it adds more complexity to the library surface. In
most cases, clients will simply drop the Response object on the floor
(which is actually all the library itself was doing before this
change... now we're just pushing that off to the client).
Initially, the Response object will be primarily of interest for
functions that return paginated result sets, since the Response.NextPage
field is the only way to know for sure if there are more pages that
should be fetched. And this is really the cleanest way to get at that
data, so in that respect this change isn't so bad.
It's also worth noting that returning the raw Response object makes a
lot more since in a GitHub library than it may in others, given how
GitHub makes liberal (read: proper) use of HTTP request and response
headers. Other APIs, like Google's various APIs for example, tend to
push things like pagination links into the response body. While this is
certainly less of a purist view in terms of REST, it does make the lives
of client developers a lot easier, since then the response body contains
everything you need to know. But whatever; this is how GitHub rolls, so
we'll roll right along with them. (Somewhat ironically we are ignoring
the RESTful links in the GitHub response bodies, since we're actually
calling the API in an RPC style and don't do anything with those links.)
We still don't have an easy way to set arbitrary request headers, but
that's a problem for another day.
Fixes#22
Steve Hipwell