Introducing the GraphQL Changelog

GitHub's GraphQL schema changes multiple times a day. We have some neat automation to automatically update our reference documentation whenever the schema is modified, but there wasn't an easy way to visualize the day-to-day additions and modifications to the schema.

We're now happy to announce the GraphQL Changelog. Every day, around 4pm PST, Hubot will automatically compose a post detailing the GraphQL additions made in the last day. We've also got an RSS feed of this changelog if you want to subscribe. To support this workflow, we're using the very awesome graphql-schema_comparator gem, which provides a diff between two schemas.

If you have any questions, feel free to contact us!

Breaking changes to projects API preview and webhook date format

As previously announced on September 1st, the format of the created_at and updated_at fields in the projects API preview and project webhook payloads have been changed to be consistent with the standard YYYY-MM-DDTHH:MM:SSZ ISO 8601 format used by all other APIs and webhooks.

Previously, project webhook payloads would include these fields as an integer number of seconds:

{
  "action": "created",
  "project_card": {
    "created_at": 1503590773,
    "updated_at": 1503590773
  }
}

And project APIs would include these fields with milliseconds that were always zero:

{
  "url": "https://api.github.com/projects/1002604",
  "id": 1002604,
  "created_at": "2017-08-24T15:56:15.000Z",
  "updated_at": "2017-08-24T15:56:15.000Z"
}

Starting today, these fields are returned as YYYY-MM-DDTHH:MM:SSZ formatted strings in all projects APIs and project, card, and column webhook payloads.

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

Additional endpoints available for GitHub Apps

We've begun an audit of the availability of REST API endpoints for GitHub Apps. Additional endpoints will be enabled in batches over the course of the next few months.

Recently enabled endpoints

The first batch of newly enabled endpoints, available now, include:

Additionally, the following endpoints are now available for user-to-server requests:

How can I try it?

To access this functionality, you’ll need to provide the following custom media type in the Accept header:

application/vnd.github.machine-man-preview+json

What about other endpoints?

Check back to the developer blog to stay updated when new batches are available. If you have specific requests or feedback, come chat with us in the Platform forum.

Weak cryptographic standards deprecation update

GitHub announced the deprecation, and eventual disablement, of our use of the below cryptographic standards in a prior post.

  • TLSv1/TLSv1.1 - This applies to all HTTPS connections, including web, API, and Git connections to https://github.com and https://api.github.com.
  • diffie-hellman-group1-sha1 - This applies to all SSH connections to github.com.
  • diffie-hellman-group14-sha1 - This applies to all SSH connections to github.com.

Since publication, we have enabled diffie-hellman-group-exchange-sha256, which will allow the majority of SSH clients to seamlessly transition away from the deprecated algorithms. As noted in the original announcement, we plan to disable TLSv1/TLSv1.1, diffie-hellman-group1-sha1, and diffie-hellman-group14-sha1 on February 1, 2018.

For full details on the deprecation update, please see our GitHub Engineering blog post.

As always, if you have any questions, please get in touch.

Changes to maximum webhook timeout period

We've recently rolled out a change that modifies the maximum length of time the GitHub Platform will wait for an external server to receive a webhook payload.

Previously, from the time we opened a connection to an external server, we provided a 30 second window for the server to acknowledge the request. After that, if the server did not respond, we terminated the connection and the payload was lost.

We've now lowered the timeout window response time to 10 seconds; this is documented in our Best Practices guide. This change has been in production for several weeks as we gauged the effect it would have on integrators.

This change has no effect for webhooks on GitHub Enterprise, which are still kept at a 30 second maximum response time.

If you have any questions or feedback about this, please get in touch with us!

Protected Branches API Becomes an Official Part of API v3

We're excited to announce that the Protected Branches API has graduated from preview mode. As of today, the Protected Branches API is an official part of the GitHub API v3—stable and suitable for production use.

Breaking changes

As announced in a previous blog post, you are now required to pass the required_pull_request_reviews object when calling the update branch protection endpoint. Passing this object was optional during the preview period.

Also as previously announced, you are no longer able to call the PATCH /repos/:owner/:repo/branches/:branch endpoint. Please make sure you are using PUT /repos/:owner/:repo/branches/:branch/protection instead.

Additionally, you must now be a repository administrator to list protected branches.

Preview media type no longer required

If you used the Protected Branches API during the preview period, you needed to provide a custom media type in the Accept header:

application/vnd.github.loki-preview+json

As of today, 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 to everyone who tried out the Protected Branches API during the preview period!

If you have any questions or feedback, please get in touch with us.

Breaking changes to projects API preview and webhook date format

The format of the created_at and updated_at fields in the projects API preview and project webhook payloads is being changed to be consistent with the standard YYYY-MM-DDTHH:MM:SSZ ISO 8601 format used by all other APIs and webhooks.

Previously project webhook payloads would include these fields as an integer number of seconds:

{
  "action": "created",
  "project_card": {
    "created_at": 1503590773,
    "updated_at": 1503590773
  }
}

And project APIs would include these fields with milliseconds that were always zero:

{
  "url": "https://api.github.com/projects/1002604",
  "id": 1002604,
  "created_at": "2017-08-24T15:56:15.000Z",
  "updated_at": "2017-08-24T15:56:15.000Z"
}

Starting on Monday October 2nd, 2017 these fields will be returned as YYYY-MM-DDTHH:MM:SSZ formatted strings in all projects APIs and project, card, and column webhook payloads.

You can opt-in to this change in the project APIs today by using the following Accept header that will enable the new format before it becomes the default:

application/vnd.github.inertia-preview.iso8601+json

We apologize for any inconvenience this causes you.

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

Preview the new Nested Teams APIs

We're releasing new endpoints and changes to existing endpoints to better help you administer your organization's nested teams.

New endpoints

Changes to existing API endpoints

  • The List team members and Get team membership endpoints will now include both direct and child team members.

  • The List team repositories and Check if a team manages a repository endpoints now include both direct and inherited repositories.

  • You can now create a team with a parent team by passing the parent_team_id parameter to the Create team endpoint.

  • You can now update a team's parent team by passing the parent_team_id parameter to the Edit team endpoint.

  • Deleting a nested team through the Delete team endpoint will delete the team and all its child teams. Note: this action is only available to organization admins.

  • Listing a repository's collaborators through the Lists collaborators will now include child team members.

  • Endpoints that return team hashes will now include the parent field representing the parent team. Additionally, the members_count and repositories_count will include all members and repositories according to the nested structure.

To access the Nested Teams APIs during the preview period, you must provide a custom media type in the Accept header:

application/vnd.github.hellcat-preview+json

During the preview period, we may change aspects of these API methods 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!

Repository Invitations API is now official

The Repository Invitations API is now part of the official GitHub API. You will no longer be able to directly add a user to a repository. Instead, the user will receive an invitation, which they can accept or decline via email, notification, or API endpoint.

For details on how to use the repository invitations endpoints, please refer to the API documentation.

If you have any questions or feedback, please get in touch with us.

Helium and GitHub partner to streamline connected hardware development

Mark Phillips is Helium's Director of Customer Success.

In the coming weeks, we're excited to make it easier for IoT developers to prototype and ship connected devices as part of our new partnership with GitHub, and the GitHub Developer Program.

This means two things for the GitHub community:

  1. You can look forward to us integrating several parts of the Helium platform and features with the GitHub API, so you'll have a smoother experience when building IoT hardware and sensors.

  2. Starting today, all GitHub Developer Program members can access discounts on Helium products, cloud services, and ongoing support to get started.

Why Helium and GitHub?

Hardware and IoT developers already use GitHub as a core part of their workflows. Arduino and Raspberry Pi are a couple of hardware platforms that use GitHub for their open source development and community building. Similarly, the Helium Team depends on GitHub for our growing suite of open source IoT development tools.

We firmly believe that Helium, and our combination of hardware and software, is the best way for developers to protoype and deploy connected, secure hardware products. Now we're going to make it even better by removing as much friction as possible for GitHub users who are building applications with a wireless component. Our partnership will make it easier for you to access IoT development services and move faster when you're prototyping.

Helium and GitHub integration roadmap

Our current integration roadmap currently has two components, and it will likely expand as we collect your feedback.

GitHub authentication for the Helium Dashboard

We'll deliver the ability to create accounts and log in to the Helium Dashboard using your existing GitHub account. We'll also make it possible to automatically mirror your GitHub Team structure within the Helium Dashboard.

git push to deploy device configurations updates over the air

Few platforms make it possible to deploy configuration or complete software updates over the air to connected sensors. We'll offer developers the ability to git push updates to a target repository that will then kick off an OTA deployment to devices deployed in the field.

Helium for GitHub Developer Program members

To help Developer Program members get started, we're offering all of these discounts on Helium products:

Just use code HELIUM-AND-GITHUB-4-IOT during checkout.

All current members of the GitHub Developer Program received an email with details about how to buy Helium products with these discounts. If you're not yet a member of the GitHub Developer Program, you can apply here.

We can't wait to see what you build with GitHub and Helium. If you have any questions about our partnership or products, find us in the Helium Community Slack, post a message on the Helium Developer Forum, or send me a note.

Recent Posts

Subscribe to the RSS feed