The GitHub docs don't make it completely clear that AddEmails is also
switching to the new v3 response format, but new integration tests
verify that it is.
This is a breaking change, but it appears that this method has been
broken for some time now and no one has complained yet, so I'm going to
assume no one is using it yet.
Notably, this is also the first (of many, I'm sure) bug I've discovered
while working on the new integration tests (#98). Yay for better tests!
With this code it should be possible to tick the ‘Content’ box in issue
#37. The code is written after reviewing PR #64 and so is (very)
loosely based on that PR. So big thanks for the work already done by
@octavore! I did however had some different insights about a few fixes
and as the PR hasn’t moved for the last 5 months, I thought to just
rewrite and PR and I send in a new PR hoping to come to a merge…
Using an *Issue in IssuesService.{Create,Edit} means that the Labels
and Assignee fields do not serialize to the correct JSON representation
for the GitHub API. This change introduces an IssueRequest struct to
use instead, allowing labels and assignees to be set on create or edit.
Inspired by the Ruby version [1], UploadReleaseAsset now accepts a
simple path to a file.
The Content-Type is now determined internally using the
mime.TypeByExtension() function.
Note this version is also more flexible. Indeed, the previous version
needed an io.Reader, but actually only 3 kinds of io.Reader were bore.
This is because of http.NewRequest needs to determine the Content-Length
of the body, and it can only determine it for bytes.Buffer, bytes.Reader
or strings.Reader [2]. Note there is an issue raised about this [3].
With a path to a file, we can easily determine the file size, and then
manually add it to the request.
[1]
https://github.com/octokit/octokit.rb/blob/master/lib/octokit/client/releases.rb#L85
[2] http://golang.org/src/pkg/net/http/request.go#L447
[3] https://code.google.com/p/go/issues/detail?id=6738