# Technical Documentation: google/go-github

> ℹ️ **Provenance:** Multi-Tier Ingestion · [CodeWiki Reference](https://codewiki.google/github.com/google/go-github)

### Overview (`README.md`)

# go-github #

[](https://github.com/google/go-github/releases)
[](https://pkg.go.dev/github.com/google/go-github/v93/github)
[](https://github.com/google/go-github/actions/workflows/tests.yml)
[](https://codecov.io/gh/google/go-github)
[](https://groups.google.com/group/go-github)
[](https://bestpractices.coreinfrastructure.org/projects/796)

go-github is a Go client library for accessing the [GitHub API v3][].

go-github tracks [Go's version support policy][support-policy] supporting any
minor version of the latest two major releases of Go and the go directive in
go.mod reflects that.
We do our best not to break older versions of Go if we don't have to, but we
don't explicitly test older versions and as of Go 1.26 the go directive in
go.mod declares a hard required _minimum_ version of Go to use with this module
and this _must_ be greater than or equal to the go line of all dependencies so
go-github will require the N-1 major release of Go by default.

[support-policy]: https://golang.org/doc/devel/release.html#policy

## Development ##

If you're interested in using the [GraphQL API v4][], the recommended library is
[shurcooL/githubv4][].

## Installation ##

go-github is compatible with modern Go releases in module mode, with Go installed:

```bash
go get github.com/google/go-github/v93
```

will resolve and add the package to the current development module, along with its dependencies.

Alternatively the same can be achieved if you use import in a package:

```go
import "github.com/google/go-github/v93/github"
```

and run `go get` without parameters.

Finally, to use the top-of-trunk version of this repo, use the following command:

```bash
go get github.com/google/go-github/v93@master
```

To discover all the changes that have occurred since a prior release, you can
first clone the repo, then run (for example):

```bash
go run tools/gen-release-notes/main.go --tag v93.0.0
```

## Usage ##

```go
import "github.com/google/go-github/v93/github"
```

Construct a new GitHub client, then use the various services on the client to
access different parts of the GitHub API. For example:

```go
client, err := github.NewClient()
if err != nil {
	// Handle error.
}

// list all organizations for user "willnorris"
orgs, _, err := client.Organizations.List(context.Background(), "willnorris", nil)
```

Some API methods have optional parameters that can be passed. For example:

```go
client, err := github.NewClient()
if err != nil {
	// Handle error.
}

// list public repositories for org "github"
opt := &github.RepositoryListByOrgOptions{Type: "public"}
repos, _, err := client.Repositories.ListByOrg(context.Background(), "github", opt)
```

The services of a client divide the API into logical chunks and correspond to
the structure of the [GitHub API documentation](https://docs.github.com/en/rest).

NOTE: Using the [context](https://pkg.go.dev/context) package, one can easily
pass cancellation signals and deadlines to various services of the client for
handling a request. In case there is no context available, then `context.Background()`
can be used as a starting point.

For more sample code snippets, head over to the
[example](https://github.com/google/go-github/tree/master/example) directory.

### Authentication ###

Use the `github.WithAuthToken` options 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.

```go
client, err := github.NewClient(github.WithAuthToken("... your access token ..."))
if err != nil {
	// Handle error.
}
```

To support more advanced use cases; you can use the `github.WithTokenSource` option to provide a
`oauth2.TokenSource` that handles authentication for you.

Note that when using an authenticated Client, all calls made by the client to
will the client base and upload URL origins will include a token. Therefore,
authenticated clients should almost never be shared between different users.

#### As a GitHub App ####

GitHub Apps authentication can be provided by [jferrl/go-githubauth](https://github.com/jferrl/go-githubauth).

> **Note**: Most endpoints (ex. [`GET /rate_limit`]) require access token authentication
> while a few others (ex. [`GET /app/hook/deliveries`]) require [JWT] authentication.

[`GET /rate_limit`]: https://docs.github.com/en/rest/rate-limit#get-rate-limit-status-for-the-authenticated-user
[`GET /app/hook/deliveries`]: https://docs.github.com/en/rest/apps/webhooks#list-deliveries-for-an-app-webhook
[JWT]: https://docs.github.com/en/developers/apps/building-github-apps/authenticating-with-github-apps#authenticating-as-a-github-app

`go-githubauth` implements a set of functions that can create `oauth2.TokenSource` implementations.
The `oauth2.TokenSource` can be configured for the `github.Client` using the `github.WithTokenSource` option.

`NewApplicationTokenSource` accepts either the App's client ID (a `string`, which GitHub now recommends) or its legacy app ID (an `int64`).

Another example using `go-githubauth`:

```go
package main

import (
	"fmt"
	"os"
	"strconv"

	"github.com/google/go-github/v93/github"
	"github.com/jferrl/go-githubauth"
)

func main() {
	privateKey := []byte(os.Getenv("GITHUB_APP_PRIVATE_KEY"))
	clientID := os.Getenv("GITHUB_APP_CLIENT_ID")

	installationID, err := strconv.ParseInt(os.Getenv("GITHUB_APP_INSTALLATION_ID"), 10, 64)
	if err != nil {
		fmt.Println("Error parsing installation ID:", err)
		return
	}

	appTokenSource, err := githubauth.NewApplicationTokenSource(clientID, privateKey)
	if err != nil {
		fmt.Println("Error creating application token source:", err)
		return
	}

	installationTokenSource := githubauth.NewInstallationTokenSource(installationID, appTokenSource)

	client, err := github.NewClient(github.WithTokenSource(installationTokenSource))
	if err != nil {
		// Handle error.
	}

	// Use client...
}
```

_Note_: In order to interact with certain APIs, for example writing a file to a repo, one must generate an installation token
using the installation ID of the GitHub app and authenticate with the OAuth method mentioned above. See the examples.

### Rate Limiting ###

GitHub imposes rate limits on all API clients. The [primary rate limit](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api#about-primary-rate-limits)
is the limit to the number of REST API requests that a client can make within a
specific amount of time. This limit helps prevent abuse and denial-of-service
attacks, and ensures that the API remains available for all users. Some
endpoints, like the search endpoints, have more restrictive limits.
Unauthenticated clients may request public data but have a low rate limit,
while authenticated clients have rate limits based on the client
identity.

In addition to primary rate limits, GitHub enforces [secondary rate limits](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api#about-secondary-rate-limits)
in order to prevent abuse and keep the API available for all users.
Secondary rate limits generally limit the number of concurrent requests that a
client can make.

The client 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 the client `RateLimits` service to fetch the most
up-to-date rate limit data for the client.

To detect a primary API rate limit error, you can check if the error is a
`RateLimitError`.

```go
repos, _, err := client.Repositories.List(ctx, "", nil)
var rateErr *github.RateLimitError
if errors.As(err, &rateErr) {
	log.Printf("hit primary rate limit, used %v of %v\n", rateErr.Rate.Used, rateErr.Rate.Limit)
}
```

To detect an API secondary rate limit error, you can check if the error is an
`AbuseRateLimitError`.

```go
repos, _, err := client.Repositories.List(ctx, "", nil)
var rateErr *github.AbuseRateLimitError
if errors.As(err, &rateErr) {
	log.Printf("hit secondary rate limit, retry after %v\n", rateErr.RetryAfter)
}
```

If you hit the primary rate limit, you can use the `SleepUntilPrimaryRateLimitResetWhenRateLimited`
method to block until the rate limit is reset.

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

If you need to make a request even if the rate limit has been hit you can use
the `BypassRateLimitCheck` method to bypass the rate limit check and make the
request anyway.

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

For more advanced use cases, you can use [gofri/go-github-ratelimit](https://github.com/gofri/go-github-ratelimit)
which provides a middleware (`http.RoundTripper`) that handles both the primary
rate limit and secondary rate limit for the GitHub API. In this case you can
set the client `DisableRateLimitCheck` to `true` so the client doesn't track the rate limit usage.

If the client is an [OAuth app](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api#primary-rate-limit-for-oauth-apps)
you can use the apps higher rate limit to request public data by using the
`github.WithBasicAuth` option to configure the client to make calls as the
app instead of as the user.

### 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`:

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

### Conditional Requests ###

The GitHub REST API has good support for [conditional HTTP requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate)
via the `ETag` header which will help prevent you from burning through your
rate limit, as well as help speed up your application. `go-github` does not
handle conditional requests directly, but is instead designed to work with a
caching `http.Transport`.

Typically, an [RFC 9111](https://datatracker.ietf.org/doc/html/rfc9111)
compliant HTTP cache such as [bartventer/httpcache](https://github.com/bartventer/httpcache)
is recommended, ex:

```go
import (
	"github.com/bartventer/httpcache"
	_ "github.com/bartventer/httpcache/store/memcache" // Register the in-memory backend
)

client, err := github.NewClient(github.WithTransport(httpcache.NewTransport("memcache://")), github.WithAuthToken(os.Getenv("GITHUB_TOKEN")))
if err != nil {
	// Handle error.
}
```

Alternatively, the [bored-engineer/github-conditional-http-transport](https://github.com/bored-engineer/github-conditional-http-transport)
package relies on (undocumented) GitHub specific cache logic and is
recommended when making requests using short-lived credentials such as a
[GitHub App installation token](https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-as-a-github-app-installation).

### Creating and Updating Resources ###

Many resource and request structs use pointers for optional scalar fields. This
allows distinguishing between unset fields and those set to a zero-value.
Required fields such as `CreateRepositoryRequest.Name` use value types.
Use the `new` builtin to easily create these pointers for string,
bool, and int values. For example:

```go
// create a new private repository named "foo"
repo := github.CreateRepositoryRequest{
	Name:    "foo",
	Private: new(true),
}
client.Repositories.Create(ctx, "", repo)
```

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

### Pagination ###

All requests for resource collections (repos, pull requests, issues, etc.)
support pagination. Pagination options using page numbers are described in the
`github.ListOptions` struct and passed to the list methods directly or as an
embedded type of a more specific list options struct (for example
`github.PullRequestListOptions`). Pages information is available via the
`github.Response` struct.

```go
client, err := github.NewClient()
if err != nil {
	// Handle error.
}

opt := &github.RepositoryListByOrgOptions{
	ListOptions: github.ListOptions{PerPage: 10},
}
// get all pages of results
var allRepos []*github.Repository
for {
	repos, resp, err := client.Repositories.ListByOrg(ctx, "github", opt)
	if err != nil {
		return err
	}
	allRepos = append(allRepos, repos...)
	if resp.NextPage == 0 {
		break
	}
	opt.Page = resp.NextPage
}
```

Pagination options using string cursors are described in the `github.ListCursorOptions`
struct and passed to the list methods directly or as an
embedded type of a more specific list cursor options struct (for example
`github.ListGlobalSecurityAdvisoriesOptions`). Similarly, cursor and pages information
is available via the `github.Response` struct.

#### Iterators ####

Go v1.23 introduces the new `iter` package.

The new `github/gen-iterators.go` file auto-generates "*Iter" methods in `github/github-iterators.go`
for all methods that support page number iteration (using the `NextPage` field in each response)
or string cursor iteration (using the `After` field in each response).
To handle rate limiting issues, make sure to use a rate-limiting transport.
(See [Rate Limiting](/#rate-limiting) above for more details.)
To use these methods, simply create an iterator and then range over it, for example:

```go
client, err := github.NewClient()
if err != nil {
	// Handle error.
}
var allRepos []*github.Repository

// create an iterator and start looping through all the results
iter := client.Repositories.ListIter(ctx, "github", nil)
for repo, err := range iter {
	if err != nil {
		log.Fatal(err)
	}
	allRepos = append(allRepos, repo)
}
```

Alternatively, if you wish to use an external package, there is `enrichman/gh-iter`.
Its iterator will handle pagination for you, looping through all the available results.

```go
client, err := github.NewClient()
if err != nil {
	// Handle error.
}
var allRepos []*github.Repository

// create an iterator and start looping through all the results
repos := ghiter.NewFromFn1(client.Repositories.ListByOrg, "github")
for repo := range repos.All() {
	allRepos = append(allRepos, repo)
}
```

For complete usage of `enrichman/gh-iter`, see the full [package docs](https://github.com/enrichman/gh-iter).

#### Middleware ####

You can use [gofri/go-github-pagination](https://github.com/gofri/go-github-pagination) to handle
pagination for you. It supports both sync and async modes, as well as customizations.
By default, the middleware automatically paginates through all pages, aggregates results, and returns them as an array.
See `example/ratelimit/main.go` for usage.

### Webhooks ###

`go-github` provides structs for almost all [GitHub webhook events][] as well as functions to validate them and unmarshal JSON payloads from `http.Request` structs.

```go
func (s *GitHubEventMonitor) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	payload, err := github.ValidatePayload(r, s.webhookSecretKey)
	if err != nil { ... }
	event, err := github.ParseWebHook(github.WebHookType(r), payload)
	if err != nil { ... }
	switch event := event.(type) {
	case *github.CommitCommentEvent:
		processCommitCommentEvent(event)
	case *github.CreateEvent:
		processCreateEvent(event)
	...
	}
}
```

Furthermore, there are libraries like [cbrgm/githubevents][] that build upon the example above and provide functions to subscribe callbacks to specific events.

For complete usage of go-github, see the full [package docs][].

[GitHub API v3]: https://docs.github.com/en/rest
[personal access token]: https://github.com/blog/1509-personal-api-tokens
[package docs]: https://pkg.go.dev/github.com/google/go-github/v93/github
[GraphQL API v4]: https://developer.github.com/v4/
[shurcooL/githubv4]: https://github.com/shurcooL/githubv4
[GitHub webhook events]: https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads
[cbrgm/githubevents]: https://github.com/cbrgm/githubevents

### Testing code that uses `go-github` ###

The repo [migueleliasweb/go-github-mock](https://github.com/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](test/README.md).

## Contributing ##

I would like to cover the entire GitHub API and contributions are of course always welcome. The
calling pattern is pretty well established, so adding new methods is relatively
straightforward. See [`CONTRIBUTING.md`](CONTRIBUTING.md) for details.

## Versioning ##

In general, go-github follows [semver](https://semver.org/) 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](https://github.blog/developer-skills/github/to-infinity-and-beyond-enabling-the-future-of-githubs-rest-api-with-api-versioning/)
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.

### Version Compatibility Table ###

The following table identifies which version of the GitHub API is
supported by this (and past) versions of this repo (go-github).
Versions prior to 48.2.0 are not listed.

| go-github Version | GitHub v3 API Version |
| ----------------- | --------------------- |
| 93.0.0            | 2022-11-28            |
| ...               | 2022-11-28            |
| 48.2.0            | 2022-11-28            |

## License ##

This library is distributed under the BSD-style license found in the [LICENSE](./LICENSE)
file.

---

### Overview (`scrape/README.md`)

[](https://pkg.go.dev/github.com/google/go-github/scrape)

The scrape package provides an experimental client for accessing additional
GitHub data via screen scraping. It is designed to be a client of last resort
for data that cannot be retrieved via the REST or GraphQL APIs.

# What should be added here

**Add only what you need.** Whereas the main go-github library attempts to
implement the entire GitHub REST API, there is little point in trying to do that
here. Certainly, feel free to contribute patches to get data you actually
need, but I'd rather not try and provide exhaustive coverage of all GitHub data
here.

**Add only what can't be accessed elsewhere.** If the data can be retrieved
through the REST or GraphQL API, use the appropriate libraries for that.

**Prefer read-only access.** For now, I'm only focusing on reading data. It
might be that writing works fine as well, but it is of course much riskier.

# How to add methods

See [apps.go](apps.go) for examples of methods that access data. Basically,
fetch the contents of the page using `client.get`, and then use goquery to dig
into the markup on the page. Prefer selectors that grab semantic ID or class
names, as they are more likely to be stable.

---

### Overview (`test/README.md`)

go-github tests
===============

This directory contains additional test suites beyond the unit tests already in
[../github](../github). Whereas the unit tests run very quickly (since they
don't make any network calls) and are run by Travis on every commit, the tests
in this directory are only run manually.

The test packages are:

integration
-----------

This will exercise the entire go-github library (or at least as much as is
practical) against the live GitHub API. These tests will verify that the
library is properly coded against the actual behavior of the API, and will
(hopefully) fail upon any incompatible change in the API.

Because these tests are running using live data, there is a much higher
probability of false positives in test failures due to network issues, test
data having been changed, etc.

These tests send real network traffic to the GitHub API and will exhaust the
default unregistered rate limit (60 requests per hour) very quickly.
Additionally, in order to test the methods that modify data, a real OAuth token
will need to be present. While the tests will try to be well-behaved in terms
of what data they modify, it is **strongly** recommended that these tests only
be run using a dedicated test account.

Run tests using:

    GITHUB_AUTH_TOKEN=XXX go test -v -tags=integration ./integration

Some tests create repositories. By default, the new repositories will be owned
by the user identified by the OAuth token. Set the `GITHUB_OWNER='<GH_OWNER>'`
environment variable to specify a different owner, such as an organization.

Additionally there are a set of integration tests for the Authorizations API.
These tests require a GitHub user (username and password), and also that a
[GitHub Application](https://github.com/settings/applications/new) (with
attendant Client ID and Client Secret) be available. Then, to execute just the
Authorization tests:

    GITHUB_USERNAME='<GH_USERNAME>' GITHUB_PASSWORD='<GH_PASSWORD>' GITHUB_CLIENT_ID='<CLIENT_ID>' GITHUB_CLIENT_SECRET='<CLIENT_SECRET>' go test -v -tags=integration -run=Authorizations ./integration

If some or all of these environment variables are not available, certain of the
Authorization integration tests will be skipped.

---

--- METRICS ---
- Files Extracted: 3
- Estimated Token Budget: ~5894 tokens
- Canonical Reference: https://codewiki.google/github.com/google/go-github