![](\"http:\/\/github.com\/peter-murach\/github\/raw\/master\/icons\/github_api.png\")
][icon] [icon]: https:\/\/github.com\/peter-murach\/github\/raw\/master\/icons\/github_api.png<\/p>\n[][icon] [icon]: https:\/\/github.com\/peter-murach\/github\/raw\/master\/icons\/github_api.png<\/p>\n
![](\"http:\/\/badge.fury.io\/rb\/github_api.png\"){kind=icon}
![](\"http:\/\/secure.travis-ci.org\/peter-murach\/github.png?branch=master\")
![](\"http:\/\/gemnasium.com\/peter-murach\/github.png?travis\")
![](\"http:\/\/codeclimate.com\/github\/peter-murach\/github.png\")
![](\"http:\/\/coveralls.io\/repos\/peter-murach\/github\/badge.png?branch=master\"){kind=icon}
<\/p>\n
Website | Wiki | RDocs<\/p>\n
A Ruby client for the official GitHub API.<\/p>\n
Supports all the API methods. It\u2019s built in a modular way. You can either instantiate the whole API wrapper Github.new or use parts of it i.e. Github::Client::Repos.new if working solely with repositories is your main concern. Intuitive query methods allow you easily call API endpoints.<\/p>\n
Install the gem by running<\/p>\n
gem install github_api\n<\/code><\/pre>\nor put it in your Gemfile and run bundle install<\/code><\/p>\ngem \"github_api\"\n<\/code><\/pre>\nContents<\/h2>\n1 Usage<\/h2>\n
To start using the gem, you can either perform requests directly on Github<\/code> namespace:<\/p>\nGithub.repos.list user: 'peter-murach'\n<\/code><\/pre>\nor create a new client instance like so<\/p>\n
github = Github.new\n<\/code><\/pre>\nand then call api methods, for instance, to list a given user repositories do<\/p>\n
github.repos.list user: 'peter-murach'\n<\/code><\/pre>\n1.1 API Navigation<\/h3>\n
The github_api<\/strong> closely mirrors the GitHub API hierarchy. For example, if you want to create a new file in a repository, look up the GitHub API spec. In there you will find contents sub category underneath the repository category. This would translate to the request:<\/p>\ngithub = Github.new\ngithub.repos.contents.create 'peter-murach', 'finite_machine', 'hello.rb',\n path: 'hello.rb',\n content: \"puts 'hello ruby'\"\n<\/code><\/pre>\nThe whole library reflects the same api navigation. Therefore, if you need to list releases for a repository do:<\/p>\n
github.repos.releases.list 'peter-murach', 'finite_machine'\n<\/code><\/pre>\nor to list a user\u2019s followers:<\/p>\n
github.users.followers.list 'peter-murach'\n<\/code><\/pre>\nThe code base has been extensively documented with examples of how to use each method. Please refer to the documentation under the Github::Client<\/code> class name.<\/p>\nAlternatively, you can find out which methods are supported by an api by calling actions<\/code> on a class or instance. For example, in order to find out available endpoints for Github::Client::Repos::Contents<\/code> api call actions<\/code> method:<\/p>\nGithub::Client::Repos::Contents.actions\n=> [:archive, :create, :delete, :find, :get, :readme, :update]\n<\/code><\/pre>\n1.2 Modularity<\/h3>\n
The code base is modular. This means that you can work specifically with a given part of GitHub API. If you want to only work with activity starring API do the following:<\/p>\n
starring = Github::Client::Activity::Starring.new\nstarring.star 'peter-murach', 'github'\n<\/code><\/pre>\nPlease refer to the documentation and look under Github::Client<\/code> to see all available classes.<\/p>\n1.3 Arguments<\/h3>\n
The github_api<\/strong> library allows for flexible argument parsing.<\/p>\nArguments can be passed directly inside the method called. The required<\/code> arguments are passed in first, followed by optional parameters supplied as hash options:<\/p>\nissues = Github::Client::Issues.new\nissues.milestones.list 'peter-murach', 'github', state: 'open'\n<\/code><\/pre>\nIn the previous example, the order of arguments is important. However, each method also allows you to specify required<\/code> arguments using hash symbols and thus remove the need for ordering. Therefore, the same example could be rewritten like so:<\/p>\nissues = Github::Client::Issues.new\nissues.milestones.list user: 'peter-murach', repo: 'github', state: 'open'\n<\/code><\/pre>\nFurthermore, required<\/code> arguments can be passed during instance creation:<\/p>\nissues = Github::Client::Issues.new user: 'peter-murach', repo: 'github'\nissues.milestones.list state: 'open'\n<\/code><\/pre>\nSimilarly, the required<\/code> arguments for the request can be passed inside the current scope such as:<\/p>\nissues = Github::Client::Issues.new\nissues.milestones(user: 'peter-murach', repo: 'github').list state: 'open'\n<\/code><\/pre>\nBut why limit ourselves? You can mix and match arguments, for example:<\/p>\n
issues = Github::Client::Issues.new user: 'peter-murach'\nissues.milestones(repo: 'github').list\nissues.milestones(repo: 'tty').list\n<\/code><\/pre>\nYou can also use a bit of syntactic sugar whereby \u201cusername\/repository\u201d can be passed as well:<\/p>\n
issues = Github::Client::Issues.new\nissues.milestones('peter-murach\/github').list\nissues.milestones.list 'peter-murach\/github'\n<\/code><\/pre>\nFinally, use the with<\/code> scope to clearly denote your requests<\/p>\nissues = Github::Client::Issues.new\nissues.milestones.with(user: 'peter-murach', repo: 'github').list\n<\/code><\/pre>\nPlease consult the method documentation or GitHub specification to see which arguments are required and what are the option parameters.<\/p>\n
1.4 Response Querying<\/h3>\n
The response is of type Github::ResponseWrapper<\/code> and allows traversing all the json response attributes like method calls. In addition, if the response returns more than one resource, these will be automatically yielded to the provided block one by one.<\/p>\nFor example, when request is issued to list all the branches on a given repository, each branch will be yielded one by one:<\/p>\n
repos = Github::Client::Repos.new\nrepos.branches user: 'peter-murach', repo: 'github' do |branch|\n puts branch.name\nend\n<\/code><\/pre>\n1.4.1 Response Body<\/h4>\n
The ResponseWrapper<\/code> allows you to call json attributes directly as method calls. there is no magic here, all calls are delegated to the response body. Therefore, you can directly inspect request body by calling body<\/code> method on the ResponseWrapper<\/code> like so:<\/p>\nresponse = repos.branches user: 'peter-murach', repo: 'github'\nresponse.body # => Array of branches\n<\/code><\/pre>\n1.4.2 Response Headers<\/h4>\n
Each response comes packaged with methods allowing for inspection of HTTP start line and headers. For example, to check for rate limits and status codes do:<\/p>\n
response = Github::Client::Repos.branches 'peter-murach', 'github'\nresponse.headers.ratelimit_limit # \"5000\"\nresponse.headers.ratelimit_remaining # \"4999\"\nresponse.headers.status # \"200\"\nresponse.headers.content_type # \"application\/json; charset=utf-8\"\nresponse.headers.etag # \"\\\"2c5dfc54b3fe498779ef3a9ada9a0af9\\\"\"\nresponse.headers.cache_control # \"public, max-age=60, s-maxage=60\"\n<\/code><\/pre>\n1.4.3 Response Success<\/h4>\n
If you want to verify if the response was success, namely, that the 200<\/code> code was returned call the success?<\/code> like so:<\/p>\nresponse = Github::Client::Repos.branches 'peter-murach', 'github'\nresponse.success? # => true\n<\/code><\/pre>\n1.5 Request Headers<\/h3>\n
It is possible to specify additional header information which will be added to the final request.<\/p>\n
For example, to set etag<\/code> and X-Poll_Interval<\/code> headers, use the :headers<\/code> hash key inside the :options<\/code> hash like in the following:<\/p>\nevents = Github::Client::Activity::Events.new\nevents.public headers: {\n 'X-Poll-Interval': 60,\n 'ETag': \"a18c3bded88eb5dbb5c849a489412bf3\"\n }\n<\/code><\/pre>\n1.5.1 Media Types<\/h4>\n
In order to set custom media types for a request use the accept header. By using the :accept<\/code> key you can determine media type like in the example:<\/p>\nissues = Github::Client::Issues.new\nissues.get 'peter-murach', 'github', 108, accept: 'application\/vnd.github.raw'\n<\/code><\/pre>\n2 Configuration<\/h2>\n
The github_api<\/strong> provides ability to specify global configuration options. These options will be available to all api calls.<\/p>\n2.1 Basic<\/h3>\n
The configuration options can be set by using the configure<\/code> helper<\/p>\nGithub.configure do |c|\n c.basic_auth = \"login:password\"\n c.adapter = :typheous\n c.user = 'peter-murach'\n c.repo = 'finite_machine'\nend\n<\/code><\/pre>\nAlternatively, you can configure the settings by passing a block to an instance like:<\/p>\n
Github.new do |c|\n c.endpoint = 'https:\/\/github.company.com\/api\/v3'\n c.site = 'https:\/\/github.company.com'\nend\n<\/code><\/pre>\nor simply by passing hash of options to an instance like so<\/p>\n
github = Github.new basic_auth: 'login:password',\n adapter: :typheous,\n user: 'peter-murach',\n repo: 'finite_machine'\n<\/code><\/pre>\nThe following is the full list of available configuration options:<\/p>\n
adapter # Http client used for performing requests. Default :net_http\nauto_pagination # Automatically traverse requests page links. Default false\nbasic_auth # Basic authentication in form login:password.\nclient_id # Oauth client id.\nclient_secret # Oauth client secret.\nconnection_options # Hash of connection options.\nendpoint # Enterprise API endpoint. Default: 'https:\/\/api.github.com'\noauth_token # Oauth authorization token.\norg # Global organization used in requests if none provided\nper_page # Number of items per page. Max of 100. Default 30.\nrepo # Global repository used in requests in none provided\nsite # enterprise API web endpoint\nssl # SSL settings in hash form.\nuser # Global user used for requests if none provided\nuser_agent # Custom user agent name. Default 'Github API Ruby Gem'\n<\/code><\/pre>\n2.2 Advanced<\/h3>\n
The github_api<\/strong> will use the default middleware stack which is exposed by calling stack<\/code> on a client instance. However, this stack can be freely modified with methods such as insert<\/code>, insert_after<\/code>, delete<\/code> and swap<\/code>. For instance, to add your CustomMiddleware<\/code> do:<\/p>\nGithub.configure do |c|\n c.stack.insert_after Github::Response::Helpers, CustomMiddleware\nend\n<\/code><\/pre>\nFurthermore, you can build your entire custom stack and specify other connection options such as adapter<\/code> by doing:<\/p>\nGithub.new do |c|\n c.adapter :excon\n\n c.stack do |builder|\n builder.use Github::Response::Helpers\n builder.use Github::Response::Jsonize\n end\nend\n<\/code><\/pre>\n2.3 SSL<\/h3>\n
By default requests over SSL are set to OpenSSL::SSL::VERIFY_PEER. However, you can turn off peer verification by<\/p>\n
github = Github.new ssl: { verify: false }\n<\/code><\/pre>\nIf your client fails to find CA certs, you can pass other SSL options to specify exactly how the information is sourced<\/p>\n
ssl: {\n client_cert: \"\/usr\/local\/www.example.com\/client_cert.pem\"\n client_key: \"\/user\/local\/www.example.com\/client_key.pem\"\n ca_file: \"example.com.cert\"\n ca_path: \"\/etc\/ssl\/\"\n}\n<\/code><\/pre>\nFor instance, download CA root certificates from Mozilla cacert and point ca_file at your certificate bundle location. This will allow the client to verify the github.com ssl certificate as authentic.<\/p>\n
2.4 Caching<\/h3>\n
Caching is supported through the faraday-http-cache<\/code> gem.<\/p>\nAdd the gem to your Gemfile:<\/p>\n
gem 'faraday-http-cache'\n<\/code><\/pre>\nYou can now configure cache parameters as follows<\/p>\n
Github.configure do |config|\n config.stack do |builder|\n builder.use Faraday::HttpCache, store: Rails.cache\n end\nend\n<\/code><\/pre>\nMore details on the available options can be found in the gem\u2019s own documentation: https:\/\/github.com\/plataformatec\/faraday-http-cache#faraday-http-cache<\/p>\n
3 Authentication<\/h2>\n3.1 Basic<\/h3>\n
To start making requests as authenticated user you can use your GitHub username and password like so<\/p>\n
Github.new basic_auth: 'login:password'\n<\/code><\/pre>\nThough this method is convenient you should strongly consider using OAuth<\/code> for improved security reasons.<\/p>\n3.2 Authorizations API<\/h3>\n3.2.1 For an User<\/h4>\n
To create an access token through the GitHub Authrizations API, you are required to pass your basic credentials and scopes you wish to have for the authentication token.<\/p>\n
github = Github.new basic_auth: 'login:password'\ngithub.oauth.create scopes: ['repo']\n<\/code><\/pre>\nYou can add more than one scope from the user<\/code>, public_repo<\/code>, repo<\/code>, gist<\/code> or leave the scopes parameter out, in which case, the default read-only access will be assumed (includes public user profile info, public repo info, and gists).<\/p>\n3.2.2 For an App<\/h4>\n
Furthermore, to create auth token for an application you need to pass :app<\/code> argument together with :client_id<\/code> and :client_secret<\/code> parameters.<\/p>\ngithub = Github.new basic_auth: 'login:password'\ngithub.oauth.app.create 'client-id', scopes: ['repo']\n<\/code><\/pre>\nIn order to revoke auth token(s) for an application you must use basic authentication with client_id<\/code> as login and client_secret<\/code> as password.<\/p>\ngithub = Github.new basic_auth: \"client_id:client_secret\"\ngithub.oauth.app.delete 'client-id'\n<\/code><\/pre>\nRevoke a specific app token.<\/p>\n
github.oauth.app.delete 'client-id', 'access-token'\n<\/code><\/pre>\n3.3 Scopes<\/h3>\n
You can check OAuth scopes you have by:<\/p>\n
github = Github.new oauth_token: 'token'\ngithub.scopes.list # => ['repo']\n<\/code><\/pre>\nTo list the scopes that the particular GitHub API action checks for do:<\/p>\n
repos = Github::Client::Repos.new\nresponse = repos.list user: 'peter-murach'\nresponse.headers.accepted_oauth_scopes # => ['delete_repo', 'repo', 'public_repo']\n<\/code><\/pre>\nTo understand what each scope means refer to documentation<\/p>\n
3.4 Application OAuth<\/h3>\n
In order to authenticate your app through OAuth2 on GitHub you need to<\/p>\n
You can use convenience methods to help you achieve this using GithubAPI<\/strong> gem:<\/p>\ngithub = Github.new client_id: '...', client_secret: '...'\ngithub.authorize_url redirect_uri: 'http:\/\/localhost', scope: 'repo'\n# => \"https:\/\/github.com\/login\/oauth\/authorize?scope=repo&response_type=code&client_id='...'&redirect_uri=http%3A%2F%2Flocalhost\"\n<\/code><\/pre>\nAfter you get your authorization code, call to receive your access_token<\/p>\n
token = github.get_token( authorization_code )\n<\/code><\/pre>\nOnce you have your access token, configure your github instance following instructions under Configuration.<\/p>\n
Note<\/strong>: If you are working locally (i.e. your app URL and callback URL are localhost), do not specify a :redirect_uri<\/code> otherwise you will get a redirect_uri_mismatch<\/code> error.<\/p>\n3.5 Two-Factor<\/h3>\n
In order to use Two-Factor authentication you need provide X-GitHub-OTP: required; :2fa-type<\/code> header.<\/p>\nYou can add headers during initialization:<\/p>\n
Github.new do |config|\n config.basic_auth = \"user:password\"\n config.connection_options = {headers: {\"X-GitHub-OTP\" => '2fa token'}}\nend\n<\/code><\/pre>\nor per request:<\/p>\n
github = Github.new basic_auth: 'login:password'\ngithub.oauth.create scopes: [\"public_repo\"],\n headers: {\"X-GitHub-OTP\" => \"2fa token\"}\n<\/code><\/pre>\n4 Pagination<\/h2>\n
Any request that returns multiple items will be paginated to 30 items by default. You can specify custom page<\/code> and per_page<\/code> query parameters to alter default behavior. For instance:<\/p>\nrepos = Github::Client::Repos.new\nresponse = repos.list user: 'wycats', per_page: 10, page: 5\n<\/code><\/pre>\nThen you can query the pagination information included in the link header by:<\/p>\n
response.links.first # Shows the URL of the first page of results.\nresponse.links.next # Shows the URL of the immediate next page of results.\nresponse.links.prev # Shows the URL of the immediate previous page of results.\nresponse.links.last # Shows the URL of the last page of results.\n<\/code><\/pre>\nIn order to iterate through the entire result set page by page, you can use convenience methods:<\/p>\n
response.each_page do |page|\n page.each do |repo|\n puts repo.name\n end\nend\n<\/code><\/pre>\nor use has_next_page?<\/code> and next_page<\/code> helper methods like in the following:<\/p>\nwhile response.has_next_page?\n ... process response ...\n res.next_page\nend\n<\/code><\/pre>\nOne can also navigate straight to the specific page by:<\/p>\n
res.count_pages # Number of pages\nres.page 5 # Requests given page if it exists, nil otherwise\nres.first_page # Get first page\nres.next_page # Get next page\nres.prev_page # Get previous page\nres.last_page # Get last page\n<\/code><\/pre>\n4.1 Auto pagination<\/h3>\n
You can retrieve all pages in one invocation by passing the auto_pagination<\/code> option like so:<\/p>\ngithub = Github.new auto_pagination: true\n<\/code><\/pre>\nDepending at what stage you pass the auto_pagination<\/code> it will affect all or only a single request. For example, in order to auto paginate all Repository API methods do:<\/p>\nGithub::Repos.new auto_pagination: true\n<\/code><\/pre>\nHowever, to only auto paginate results for a single request do:<\/p>\n
Github::Repos.new.list user: '...', auto_pagination: true\n<\/code><\/pre>\n5 Error Handling<\/h2>\n
The generic error class Github::Error::GithubError<\/code> will handle both the client (Github::Error::ClientError<\/code>) and service (Github::Error::ServiceError<\/code>) side errors. For instance in your code you can catch errors like<\/p>\nbegin\n # Do something with github_api gem\nrescue Github::Error::GithubError => e\n puts e.message\n\n if e.is_a? Github::Error::ServiceError\n # handle GitHub service errors such as 404\n elsif e.is_a? Github::Error::ClientError\n # handle client errors e.i. missing required parameter in request\n end\nend\n<\/code><\/pre>\n6 Examples<\/h2>\n6.1 Rails<\/h3>\n
A Rails controller that allows a user to authorize their GitHub account and then performs a request.<\/p>\n
class GithubController < ApplicationController\n\n def authorize\n address = github.authorize_url redirect_uri: 'http:\/\/...', scope: 'repo'\n redirect_to address\n end\n\n def callback\n authorization_code = params[:code]\n access_token = github.get_token authorization_code\n access_token.token # => returns token value\n end\n \n private\n \n def github\n @github ||= Github.new client_id: '...', client_secret: '...'\n end\nend\n<\/code><\/pre>\n6.2 Manipulating Files<\/h3>\n
In order to be able to create\/update\/remove files you need to use Contents API like so:<\/p>\n
contents = Github::Client::Repos::Contents.new oauth_token: '...'\n<\/code><\/pre>\nHaving instantiated the contents, to create a file do:<\/p>\n
contents.create 'username', 'repo_name', 'full_path_to\/file.ext',\n path: 'full_path_to\/file.ext',\n message: 'Your commit message',\n content: 'The contents of your file'\n<\/code><\/pre>\nContent is all Base64 encoded to\/from the API, and when you create a file it encodes it automatically for you.<\/p>\n
To update a file, first you need to find the file so you can get the SHA you\u2019re updating off of:<\/p>\n
file = contents.find path: 'full_path_to\/file.ext'\n<\/code><\/pre>\nThen update the file just like you do with creating:<\/p>\n
contents.update 'username', 'repo_name', 'full_path_to\/file.ext',\n path: 'full_path_to\/file.ext'\n message: 'Your commit message',\n content: 'The contens to be updated',\n sha: file.sha\n<\/code><\/pre>\nFinally to remove a file, find the file so you can get the SHA you\u2019re removing:<\/p>\n
file = contents.find path: 'full_path_to\/file.ext'\n<\/code><\/pre>\nThen delete the file like so:<\/p>\n
github.delete 'username', 'tome-of-knowledge', 'full_path_to\/file.ext',\n path: 'full_path_to\/file.ext',\n message: 'Your Commit Message',\n sha: file.sha\n<\/code><\/pre>\n7 Testing<\/h2>\n
The test suite is split into two groups, live<\/code> and mock<\/code>.<\/p>\nThe live<\/code> tests are the ones in features<\/code> folder and they simply exercise the GitHub API by making live requests and then being cached with VCR in directory named features\\cassettes<\/code>. For details on how to get set up, please navigate to the features<\/code> folder.<\/p>\nThe mock<\/code> tests are in the spec<\/code> directory and their primary concern is to test the gem internals without the hindrance of external calls.<\/p>\nDevelopment<\/h2>\n
Questions or problems? Please post them on the issue tracker. You can contribute changes by forking the project and submitting a pull request. You can ensure the tests are passing by running bundle<\/code> and rake<\/code>.<\/p>\nCopyright<\/h2>\n
Copyright \u00a9 2011-2014 Piotr Murach. See LICENSE.txt for further details.<\/p>\n","protected":false},"excerpt":{"rendered":"
[][icon] [icon]: https:\/\/github.com\/peter-murach\/github\/raw\/master\/icons\/github_api.png Website | Wiki | RDocs A Ruby client for the official GitHub API. Supports all the API methods. It\u2019s built in a modular way. You can either instantiate the whole API wrapper Github.new or use parts of it i.e. Github::Client::Repos.new if working solely with repositories is your main concern. Intuitive query methods […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-7637","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/7637","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/comments?post=7637"}],"version-history":[{"count":0,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/7637\/revisions"}],"wp:attachment":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/media?parent=7637"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/categories?post=7637"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/tags?post=7637"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}