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.
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.
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:
GET /repos/:owner/:repo/branches/:branch/protection/restrictions/apps
PUT /repos/:owner/:repo/branches/:branch/protection/restrictions/apps
POST /repos/:owner/:repo/branches/:branch/protection/restrictions/apps
DELETE /repos/:owner/:repo/branches/:branch/protection/restrictions/apps
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!