XUtils

github

Go library for accessing the GitHub REST API v3.

Golang
https://github.com/google/go-github

Authentication

Use the WithAuthToken method to configure your client to authenticate using an OAuth token (for example, a [personal access token][]). This is what is needed for a majority of use cases aside from GitHub Apps.

client := github.NewClient(nil).WithAuthToken("... your access token ...")

Note that when using an authenticated Client, all calls made by the client will include the specified OAuth token. Therefore, authenticated clients should almost never be shared between different users.

For API methods that require HTTP Basic Authentication, use the BasicAuthTransport.

Rate Limiting

GitHub imposes a rate limit on all API clients. Unauthenticated clients are limited to 60 requests per hour, while authenticated clients can make up to 5,000 requests per hour. The Search API has a custom rate limit. Unauthenticated clients are limited to 10 requests per minute, while authenticated clients can make up to 30 requests per minute. To receive the higher rate limit when making calls that are not issued on behalf of a user, use UnauthenticatedRateLimitedTransport.

The returned Response.Rate value contains the rate limit information from the most recent API call. If a recent enough response isn’t available, you can use RateLimits to fetch the most up-to-date rate limit data for the client.

To detect an API rate limit error, you can check if its type is *github.RateLimitError:

repos, _, err := client.Repositories.List(ctx, "", nil)
if _, ok := err.(*github.RateLimitError); ok {
	log.Println("hit rate limit")
}

Learn more about GitHub rate limiting at https://docs.github.com/en/rest/rate-limit .

In addition to these rate limits, GitHub imposes a secondary rate limit on all API clients. This rate limit prevents clients from making too many concurrent requests.

To detect an API secondary rate limit error, you can check if its type is *github.AbuseRateLimitError:

repos, _, err := client.Repositories.List(ctx, "", nil)
if _, ok := err.(*github.AbuseRateLimitError); ok {
	log.Println("hit secondary rate limit")
}

Alternatively, you can block until the rate limit is reset by using the context.WithValue method:

repos, _, err := client.Repositories.List(context.WithValue(ctx, github.SleepUntilPrimaryRateLimitResetWhenRateLimited, true), "", nil)

You can use go-github-ratelimit to handle secondary rate limit sleep-and-retry for you.

Learn more about GitHub secondary rate limiting at https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#about-secondary-rate-limits .

Accepted Status

Some endpoints may return a 202 Accepted status code, meaning that the information required is not yet ready and was scheduled to be gathered on the GitHub side. Methods known to behave like this are documented specifying this behavior.

To detect this condition of error, you can check if its type is *github.AcceptedError:

stats, _, err := client.Repositories.ListContributorsStats(ctx, org, repo)
if _, ok := err.(*github.AcceptedError); ok {
	log.Println("scheduled on GitHub side")
}

Creating and Updating Resources

All structs for GitHub resources use pointer values for all non-repeated fields. This allows distinguishing between unset fields and those set to a zero-value. Helper functions have been provided to easily create these pointers for string, bool, and int values. For example:

// create a new private repository named "foo"
repo := &github.Repository{
	Name:    github.String("foo"),
	Private: github.Bool(true),
}
client.Repositories.Create(ctx, "", repo)

Users who have worked with protocol buffers should find this pattern familiar.

Testing code that uses go-github

The repo migueleliasweb/go-github-mock provides a way to mock responses. Check the repo for more details.

Integration Tests

You can run integration tests from the test directory. See the integration tests README.

Versioning

In general, go-github follows semver as closely as we can for tagging releases of the package. For self-contained libraries, the application of semantic versioning is relatively straightforward and generally understood. But because go-github is a client library for the GitHub API, which itself changes behavior, and because we are typically pretty aggressive about implementing preview features of the GitHub API, we’ve adopted the following versioning policy:

  • We increment the major version with any incompatible change to non-preview functionality, including changes to the exported Go API surface or behavior of the API.
  • We increment the minor version with any backwards-compatible changes to functionality, as well as any changes to preview functionality in the GitHub API. GitHub makes no guarantee about the stability of preview functionality, so neither do we consider it a stable part of the go-github API.
  • We increment the patch version with any backwards-compatible bug fixes.

Preview functionality may take the form of entire methods or simply additional data returned from an otherwise non-preview method. Refer to the GitHub API documentation for details on preview functionality.

Calendar Versioning

As of 2022-11-28, GitHub has announced that they are starting to version their v3 API based on “calendar-versioning”.

In practice, our goal is to make per-method version overrides (at least in the core library) rare and temporary.

Our understanding of the GitHub docs is that they will be revving the entire API to each new date-based version, even if only a few methods have breaking changes. Other methods will accept the new version with their existing functionality. So when a new date-based version of the GitHub API is released, we (the repo maintainers) plan to:

  • update each method that had breaking changes, overriding their per-method API version header. This may happen in one or multiple commits and PRs, and is all done in the main branch.

  • once all of the methods with breaking changes have been updated, have a final commit that bumps the default API version, and remove all of the per-method overrides. That would now get a major version bump when the next go-github release is made.

Articles

  • coming soon...