List branches or pull requests for a commit (preview)

We're releasing a couple of REST endpoints that enable you to retrieve additional information from an existing commit.

To access the new endpoints you must provide a custom media type in the Accept header:

application/vnd.github.groot-preview+json

The first endpoint allows you to get the list of branches where the given commit is the HEAD:

GET /repos/:owner/:repo/commits/:commit_sha/branches-where-head

The second one enables you to get a list of pull requests associated with the commit:

GET /repos/:owner/:repo/commits/:commit_sha/pulls

During the preview period, we may change aspects of these APIs based on developer feedback. If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice.

If you have any questions or feedback, please let us know!

Webhook IP addresses are changing

On April 9th, GitHub will begin sending webhooks from the 140.82.112.0/20 range of IP addresses in addition to the older 192.30.252.0/22 range.

We use a large pool of IP's to reach our customers, and we are adding further netblocks to help serve webhooks more reliably. If you have rules in place that only allow GitHub webhooks from our trusted addresses, you will need to update them.

This block of IPs has been in the /meta API endpoint since May 2018, but we wanted to announce this update in case you missed it.

Please contact us if you have any questions.

New response code for notifications marked as "read" in bulk

You can use the Mark notifications as read endpoint to mark all notifcations as "read." Similarly, you can use the Mark repository notifications as read endpoint to mark all notifications as "read" for a specific repository.

Sometimes, GitHub would time out and return an error when there were too many unread notifications to process in a single request. We've changed both endpoints to trigger a background job that will mark the notifications as "read" asynchronously. If the operation is too expensive for a single request, the endpoint returns a 202 status code with the following response:

{
  "message": "Unread notifications couldn't be marked in a single request. Notifications are being marked as read in the background."
}

After analyzing recent request data and we expect very few requests to trigger a background job. Most requests should return a 205 status code as usual. If you do receive a 202 status code, it will take a short amount of time for all notifications to be marked as "read" in the background job. There is currently no way to check if the job has completed. Instead, we recommend checking the number of unread notifications in separate requests using one of these endpoints:

GET https://api.github.com/notifications?all=false

or

GET https://api.github.com/repos/:owner/:repo/notifications?all=false

Preview enable and disable Pages API endpoints

We're releasing a new Pages API preview that allows you to enable and disable GitHub Pages from the REST v3 API. These add to our existing Pages APIs which allow you to access & update Pages configuration as well as access & create new builds.

To access the enable API or disable API during the preview period, you must provide a custom media type in the Accept header:

   application/vnd.github.switcheroo-preview+json

During the preview period, we may change aspects of these APIs based on developer feedback. If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice.

If you have any questions or feedback, please let us know!

Preview the new Draft Pull Requests API

We're releasing new GraphQL mutations and fields that allow you to handle draft pull requests. We're also showing the draft boolean in REST API responses. When this boolean is true, the pull request is in a draft state, and cannot be merged. For more information about draft pull requests, see "About pull requests" in the GitHub Help documentation.

[Updated 03-22-19] You can also create draft pull requests using a new draft field in the Create a pull request endpoint.

Changes

• REST API pull request responses include draft boolean
• CreatePullRequestInput includes draft boolean
• markPullRequestReadyForReview mutation
• PullRequest object includes draft field

To access these new API endpoints during the preview period, you must provide a custom media type in the Accept header:

application/vnd.github.shadow-cat-preview+json

During the preview period, we may change aspects of these API endpoints based on developer feedback. If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice.

If you have any questions or feedback, please let us know!

Removing the strict validation preview

As part of our plans for stricter validation in our REST API, we introduced a preview header to test out the changes before the rollout. Stricter validation has been postponed and beginning January 31, 2019, we will no longer support this header:

application/vnd.github.speedy-preview+json

We still believe that stricter validation would have a positive impact on our REST API overall and are looking for alternative ways to introduce it. Stay tuned for future updates.

If you have any questions, please reach out!

"GitHub Services" Feature Deprecation: What to Expect

As we have mentioned in previous posts, the "GitHub Services" feature will be deprecated this Thursday, January 31st, 2019. Here is what you can expect regarding "GitHub Services" going forward:

• GitHub will cut off all service hook deliveries. There will be no exceptions or extensions. If you still have service hooks configured for your repositories, we highly suggest migrating them to webhooks or GitHub Apps. Please see our "Replacing GitHub Services" guide for more information on how to do that.
• The github/github-services repository will be archived and no more contributions to the services will be accepted.
• You will no longer be able to modify service hook configurations through the GitHub settings UI or the repository hooks API. This change will affect the following endpoints for service hooks only:
  • PATCH /repos/:owner/:repo/hooks/:hook_id
  • POST /repos/:owner/:repo/hooks/:hook_id/tests
  • POST /repos/:owner/:repo/hooks/:hook_id/pings

• You will still be able to view and remove service hooks through the GitHub settings UI and API until April 1st, 2019. After that date, we will be removing all service hook records.
• Updated 01-30-19: Email service hooks have been migrated to a new repository notifications feature. Management of those notifications can be found in the repository settings UI only. There are no necessary actions to be taken to enable this new feature, and there should be no interruption of service for email deliveries. See "About email notifications for pushes to your repository" in the GitHub Help documentation to learn how to configure commit email notifications. Email notifications for pushes to your repository will be available in GitHub Enterprise Server 2.17 and higher.

Please contact us if you have any questions!

Creating Content Attachments Limited to 6 Hours

In an effort to provide a predictable user experience, we are going to begin limiting the creation of content attachments to 6 hours from when the content reference URL was added.

If an application tries to create a content attachment for a content reference URL older than 6 hours, a response with HTTP status code 422 will be returned.

Please contact us if you have any questions!

Preview the new Interactions API

We're releasing new REST API v3 endpoints that allow you to manage repository and organization interaction limits.

New endpoints

• Get interaction restrictions for a repository
• Set interaction restrictions for a repository
• Remove interaction restrictions for a repository
• Get interaction restrictions for an organization
• Set interaction restrictions for an organization
• Remove interaction restrictions for an organization

To access these new API endpoints during the preview period, you must provide a custom media type in the Accept header:

application/vnd.github.sombra-preview+json

During the preview period, we may change aspects of these API endpoints based on developer feedback. If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice.

If you have any questions or feedback, please let us know!

Content Attachments API Public Beta

Developers share a lot of links on GitHub. Nearly one-third of comments on issues and pull requests include a link. Hidden behind each of those links is important context that can inform the conversation. Today we’re excited to announce that you can curate and showcase content to help drive those conversations with the Content Attachments API, which is now in public beta.

GitHub Apps now have the ability to listen for links in issues and pull requests and attach content to those links:

Setting up content attachments

Step 1. Create a GitHub App.

Register the domain that your app would like to create content attachments for (errors.ai in this case). Make sure to select Read & write access: Make sure to select the Content reference event:

Step 2. Install your newly created GitHub App on a repository.

API interaction flow

1. Someone posts a link in an issue or pull request on a repository where your app is installed.

2. Your app will receive a content_reference event with action created. The contents of the content_reference and installation hash are important.

   {
     "action": "created",
     "content_reference": {
       "id": 1512,
       "node_id": "MDE2OkNvbnRlbnRSZWZlcmVuY2UxNTEy",
       "reference": "https://errors.ai/my-project/A-1234"
     },
     "repository": {...},
     "sender": {...},
     "installation": {
       "id": 492164,
       "node_id": "MDIzOkludGVncmF0aW9uSW5zdGFsbGF0aW9uNDkyMTY0"
     }
   }
   

3. Using the content_reference id you can now create a content attachment using the API by supplying a title and body in the API call. You'll also need the installation id to authenticate as a GitHub App installation. You can use markdown in the body parameter.

   curl -X POST \
     https://api.github.com/content_references/1512/attachments \
     -H 'Accept: application/vnd.github.corsair-preview+json' \
     -H 'Authorization: Bearer $INSTALLATION_TOKEN' \
     -d '{
       "title": "[A-1234] IntegrityError in core/models.py",
       "body": "duplicate key violates unique constraint user_email_uniq\nDETAIL: Key (email)=(hubot@github.com) already exists..."
   }'
   

4. You'll see the new content attachment appear under the link in a pull request or issue comment on GitHub:

Getting started

Try out one of the apps already supporting content attachments or build your own:

• Remix our Glitch blueprint
• Further documentation

Questions

How many domains can an app register?

An app can register up to 5 domains, read more.

What kind of links are GitHub Apps notified of?

For an app to receive a content_reference event, the posted link must be "free standing", so it cannot be part of a markdown link.

If posted, this link will trigger the content_reference event:

https://example.com/test/url

However, this link will not:

[my favorite URL](https://example.com/test/url)

Also, remember, that for an app to receive the content_reference event, it needs to be installed on the repository and have the matching domain registered. So in the above case the app would need to have example.com registered as a content_reference in the app settings.

If you have any questions or feedback, please let us know!