Improved Support for Submodules in the Repository Contents API

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.

Deprecating a Confusing Attribute in the Pull Request API

EDIT: As of January 2017, we have decided not to deprecate this field for REST API.

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.

User Agent now mandatory

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.

New Hookshot Changes

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 :)

Sortable Stars in Repository Starring API

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.

Hookshot Load balancer

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.

Some Hookshot Issues

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:

1. Remove the IP white list.
2. Fall back to HTTPS and Basic Auth to restrict pushes to authorized senders only.

We're currently working on solving this problem.

Upcoming Changes to GitHub Services

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 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.

User Agent mandatory from March 4th 2013

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.

New User scopes

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