Multi-line comments

Now you can create comments across multiple lines of code in a pull request diff using REST API or GraphQL.

To create multi-line comments or see multi-line comments with the new supported fields when you fetch comment responses, you must provide a custom media type in the Accept header:

application/vnd.github.comfort-fade-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.

Team sychronization become an official part of REST API

The features that are a part of the team sychronization team-sync-preview are now available on GitHub.com. Going forward, the Team synchronization API endpoints will be available without a preview header.

Preview media type no longer needed

Now that the preview period has ended (first announced in June 2019), you no longer need to pass the team-sync-preview custom media type.

More check annotations are now shown on the "Files changed" tab

In May of 2018, we announced the Checks API, which added many new capabilities for running checks on code. One of those new capabilities were check annotations, which let apps annotate specific lines of code as part of a check run.

demo-screenshot-of-unchanged-files-with-check-annotations

Check annotations point directly to those lines where a test failure or a lint error occurred, and they empower users to fix any kind of errors or warnings quickly so they can move forward with their pull requests.

demo-screenshot-from-checks-api-blog-post

Today we're making check annotations even more powerful by bringing more of them to where you're already looking: the "Files changed" tab. Checks annotations created on lines or files that were not modified as part of a pull request will now be prominently displayed alongside the diff.

Internal testing has proven that surfacing unchanged files with check annotations has been especially beneficial to our workflows, because test failures can often happen on files that weren't modified as part of a pull request.

Click here to see it in action!

The best part? The API for creating check annotations has not changed. If you're already creating annotations on files or lines outside of the diff, then there's no need to modify any code to use this improvement.

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

Grant GitHub Apps push access to protected branches

The Protected Branches API now allows you to grant GitHub Apps push access to protected branches.

You can only grant GitHub Apps push access to a protected branch if they have been installed with the repository contents write permission.

The Protected Branches API now includes the following endpoints:

The existing endpoint to set branch protection now accepts app restrictions:

If you have any questions or feedback, please get in touch!

Create and use repository templates

Repository templates enable you to create a new repository using an existing one that is marked is_template. This only copies repository contents without copying the commit history.

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

application/vnd.github.baptiste-preview+json

The following new endpoint is available for you to generate a new repository from a template repository:

In addition, you can make your repository available as a template when you Create a repository for the authenticated user or Update a repository. You can also Get a repository a repository's information to see if the repository is available to use as a template (is_template key is true) or was generated from a template_repository. For more information, see the Repositories API.

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!

Connect GitHub teams and IdP groups

Team synchronization is available for organizations using GitHub Enterprise Cloud. For more information, see GitHub's products in the GitHub Help documentation.

The Team Synchronization API allows you to manage connections between GitHub teams and external identity provider (IdP) groups.

You can manage GitHub team members through your IdP with team synchronization. Team synchronization must be enabled to use the Team Synchronization API. For more information, see "Synchronizing teams between your identity provider and GitHub" in the GitHub Help documentation.

To access the new API, you will need to authorize your API token for use with your IdP (SSO) provider. You must also provide a custom media type in the Accept header:

application/vnd.github.team-sync-preview+json

The following endpoints in the Team Synchronization API are available for you to use:

  • GET /orgs/:org/team-sync/groups
  • GET /teams/:team_id/team-sync/group-mappings
  • PATCH /teams/:team_id/team-sync/group-mappings

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!

Enable or disable automated security fixes for a repository

Previously, you could only enable or disable automated security fixes from a repository's security alerts page. We understand that having to do this for a large amount of repositories is not an optimal user experience. We've heard your feedback and are pleased to announce that we have released a new set of endpoints to manage the automated security fixes setting for your repositories.

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

application/vnd.github.london-preview+json

The first endpoint allows you to enable the automated security fixes setting:

PUT /repos/:owner/:repo/automated-security-fixes

The second endpoint allows you to disable the automated security fixes setting:

DELETE /repos/:owner/:repo/automated-security-fixes

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!

Perform an "Update branch" on a pull request via the REST API

We are pleased to announce a new API for updating the branch on a pull request, the Update Branch API. Rather than having to manually click a button to update the HEAD of a pull request branch with the latest changes from the base branch, you can now do so with one REST API endpoint call.

Why not just use the Merging API? Good question, and of course you can! The advantage of using this new API is that you only need the pull request number, not the base or head. This could potentially save a few roundtrips to the API and reduce the risk of getting rate limited.

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

application/vnd.github.lydian-preview+json

The update a pull request branch endpoint allows you to update the HEAD of the pull request branch for a pull request.

PUT /repos/:owner/:repo/pulls/:pull_number/update-branch

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.

Feedback welcomed!

Enable or disable vulnerability alerts for a repository

Previously, you could only enable or disable repository vulnerability alerts by checking a box in a repository's settings. We understand that having to do this for a large amount of repositories is not an optimal user experience. We've heard your feedback and are pleased to announce that we have released a new set of endpoints to manage the vulnerability alerts setting for your repositories.

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

application/vnd.github.dorian-preview+json

The first endpoint allows you to enable the vulnerability alerts setting:

PUT /repos/:owner/:repo/vulnerability-alerts

And the second endpoint allows you to disable the vulnerability alerts setting:

DELETE /repos/:owner/:repo/vulnerability-alerts

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!

[Updated 06-10-19] You can also check whether repository alerts are enabled or disabled for a repository using a new endpoint.

  GET /repos/:owner/:repo/vulnerability-alerts

New webhook events and actions

Our webhooks team is pleased to announce that we have added some long-awaited webhook events and actions to the list that we support and they will be available today. You'll automatically begin receiving these events if you have a webhook that is subscribed to wildcard events, otherwise you will be able to select the new events from the list in your webhook settings. As always, we continue to recommend listening for the actions in order to future-proof your code.

Here are the new events and actions that we've added:

Event Action Description
DeployKeyEvent created Triggered when a deploy key is added to a repository.
DeployKeyEvent deleted Triggered when a deploy key is removed from a repository.
IssueEvent locked Triggered when an issue is locked.
IssueEvent unlocked Triggered when an issue is unlocked.
MetaEvent deleted Triggered when the hook itself is deleted.
OrganizationEvent renamed Triggered when the organization is renamed.
OrganizationEvent deleted Triggered when the organization is deleted.
PullRequestEvent locked Triggered when a pull request is locked.
PullRequestEvent unlocked Triggered when a pull request is unlocked.
ReleaseEvent created Triggered when a release is created.
ReleaseEvent edited Triggered when a release is edited.
ReleaseEvent deleted Triggered when a release is deleted.
ReleaseEvent prereleased Triggered when a release is prereleased.
ReleaseEvent unpublished Triggered when a release is unpublished.
RepositoryEvent edited Triggered when attributes on a repository (e.g. description, default branch, homepage) are changed.
RepositoryEvent renamed Triggered when a repository is renamed.
RepositoryEvent transferred Triggered when a repository is transferred to a new owner.
StarEvent created Triggered when a star is added to a repository.
StarEvent deleted Triggered when a star is removed from a repository.

Please visit our webhooks documentation to view all of the events and actions that we support, and to get more information on these new ones.

If you have any questions or feedback, please get in touch!