-
-
-
-
-
-
-
We’ve added a new filter for listing members of an organization without
-two-factor authentication enabled:
-
-
-$ curl -H "Authorization: token [yours]" \
- https://api.github.com/orgs/octokit/members\?filter\=2fa_disabled
-
-
-
The new filter is available for owners of organizations with private
-repositories. Happy auditing and send us your feedback or questions.
-
-
-
-
-
-
-
-
-
-
Today we’re excited to announce a Deployments API. We ship a lot of
-software at GitHub: web, mobile, and native. For the last few years, we’ve been
-driving our deployments from our ChatOps tooling and we’ve learned a
-lot. The Deployments API is a generalization of the approach that we’ve been
-taking, and we’re really excited to see what our users and integrations start
-building around it.
-
-
Deployments are a new model in the GitHub ecosystem. We don’t have any UI
-components currently, and deployments are intended to be used exclusively by
-tooling. If you’re familiar with the Status API, you know that it allows
-various tools to report on the status of a commit (e.g., the progress of an
-attempt to perform a build at a particular commit). The Status API doesn’t
-perform the build; it just reports the results. Much like the Status API, we
-won’t be doing actual deployments for you. Instead, the API provides a way for
-you to track the status of your deployments. We’re hoping to provide
-consistency across the various type of release processes, regardless of the
-underlying steps involved with getting your code built or shipped to your
-servers.
-
-
Highlights
-
-
Automatic Merging
-
-
The system can auto-merge the default branch for the repository if the
-requested deployment ref is behind the default branch. On active projects it’s
-easy to fall behind, so let automation watch your back.
-
-
Commit Status Integration
-
-
By default, the system rejects deployment requests for repositories that have
-commit statuses but don’t have a green build for the deployment ref. This can
-be bypassed, but is useful in cases where continuous integration is being used.
-
-
Force Deployments
-
-
Sometimes the world crashes down on you, and you need to just get the code out
-the door. Forced deployments bypass any commit status checks or ahead/behind
-checks in the repository.
-
-
Deployment Statuses
-
-
Different deployment systems can update the status of a deployment to be
-pending, success, failure, or error. There’s also a field for linking
-to deployment output.
-
-
Events
-
-
Both Deployments and Deployment Statuses trigger events on GitHub. 3rd party
-integrations can listen for these events via webhooks and choose
-whether or not to actually deploy the repository that the event was created for.
-
-
Preview Period
-
-
We’re making this new API available today for developers to
-preview. We think developers and existing integrations are
-going to love it, but we want to get your feedback before we declare
-the Deployments API “final” and “unchangeable.” We expect the preview period to
-last for roughly 60-90 days.
-
-
As we discover opportunities to improve the API during the preview period, we
-may ship changes that break clients using the preview version of the API. We
-want to iterate quickly. To do so, we will announce any changes here (on the
-developer blog), but we will not provide any advance notice.
-
-
At the end of preview period, the Deployments API will become an official
-component of GitHub API v3. At that point, the new Deployments API will be
-stable and suitable for production use.
-
-
We hope you’ll take it for a spin and send us your feedback.
-
-

-
-
-
-
-
-
-
-
-
-
On April 15, 2014*, the GitHub API will start serving the v3 media type by default. The information below will help you determine whether your applications will be affected by this change. For affected applications, you’ll find tips below to help you smoothly navigate this change.
-
-
What’s changing?
-
-
A new default version
-
-
There are two versions of the GitHub API: beta and v3. Today, requests receive the beta version by default. On April 15*, requests will begin receiving the v3 version by default.
-
-
For the most part, beta and v3 are remarkably similar. There are just a few differences to keep in mind.
-
-
-
-
The version is one part of the media type. By default, the API provides the beta media type:
-
-
application/vnd.github.beta+json
-
-
-
On April 15*, requests will begin responding with the v3 media type by default:
-
-
application/vnd.github.v3+json
-
-
-
Who is affected?
-
-
Since 2012, we have encouraged developers to explicitly request a specific media type via the Accept header. If you are requesting either beta or v3 via the Accept header, then you are not affected by this change. The API will continue to respond with the requested media type.
-
-
If you are not requesting beta or v3 via the Accept header, then the API is currently responding with the beta media type. On April 15*, the API will begin responding with the v3 media type. If your application relies on functionality that differs between beta and v3, then you are affected by this change. You will need to take steps to prepare for the change.
-
-
What should you do?
-
-
If you are affected by this change, we recommend that you:
-
-
- - Update your applications to depend on the v3 functionality instead of the beta functionality. (If you use one of the popular client libraries, there’s a good chance that they’ve already done the work for you. In that case, you can just update to the latest version of that library.)
- - Request the v3 media type via the
Accept header.
-
-
-
If you cannot update your application to depend on the v3 functionality by April 15*, you can just request the beta media type via the Accept header. Doing so will insulate you from this change.
-
-
Cutover test on March 12, 2014
-
-
To help you understand the impact of this change before it becomes permanent, we will temporarily implement this change for a single day on March 12. From approximately 12:01am UTC to 11:59pm UTC on March 12, the API will respond with the v3 media type by default.
-
-
Follow @GitHubAPI to receive updates before and after the test.
-
-
-
-
Depending on the results of the cutover test, we may schedule additional tests before the final cutover on April 15. If so, we’ll to announce them in advance. Be sure to stay tuned to the blog or follow @GitHubAPI for updates.
-
-
If you have any questions, please get in touch. We’ll be happy to help.
-
-
-
-
-
-
-
-
-
-
The organization members and organization public members methods will soon return paginated results by default. Beginning
-today, these methods will paginate if you include page or per_page query
-parameters. Starting January 15th, 2014, these methods will always return paginated
-results.
-
-
As always, be sure and follow those Link headers to get
-subsequent results. If you have any questions or run into trouble, feel free to
-get in touch.
-
-
Happy paginating.
-
-
-
-
-
-
-
-
-
-
Hot on the heels of the Search API, the Releases API
-is now officially part of GitHub API v3. We now consider it stable for
-production use.
-
-
-
-
If you used the Releases API during the preview period, you needed to provide a custom media type in the Accept header:
-
-
application/vnd.github.manifold-preview+json
-
-
-
Now that the preview period has ended, you no longer need to pass this custom media type.
-
-
Instead, we recommend that you specify v3 as the version in the Accept header:
-
-
application/vnd.github.v3+json
-
-
-
Onward!
-
-
Thanks again to everyone that tried out the Releases API during the preview period.
-We got some great feedback, and we are already discussing additions to the API.
-
-
We can’t wait to see what you ship!
-
-
-
-
-
-
-
-
-
-
We’re excited to announce that the new Search API has graduated from preview mode.
-As of today, the Search API is an official part of GitHub API v3.
-As such, the Search API is now stable and suitable for production use.
-
-
-
-
If you used the Search API during the preview period, you needed to provide a custom media type in the Accept header:
-
-
application/vnd.github.preview+json
-
-
-
Now that the preview period has ended, you no longer need to pass this custom media type.
-
-
Instead, we recommend that you specify v3 as the version in the Accept header:
-
-
application/vnd.github.v3+json
-
-
-
Onward!
-
-
Thanks again to everyone that tried out the Search API during the preview period.
-
-
We can’t wait to see what you build!
-
-
-
-
-
-
-
-
-
-
As we prepare to end the preview period for the new search API,
-we’re making sure that it’s ready to handle the traffic from all the apps you’ll build on top of it.
-
-
New Validation Rule
-
-
In order to support the expected volume of requests, we’re applying a new validation rule to the Code Search API.
-Starting today, you will need to scope your code queries to a specific set of users, organizations, or repositories.
-
-
As usual, you specify the query via the q parameter.
-The value must include at least one user, organization, or repository.
-
-
For example, with this query, we’re searching for code from @twitter or @facebook that uses an MIT License:
-
-
MIT License user:twitter user:facebook
-
-
-
And here, we’re looking for uses of the underscore library in @mozilla’s BrowserQuest repository:
-
-
underscore language:js repo:mozilla/BrowserQuest
-
-
-
To perform these queries via the API, we would use the following URLs (respectively):
-
-
https://api.github.com/search/code?q=MIT+License+user%3Atwitter+user%3Afacebook
-
-https://api.github.com/search/code?q=underscore+language%3Ajs+repo%3Amozilla%2FBrowserQuest
-
-
-
All the various code search qualifiers are still available to you.
-A user, organization, or repository qualifier is now required.
-The other search qualifiers are still optional.
-
-
Other Search Types Not Affected
-
-
This new validation only applies to the Code Search API.
-It does not apply to the Search API for issues, users, or repositories.
-
-
This validation does not affect searches performed on github.com/search.
-
-
By ensuring that code queries are more targeted in nature, the API will be ready to meet the expected demand from all your apps.
-As we continue to tune the Search API, we hope to relax this validation in the future.
-There’s no ETA, but we’d like to relax it as soon as it’s feasible.
-
-
As always, if you have any questions or feedback, please get in touch.
-
-
-
-
-
-
-
-
-
-
We just added a new API method to list all
-the teams for the authenticated user across all organizations:
-
-
-$ curl -H "Authorization: token [yours]" https://api.github.com/user/teams
-
-[
- {
- "name": "Testing",
- "id": 396018,
- "slug": "testing",
- "permission": "pull",
- "url": "https://api.github.com/teams/396018",
- "members_url": "https://api.github.com/teams/396018/members{/member}",
- "repositories_url": "https://api.github.com/teams/396018/repos",
- "members_count": 1,
- "repos_count": 0,
- "organization": {
- "login": "dotfiles",
- "id": 1593590,
- "url": "https://api.github.com/orgs/dotfiles",
- "repos_url": "https://api.github.com/orgs/dotfiles/repos",
- "events_url": "https://api.github.com/orgs/dotfiles/events",
- "members_url": "https://api.github.com/orgs/dotfiles/members{/member}",
- "public_members_url": "https://api.github.com/orgs/dotfiles/public_members{/member}",
- "avatar_url": "https://0.gravatar.com/avatar/67d30facf213f62853c119fc2a05e246?d=https%3A%2F%2Fidenticons.github.com%2Fc90a68e6ab739e81c642f0e93f88c722.png"
- }
- },
- ...
-]
-
-
-
As always, if you have any questions or feedback, please drop us a line.
-
-
-
-
-
-
-
-
-
-
Starting today, we are returning granted scopes as part of the
-access_token response.
-For example, if you are making a POST with the application/json
-mime-type you’ll see an additional field for the granted scopes.
-
-
{
- "access_token":"e72e16c7e42f292c6912e7710c838347ae178b4a",
- "scope":"repo,gist",
- "token_type":"bearer"
-}
-
-
Right now, these scopes will be identical to what you requested, but we
-are moving towards a feature set that will allow GitHub users to edit
-their scopes, effectively granting your application less access than you
-originally requested. You should be aware of this possibility and adjust
-your application behavior accordingly.
-
-
Some things to watch out for and keep in mind:
-
-
- -
-
Most third party applications using GitHub OAuth to identify users have
-the best success in adoption by starting out with a request for the
-minimum access that the application can possibly get away with.
-Something like no scopes or just user:email is very sane.
-
- -
-
It is important to handle the error cases where a user chooses to
-grant you less access than you originally requested. Now that we are
-surfacing the granted scopes on the access_token response, applications
-can warn or otherwise communicate with their users that they will see
-reduced functionality or be unable to perform some actions.
-
- -
-
Applications can always send users back through the flow again to get
-additional permission, but don’t forget that users can always say no.
-
-
-
-
-
-
-
-
-
-
-
We owe a big “Thank You!” to everyone that has taken the time to try out the new Search API.
-We :heart: every one of you.
-Just as we hoped,
-the preview period has allowed us to see how you want to use the new API,
-and it has given us a chance to improve the API before finalizing it.
-
-
In order to incorporate everything that we’ve learned,
-we’re going to keep the Search API in preview mode for a little while longer.
-We have a few bugs to squash and a couple performance kinks to iron out.
-We’re hard at work on those improvements now,
-and we expect to have more news in the coming weeks.
-
-
In the mean time, keep the suggestions coming!
-
-
-
-
-
-
-
-
-
-
This summer we made it easier to release your software. Today, you can fully automate those releases via the
-Releases API Preview.
-
-
This API is a little different due to the binary assets. We use the Accept header for content negotiation when requesting
-a release asset. Pass a standard API media type to get the API representation:
-
-
-$ curl -i -H "Authorization: token TOKEN" \
- -H "Accept: application/vnd.github.manifold-preview" \
- "https://uploads.github.com/repos/hubot/singularity/releases/assets/123"
-
-HTTP/1.1 200 OK
-
-{
- "id": 123,
- ...
-}
-
-
-
Pass “application/octet-stream” to download the binary content.
-
-
-$ curl -i -H "Authorization: token TOKEN" \
- -H "Accept: application/octet-stream" \
- "https://uploads.github.com/repos/hubot/singularity/releases/assets/123"
-
-HTTP/1.1 302 Found
-
-
-
Uploads are handled by a single request to a companion “uploads.github.com” service.
-
-
-$ curl -H "Authorization: token TOKEN" \
- -H "Accept: application/vnd.github.manifold-preview" \
- -H "Content-Type: application/zip" \
- --data-binary @build/mac/package.zip \
- "https://uploads.github.com/repos/hubot/singularity/releases/123/assets?name=1.0.0-mac.zip"
-
-
-
Preview mode
-
-
The new API is available as a preview. This gives developers a chance to provide feedback on the direction of
-the API before we freeze changes. We expect to lift the preview status in 30 days.
-
-
As with the Search API, we’ll take this opportunity to iterate quickly. Breaking changes will be announced
-on this developer blog without any advance warning. Once the preview period is over, we’ll consider the Releases API unchangeable.
-At that point, it will be stable and suitable for production use.
-
-
The preview media type is “application/vnd.github.manifold-preview”. Manifold is
-a member of the Avengers, with the ability to teleport through time and space. He’s the one in the middle holding the spear.
-
-

-
-
-
-
-
-
-
-
-
-
As announced earlier today, GitHub.com now supports two-factor
-authentication (2FA) for increased security. For users with this feature
-enabled, GitHub.com will prompt for a 2FA code in addition to a username and
-password during authentication. We’ve also rolled out some improvements to the
-API to ensure that 2FA requirements in the API are consistent with GitHub.com.
-
-
Authenticating with the API
-
-
For users without 2FA enabled, and for applications using the OAuth web
-flow for authentication, everything is
-business as usual. You’ll continue to authenticate with the API just as you
-always have. (That was easy.)
-
-
If you enable 2FA and use Basic Authentication to access the API, we’re
-providing multiple options to make the flow simple and easy.
-
-
Basic Authentication and 2FA
-
-
Personal Access Tokens
-
-
Personal access tokens provide the simplest option for using 2FA with Basic
-Authentication. You can create these tokens via the application settings page
-on GitHub.com, and you can revoke
-them at any time. For more information about authenticating to the API with
-personal access tokens, be sure to check out our help article on the
-topic.
-
-
Tightly-integrated 2FA
-
-
For developers wishing to integrate GitHub 2FA directly into their application,
-the API’s Basic Authentication now supports the ability to send the user’s 2FA
-code, in addition to the username and password.
-
-
We’re here to help
-
-
We think GitHub users are going to love the additional security provided by
-two-factor authentication. As always, if you have any questions or feedback,
-let us know. We’re here to help!
-
-
-
-
-
-
-
-
-
-
Today we’re shipping two improvements to the new Search API.
-
-
More Text Match Metadata
-
-
When searching for code, the API previously provided text match metadata (i.e., “highlights”) for file content.
-Now, you can also get this metadata for matches that occur within the file path.
-
-
For example, when searching for files that have “client” in their path, the results include this match for lib/octokit/client/commits.rb:
-
-
-{
- "name": "commits.rb",
- "path": "lib/octokit/client/commits.rb",
- "text_matches": [
- {
- "object_url": "https://api.github.com/repositories/417862/contents/lib/octokit/client/commits.rb?ref=8d487ab06ccef463aa9f5412a56f1a2f1fa4dc88",
- "object_type": "FileContent",
- "property": "path",
- "fragment": "lib/octokit/client/commits.rb",
- "matches": [
- {
- "text": "client",
- "indices": [ 12, 18 ]
- }
- ]
- }
- ]
- // ...
-}
-
-
-
Better Text Match Metadata
-
-
Before today, the API applied HTML entity encoding to all fragment data.
-For example, imagine your search returns an issue like rails/rails#11889:
-
-

-
-
The response would include a text_matches array with the following object:
-
-
-{
- "fragment": "undefined method `except' for #<Array:XXX>",
- // ...
-}
-
-
-
Inside the fragment value, we see HTML-encoded entities (e.g., <).
-Since we’re returning JSON (not HTML), API clients might not expect any HTML-encoded text.
-As of today, the API returns these fragments without this extraneous encoding.
-
-
-{
- "fragment": "undefined method `except' for #<Array:XXX>",
- // ...
-}
-
-
-
Preview Period
-
-
We’re about halfway through the preview period for the new Search API.
-We appreciate everyone that has provided feedback so far. Please keep it coming!
-
-
-
-
-
-
-
-
-
-
Today we’re excited to announce a brand new Search API. Whether you’re
-searching for code, repositories,
-issues, or users, all the query abilities of
-github.com are now available via the API as well.
-
-
Maybe you want to find popular Tetris implementations written in Assembly.
-We’ve got you covered.
-Or perhaps you’re looking for new gems that are using Octokit.rb.
-No problem.
-The possibilities are endless.
-
-
Highlights
-
-
On github.com, we enjoy the context provided by code snippets and highlights in
-search results.
-
-

-
-
We want API consumers to have access to that information as well. So, API
-requests can opt to receive those
-text fragments in the response. Each fragment is accompanied by
-numeric offsets identifying the exact location of each matching search term.
-
-
Preview period
-
-
We’re making this new API available today for developers to
-preview. We think developers are going to love it, but we want
-to get your feedback before we declare the Search API “final” and
-“unchangeable.” We expect the preview period to last for roughly 60 days.
-
-
As we discover opportunities to improve this new API during the preview period,
-we may ship changes that break clients using the preview version of the API. We
-want to iterate quickly. To do so, we will announce any changes here (on the
-developer blog), but we will not provide any advance notice.
-
-
At the end of preview period, the Search API will become an official component
-of GitHub API v3. At that point, the new Search API will be stable and suitable
-for production use.
-
-
What about the old search API?
-
-
The legacy search API is still available. Many existing clients
-depend on it, and it is not changing in any way. While the new API offers much
-more functionality, the legacy search endpoints remain an official part of
-GitHub API v3.
-
-
Take it for a spin
-
-
We hope you’ll kick the tires and send us your feedback. Happy
-searching finding!
-
-
-
-
-
-
-
-
-
-
Have you ever wondered when your rate limit will reset back to its maximum value?
-That information is now available in the new X-RateLimit-Reset response header.
-
-
-$ curl -I https://api.github.com/orgs/octokit
-
-HTTP/1.1 200 OK
-Status: 200 OK
-X-RateLimit-Limit: 60
-X-RateLimit-Remaining: 42
-X-RateLimit-Reset: 1372700873
-...
-
-
-
The X-RateLimit-Reset header provides a Unix UTC timestamp, letting you know the exact time that your fresh new rate limit kicks in.
-
-
The reset timestamp is also available as part of the /rate_limit resource.
-
-
-$ curl https://api.github.com/rate_limit
-
-{
- "rate": {
- "limit": 60,
- "remaining": 42,
- "reset": 1372700873
- }
-}
-
-
-
For more information on rate limits, be sure to check out the docs.
-
-
If you have any questions or feedback, please drop us a line.
-
-
-
-
-
-
-
-
-
-
Today we’re releasing a new Feeds API, an easy way to list all the Atom
-resources available to the authenticated user.
-
-
-
-curl -u defunkt https://api.github.com/feeds
-
-{
- "timeline_url": "https://github.com/timeline",
- "user_url": "https://github.com/{user}",
- "current_user_public_url": "https://github.com/defunkt",
- "current_user_url": "https://github.com/defunkt.private?token=abc123",
- "current_user_actor_url": "https://github.com/defunkt.private.actor?token=abc123",
- "current_user_organization_url": "https://github.com/organizations/{org}/defunkt.private.atom?token=abc123",
- "_links": {
- "timeline": {
- "href": "https://github.com/timeline",
- "type": "application/atom+xml"
- },
- "user": {
- "href": "https://github.com/{user}",
- "type": "application/atom+xml"
- },
- "current_user_public": {
- "href": "https://github.com/defunkt",
- "type": "application/atom+xml"
- },
- "current_user": {
- "href": "https://github.com/defunkt.private?token=abc123",
- "type": "application/atom+xml"
- },
- "current_user_actor": {
- "href": "https://github.com/defunkt.private.actor?token=abc123",
- "type": "application/atom+xml"
- },
- "current_user_organization": {
- "href": "https://github.com/organizations/{org}/defunkt.private.atom?token=abc123",
- "type": "application/atom+xml"
- }
- }
-}
-
-
-
-
If you have any questions or feedback, please drop us a line.
-
-
-
-
-
-
-
-
-
-
-
-
Today we’re happy to open our Repository Statistics API to everyone. We’re using
-repository statistics to power our graphs,
-but we can’t wait to see what others can do with this information.
-
-
Starting today, these resources are available to you:
-
-
-
-
Enjoy!
-
-
-
-
-
-
-
-
-
When you view a repository with a submodule on github.com, you get useful links and information for the submodule.
-
-

-
-
Today we’re making that data available in the Repository Contents API.
-
-
-curl https://api.github.com/repos/jquery/jquery/contents/test/qunit
-
-{
- "name": "qunit",
- "path": "test/qunit",
- "type": "submodule",
- "submodule_git_url": "git://github.com/jquery/qunit.git",
- "sha": "6ca3721222109997540bd6d9ccd396902e0ad2f9",
- "size": 0,
- "url": "https://api.github.com/repos/jquery/jquery/contents/test/qunit?ref=master",
- "git_url": "https://api.github.com/repos/jquery/qunit/git/trees/6ca3721222109997540bd6d9ccd396902e0ad2f9",
- "html_url": "https://github.com/jquery/qunit/tree/6ca3721222109997540bd6d9ccd396902e0ad2f9",
- "_links": {
- "self": "https://api.github.com/repos/jquery/jquery/contents/test/qunit?ref=master",
- "git": "https://api.github.com/repos/jquery/qunit/git/trees/6ca3721222109997540bd6d9ccd396902e0ad2f9",
- "html": "https://github.com/jquery/qunit/tree/6ca3721222109997540bd6d9ccd396902e0ad2f9"
- }
-}
-
-
-
If you have any questions or feedback, please drop us a line at
-support@github.com.
-
-
-
-
-
-
-
-
-
-
-
-
When you get the details for a Pull Request from the API, the
-response provides everything there is to
-know about that Pull Request. In addition to the useful information provided in
-the API response, the JSON also includes the merge_commit_sha attribute. This
-attribute is a frequent source of misunderstanding, and we aim to remove the
-confusion.
-
-
To help current API consumers, we’ve documented the
-attribute for improved understanding.
-
-
To protect future API consumers from this confusion, we have
-deprecated the merge_commit_sha attribute, and we will
-remove it in the next major version of the API.
-
-
As always, if you have any questions or feedback, please drop us a line at
-support@github.com.
-
-
-
-
-
-
-
-
-
After an almost six week grace period, we’re now enforcing the User Agent
-header for all API requests. Most HTTP libraries (including cURL)
-set this header by default. If you’re experiencing an increase in 403
-responses, be sure and check your code.
-
-
If you have any questions or feedback, please drop us a line at
-support@github.com.
-
-
-
-
-
-
-
-
-
We are experimenting with changes to the “Hookshot” backend that powers service
-hooks. There were some significant networking changes with the new cluster,
-so there are some new IP whitelist rules for hooks:
-
-
- - 204.232.175.64/27
- - 192.30.252.0/22
-
-
-
These are in CIDR notation. They represent a significant range of GitHub
-addresses, meaning this should be the last IP change for a while. Once this
-cluster is activated and we shut the other cluster down, we will be removing
-the other entries.
-
-
We are currently testing the new backend with all repositories in the GitHub
-organization only, and expect to start testing it with user data next week.
-
-
This also means we should be able to start accepting GitHub Services pull
-requests very soon :)
-
-
-
-
-
-
-
-
-
As we announced on the GitHub blog, Stars now support sorting. The
-Repository Starring API now supports two new parameters when listing
-Stars: sort and direction.
-
-
-curl https://api.github.com/users/defunkt/starred?sort=created&direction=asc
-
-
-
Enjoy.
-
-
-
-
-
-
-
-
-
-
We had an issue with the Hookshot load balancer this morning, causing the
-majority of hooks to flow to a single node only. This lead to massive queue
-times. While fixing this, we’re putting the old Services backend in use.
-
-
This means the old IPs are back in use. Use this Help guide
-if you already removed them from your firewall.
-
-
-
-
-
-
-
-
-
We turned Hookshot (our new GitHub Services backend) on yesterday. Things have
-been pretty smooth, with one issue: Hooks going to other EC2 nodes come from
-the private IP addresses of our nodes in the 10...* range.
-
-
If your web hook servers are on EC2 and are missing hooks from GitHub due to
-an IP restriction, we recommend the following:
-
-
- - Remove the IP white list.
- - Fall back to HTTPS and Basic Auth to restrict pushes to authorized senders only.
-
-
-
We’re currently working on solving this problem. Hit up support@github.com
-if you have any questions.
-
-
-
-
-
-
-
-
-
We are finishing up a new GitHub Services backend, dubbed “Hookshot”, to
-increase the speed and reliability of our delivered payloads. We are doing
-what we can to make this a seamless transition for everyone. However, there
-are a few notable changes.
-
-
- -
-
There is a new Meta API endpoint
-listing the current public IPs that hooks originate from.
-
- -
-
We’re removing the AMQP service from GitHub. It hasn’t worked in quite some
-time, and the code it uses doesn’t work in our background workers.
-
- -
-
We’re also instituting a new guideline to improve the reliability and
-maintainability of services in the future. As of today, all new services must
-accept an unmodified payload over HTTP. Any service that does not will be
-rejected. To see an example of an acceptable service, check out Code Climate.
-Notice their service simply accepts HTTP POST from GitHub unmodified. For an
-example of a service that won’t be accepted after today, check out Campfire. It
-uses other Ruby gems and contains custom logic to transform the GitHub payload
-to Campfire messages. Existing hooks will keep working (don’t worry 37signals, we
-:heart: Campfire).
-
-
-
-
We’re making these changes because we want to focus on the reliability of the
-core Services backend for everyone. Maintaining custom logic and libraries for
-over 100 services is taking too much of this focus away.
-
-
-
-
-
-
-
-
-
-
Following on from our previous post
-about requiring requests to include a valid User Agent header
-we will soon be changing our API servers to return HTTP 403
-to any clients not providing a valid User Agent header.
-
-
We will be making this change on Monday, March 4th 2013.
-
-
Setting this helps us identify requests from you, and get in touch with people who are using
-the API in a way which causes disruption to GitHub. Most HTTP libraries and tools like cURL
-already provide a valid header for you, and allow you to customize it, so this will not require
-many of our users to make any changes whatsoever.
-
-
If you have any questions or feedback, please drop us a line at
-support@github.com.
-
-
-
-
-
-
-
-
-
We’ve added a few new user scopes for 3rd party applications that want very
-specific user functionality. The user:email scope gives apps read-only access
-to a user’s private email addresses. The user:follow scope lets a user
-follow and unfollow other users.
-
-
This should help keep applications from requiring the user scope, which
-can be potentially dangerous.
-
-
We also added a read-only endpoint to get a user’s public SSH keys.
-
-
GET https://api.github.com/users/technoweenie/keys
-
-
-
-
-
-
-
-
-
-
-
-
-

-
-
Improvements continue to the Organizations Repository listing endpoint.
-Today we’re improving pagination so that it works as documented. Now
-you can expect Link headers to navigate through the results space,
-regardless of what you send in the type parameter.
-
-
The docs for Organization Repositories queries are still here:
-
-
-
-
EDIT: Link headers are our preferred navigation technique.
-
-
-
-
-
-
-
-
-
We’ve made a couple of changes today to the Organization repositories
-listing to bring it a bit closer to the functionality of the GitHub.com
-Organization repositories tab. We now let you retrieve repositories
-which are forks of another repository, as well as those repositories which
-are sources (not forks).
-
-
# Grab all fork Repositories for an Organization
-curl "https://api.github.com/orgs/:org/repos?type=forks"
-
-# Grab all source Repositories for an Organization
-curl "https://api.github.com/orgs/:org/repos?type=sources"
-
-
-
Check out the docs for sorting and filtering options:
-
-
-
-
-
-
-
-
-
-
-
The Authorizations API is an easy way to create an OAuth
-authorization using Basic Auth. Just POST your desired scopes and optional
-note and you get a token back:
-
-
- curl -u pengwynn -d '{"scopes": ["user", "gist"]}' \
- https://api.github.com/authorizations
-
-
-
This call creates a token for the authenticating user tied to a special “API”
-OAuth application.
-
-
We now support creating tokens for your own OAuth application by passing your
-twenty character client_id and forty character client_secret as found in
-the settings page for your OAuth application.
-
-
- curl -u pengwynn -d '{ \
- "scopes": ["user", "gist"], \
- "client_id": "abcdeabcdeabcdeabcdeabcde" \
- "client_secret": "abcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcde" \
- }' \ '
- https://api.github.com/authorizations
-
-
-
No more implementing the web flow just to get a token tied to your
-app’s rate limit.
-
-
-
-
-
-
-
-
-
-
-
-
We recently made it easy to initialize a repository when you create
-it via the API. One of the options you can pass when creating a
-repository is gitignore_template. This value is the name of one of the
-templates from the the public GitHub .gitignore repository.
-
-
The Gitignore Templates API makes it easy to list those templates:
-
-
curl https://api.github.com/gitignore/templates
-
-HTTP/1.1 200 OK
-
-[
- "Actionscript",
- "Android",
- "AppceleratorTitanium",
- "Autotools",
- "Bancha",
- "C",
- "C++",
- ...
-
-
-
If you’d like to view the source, you can also fetch a single template.
-
-
curl -H 'Accept: application/vnd.github.raw' \
- https://api.github.com/gitignore/templates/Objective-C
-
-HTTP/1.1 200 OK
-
-# Xcode
-.DS_Store
-build/
-*.pbxuser
-!default.pbxuser
-*.mode1v3
-!default.mode1v3
-*.mode2v3
-!default.mode2v3
-*.perspectivev3
-!default.perspectivev3
-*.xcworkspace
-!default.xcworkspace
-xcuserdata
-profile
-*.moved-aside
-DerivedData
-.idea/
-
-
-
-
-
-
-
-
-
-
-
We made a slight change to the way you fork a repository. By default, you
-can fork my repository through an HTTP POST to the repository’s fork resource.
-
-
$ curl -X POST https://api.github.com/repos/technoweenie/faraday/forks
-
-
-
This repository forks to your personal account. However, there are cases when
-you want to fork to one of your organizations instead. The previous method
-required a ?org query parameter:
-
-
$ curl -X POST /repos/technoweenie/faraday/forks?org=mycompany
-
-
-
Query parameters on POST requests are unusual in APIs, and definitely
-inconsistent with the rest of the GitHub API. You should be able to post a
-JSON body like every other POST endpoint. Now, you can! Only, now we’re
-calling the field organization.
-
-
$ curl /repos/technoweenie/faraday/forks?org=mycompany \
- -d '{"organization": "mycompany"}'
-
-
-
Don’t worry, we are committed to maintaining the legacy behavior until the next
-major change of the GitHub API.
-
-
-
-
-
-
-
-
-
-
-
Now that the dust has settled around Notifications and Stars,
-we’ve unleashed all that :sparkles: in a brand new API. You can now
-view and mark notifications as read.
-
-
Endpoint
-
-
The core notifications functionality is under the /notifications endpoint.
-You can look for unread notifications:
-
-
-$ curl https://api.github.com/notifications
-
-
-
You can filter these notifications to a single Repository:
-
-
-$ curl https://api.github.com/repos/technoweenie/faraday/notifications
-
-
-
You can mark them as read:
-
-
-# all notifications
-$ curl https://api.github.com/notifications \
- -X PUT -d '{"read": true}'
-
-# notifications for a single repository
-$ curl https://api.github.com/repos/technoweenie/faraday/notifications \
- -X PUT -d '{"read": true}'
-
-
-
You can also modify subscriptions for a Repository or a single thread.
-
-
-# subscription details for the thread (either an Issue or Commit)
-$ curl https://api.github.com/notifications/threads/1/subscription
-
-# subscription details for a whole Repository.
-$ curl https://api.github.com/repos/technoweenie/faraday/subscription
-
-
-
Polling
-
-
The Notifications API is optimized for polling by the last modified time:
-
-
-# Add authentication to your requests
-$ curl -I https://api.github.com/notifications
-HTTP/1.1 200 OK
-Last-Modified: Thu, 25 Oct 2012 15:16:27 GMT
-X-Poll-Interval: 60
-
-# Pass the Last-Modified header exactly
-$ curl -I https://api.github.com/notifications
- -H "If-Modified-Since: Thu, 25 Oct 2012 15:16:27 GMT"
-HTTP/1.1 304 Not Modified
-X-Poll-Interval: 60
-
-
-
You can read about the API details in depth in the Notifications documentation.
-
-
-
-
-
-
-
-
-
You can set the default branch for a repository to something other than ‘master’ from the GitHub repository admin screen:
-
-

-
-
Now, you can update this setting via the API. We’ve added a default_branch parameter to the Edit Repository method:
-
-
-curl -u pengwynn \
- -d '{"name": "octokit", "default_branch":"development"}' \
- https://api.github.com/repos/pengwynn/octokit
-
-
-
If you provide a branch name that hasn’t been pushed to GitHub, we’ll gracefully fall back to 'master' or the first branch.
-
-
-
-
-
-
-
-
-
-
Requesting the member list of an
-organization of which you are not a member now redirects to the public members
-list. Similarly, requests to
-membership check resources of
-an organization of which you are not a member are redirected to the equivalent
-public membership check.
-One exception to the latter case is that if you are checking about your own
-membership the request is not redirected. You are always allowed to know what
-organizations you belong to.
-
-
The changes where made to clarify the purpose of these various resources. The
-/orgs/:org/members resources are intended for use by members of the
-organization in question. The /orgs/:org/public_members resources are for
-acquiring information about the public membership of organizations. If you are
-not a member you are not allowed to see private membership information so you
-should be using the public membership resources.
-
-
If you have any questions or feedback, please drop us a line at
-support@github.com.
-
-
-
-
-
-
-
-
-
To ensure a high quality of service for all API consumers, we’ve reduced the
-default rate limit for unauthenticated requests. To enjoy the default rate
-limit of 5,000 requests per hour, you’ll need to
-authenticate via Basic Auth
-or OAuth. Unauthenticated requests will be limited to 60 per hour unless you
-include your OAuth client and
-secret.
-
-
We’ll soon require all requests to include a valid User Agent
-header. Setting a
-unique value for this header helps us identify requests and get in touch with
-developers who are abusing the API. Most HTTP libraries, wrapper libraries, and
-even cURL provide a valid header for you already and allow you to change it to
-something unique to your application.
-
-
If you have any questions or feedback, please drop us a line at
-support@github.com.
-
-
-
-
-
-
-
-
-
Today we’ve made it easier to add commits to a repository via the GitHub API.
-Until now, you could create a repository, but you would
-need to initialize it locally via your Git client before adding any commits via
-the API.
-
-
Now you can optionally init a repository when it’s created by sending true
-for the auto_init parameter:
-
-
-curl -i -u pengwynn \
- -d '{"name": "create-repo-test", "auto_init": true}' \
- https://api.github.com/user/repos
-
-
-
The resulting repository will have a README stub and an initial commit.
-
-

-
-
.gitignore templates
-
-
Along with this change, you can set up your .gitignore template by passing
-the basename of any template in the GitHub gitignore templates
-project.
-
-
-curl -i -u pengwynn \
- -d '{"name": "create-repo-test", "auto_init": true, \
- "gitignore_template": "Haskell"}' \
- https://api.github.com/user/repos
-
-
-
As the docs point out, the gitignore_template parameter
-is ignored if auto_init is not present and true.
-
-
If you have any questions or feedback, drop us a line at
-https://github.com/contact, support@github.com, or
-@GitHubAPI.
-
-
-
-
-
-
-
-
-
-
We recently changed the Watcher behavior on GitHub. What
-used to be known as “Watching” is now “Starring”. Starring is basically a way
-to bookmark interesting repositories. Watching is a way to indicate that you
-want to receive email or web notifications on a Repository.
-
-
This works well on GitHub.com, but poses a problem for the GitHub API. How do
-we change this in a way that developers can gracefully upgrade their
-applications? We’re currently looking at rolling out the changes in three
-phases over an extended period of time.
-
-
Current Status
-
-
The current Repository Starring methods look like this:
-
-
- -
-
/repos/:owner/:repo/watchers - A list of users starring the repository.
- -
-
/users/:user/watched - A list of repositories that a user has starred.
- -
-
/user/watched - A list of repositories the current user has starred.
-
-
-
Phase 1: Add Watchers as Subscriptions
-
-
This phase exposes Watchers as “Subscriptions”. This is to
-keep from clashing with the legacy endpoints. This phase will happen
-automatically and will not break your application until Phase 3 starts.
-(UPDATE: API v3 will continue to support this functionality indefinitely.)
-
-
- -
-
/repos/:owner/:repo/subscribers - A list of users watching the repository.
- -
-
/users/:user/subscriptions - A list of repositories that a user is watching.
- -
-
/user/subscriptions - A list of repositories the current user is watching.
-
-
-
We’ll also add a copy of the legacy Watchers API in the new endpoint:
-
-
- -
-
/repos/:owner/:repo/stargazers - A list of users starring the repository.
- -
-
/users/:user/starred - A list of repositories that a user has starred.
- -
-
/user/starred - A list of repositories the current user has starred.
-
-
-
This is in place now with the current media type for the API:
-
-
application/vnd.github.beta+json
-
-
-
If you care about your application not breaking, make sure all outgoing API
-requests pass that value for the “Accept” header. You should do this now. This
-can be verified by checking the X-GitHub-Media-Type header on all API
-responses.
-
-
# Accesses a user's starred repositories.
-curl https://api.github.com/user/watched \
- -H "Accept: application/vnd.github.beta+json"
-
-
-
-This Phase will be broken once Phase 3 starts. Phase 3 removes all support for
-the "beta" media type, and makes the "v3" media type the implicit default
-for API requests.
-
-
UPDATE - November 6, 2013
-
-
-
- API v3 will continue to officially support the functionality described in
- Phase 1 above. This functionality will remain intact for the lifetime of
- API v3.
-
-
- API v3 will not include Phases 2 and 3 (below). Those phases will
- likely be part of the next major version of the API. (We have not announced
- a timeline for the next major version of the API.)
-
-
-
-
Phase 2: Switch /watchers API Endpoint
-
-
The "watch" endpoints will now be a copy of the "subscription" endpoints. You
-will have to use /user/starred to get a user's starred repositories, not
-/user/watched.
-
-
This requires a new media type value:
-
-
application/vnd.github.v3+json
-
-
This is a breaking change from Phase 1. We will release this change in an
-experimental mode first, letting developers gracefully upgrade their
-applications by specifying the new media value for the Accept header.
-
-
-
-# Accesses a user's watched repositories.
-curl https://api.github.com/user/watched \
- -H "Accept: application/vnd.github.v3+json"
-
-
-
-
Phase 3: Remove /subscribers API Endpoint.
-
-
This phase involves disabling the subscription endpoints completely. At this
-point, you should be using the starring endpoints for starred repositories, and
-the watch endpoints for watched repositories. No date has been set yet, but we
-expect this to be 3-6 months after Phase 2 is in place. This should give
-developers enough time for a smooth upgrade path. If they use popular API
-wrappers, the work will likely mostly be done for them.
-
-
Keep on passing the "v3" media type in your application, until the API has
-another breaking change to make. If you can't make the deadline for Phase 3,
-just set the "beta" media type until we shut that down completely. It's likely
-that we will keep the old "beta" media type active for another month, like
-the last time we terminated
-old API functionality.
-
-
We look forward to assisting you through this transition. Hit us up at
-https://github.com/contact, support@github.com, or
-@GitHubAPI.
-
-
-
-
-
-