| Apr | MAY | Jun |
| 13 | ||
| 2017 | 2018 | 2019 |
COLLECTED BY
Collection: University of Oklahoma Libraries
GraphQL API v4
REST API v3
Apps
Webhooks
Blog
Early Access
GitHub.com
Enterprise 2.13
Enterprise 2.12
Enterprise 2.11
Enterprise 2.10
nplasterer
Aspreviously announced, today we introduced a breaking change to the 
dismissed_review object in the Issue Events API and Issue Timeline API.
Going forward, the state will be a more informative string instead of an integer. Possible strings include commented, approved, or changes_requested. The API will no longer include the dismissal_commit_id field if a commit was not involved in the dismissal.
Please update your code accordingly, and let us know if you have any questions.
spinecone
●
benbalter
●
katmeister
When locking an issue via the issues API, you can now provide an optional reason that will be visible to anyone who views the issue. Valid lock reasons are "off-topic", "too heated", "resolved", and "spam". Providing a lock reason can help make it clearer to contributors why an issue was locked, and what kinds of behavior may result in issues being locked in the future. This change will be available on both the REST API as well as the GraphQL API.
To set a lock_reason during the preview period, you must provide a custom media type in the Accept header:
application/vnd.github.sailor-v-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.
To our GitHub Enterprise customers: issue lock reasons will be available in the next Enterprise release (2.13), but not in the current version or older versions.
active_lock_reason field that shows the lock_reason that was selected for an issue or pull request, if it is currently locked and a reason was provided.
●You can use the REST API to pass an optional lock_reason parameter to the Lock issueatPUT /repos/:owner/:repo/issues/:number/lock.
●
Issue and pull request event responses now contain a lock_reason field that shows the lock_reason that was selected for a locked event.
Lockable objects now contain an activeLockReason field that shows the lock_reason that was selected for an issue or pull request, if it is currently locked and a reason was provided.
●You can now lock issues and pull requests through the GraphQL API through the lockLockable mutation, which includes an optional lockReason parameter.
If you have any questions or feedback, please let us know!
nplasterer
On January 17, 2018, we will introduce a breaking change to the dismissed_review event in the Issue Events API.
Currently, the REST API v3 passes an integer for state, but with this change it will pass a more informative string. Possible strings include commented, approved, or changes_requested. Along with this breaking change, the API will no longer include the dismissal_commit_id field if a commit was not involved in the dismissal.
Please update your code accordingly, and let us know if you have any questions or feedback!
dewski
●
nickvanw
●
gjtorikian
To help with migrating from our REST API v3toGraphQL API v4, we're introducing a new preview period to include the GraphQL node ID in the response for the following REST API v3 resources:
●Deployments
●Gists
●Git Blobs
●Git Commits
●Git References
●Git Tags
●Issues
●Labels
●Milestones
●Organizations
●Projects
●Pull Requests
●Reactions
●Releases
●Repositories
●Statuses
●Teams
●Users
To access the API during the preview period, you must provide a custom media type in the Accept header:
application/vnd.github.jean-grey-preview+json
node_id:
{
"id": 79995,
"login": "dewski",
"node_id": "MDQ6VXNlcjc5OTk1"
}
{
node(id: "MDQ6VXNlcjc5OTk1") {
... on User {
databaseId
login
id
}
}
}
{
"data": {
"node": {
"databaseId": 79995,
"login": "dewski",
"id": "MDQ6VXNlcjc5OTk1"
}
}
}
node_id is only available to GitHub Enterprise customers on 2.12 (and future GHE versions when they are released).
If you have any questions or feedback, please let us know on the GitHub Platform Forum.
mbcampbell
Yesterday, we released GitHub Enterprise 2.12. This release includes a few updates relevant to the platform community including GitHub Apps, global webhooks, GitHub Enterprise version information in API responses, and new and improved documentation.
jmilas
As part of the name change from Integrations to GitHub Apps, we have deprecated the performed_via_integration key in favor of performed_via_github_app. The old key will no longer be returned starting on December 13. Please update your application to respond to the new key as soon as possible.
For related deprecations, please see our previous blog post.
benbalter
In March of 2015, we announced the License API preview to support open source license usage on GitHub.com.
Since then, we've improved the underlying license detection algorithm, added license support to additional endpoints, and made it easier to retrieve a repository's license text.
Today, we're making things official by ending the preview period, and we consider the response payload to be stable going forward. We've also exposed license metadata via the GraphQL API as a repository's licenseInfo property.
Going forward, endpoints that return license metadata will no longer require passing the preview media type. Instead, we recommend that you specify v3 as the version in the Accept header:
application/vnd.github.v3+json
application/vnd.github.drax-preview+json
seejohnrun
We're releasing a new endpoint that allows you to transfer a repository to another user or organization.
Accept header:
application/vnd.github.nightshade-preview+json
MikeMcQuaid
As part of the release of archiving repositories, we've made changes to expose this feature to developers.
Note that archived repositories are read-only to everyone (including repository owners). This includes anyone using the REST or GraphQL APIs to edit the repository, issues, pull requests, labels, milestones, projects, wiki, releases, commits, tags, branches, reactions, or comments. No one (including repository owners) can use the REST or GraphQL APIs to create new issues, pull requests, or comments on an archived repository.
To our GitHub Enterprise customers: archiving repositories will be available in the next Enterprise release (2.12), but not in the current version or older versions.
archived field that is trueorfalse depending on whether the repository was archived.
●You can use the REST API to archive repositories by passing the "archived": true parameter to the Edit endpointatPATCH /repos/:owner/:repo.
Repository, RepositoryInfo, and RepositoryInvitationRepository objects now contain an isArchived field that is trueorfalse depending on whether the repository was archived.
RepositoryEvent webhooks are now emitted when a repository is archivedorunarchived.
archived:true search filter.
Happy archiving! If you have any questions or feedback, please let us know!
jmilas
As part of the name change from Integrations to GitHub Apps, we previously announced breaking changes to certain webhook events, payloads, responses, and URL routing. We continued to support the original implementation with a deprecation date of November 22, 2017. As this date nears, we want to remind you to update your applications as soon as possible.
integration_installation and integration_installation_repositories event names will be removed in favor of installation and installation_repositories.
●The integration_id key in webhook payloads and API responses will be removed in favor of the app_id key.
https://github.com/integrations/super-ci/installations/new will no longer work. The correct format for that URL is https://github.com/apps/super-ci/installations/new.