We've just released a new version of Octokit.js, our SDK for interacting with the GitHub API from your JavaScript or TypeScript code.
The new release adds support for 91 new APIs – right up to the brand new dependency submission API launched last week.
Best of all, it offers in-editor code hints to make working with the API a breeze ✨
Custom repository roles are now GA for GitHub.com and Enterprise Server 3.5.
Organization admins can create custom repository roles available to all repositories in their organization. Roles can be configured from a set of 35 fine grained permissions covering discussions, issues, pull requests, repos, and security alerts. Once a role is created, repository admins can assign a custom role to any individual or team in their repository.
Custom repository roles can be managed in the Repository roles tab of your Organization settings:
Custom repository roles are also supported in the GitHub REST APIs. The Custom Roles API can be used to list all custom repository roles in an organization, and the existing APIs for granting repository access to individuals and teams support custom repository roles.
To get started with custom repository roles, read the docs.
Previously, the Get repository content REST API endpoint had a file size limit of 1 MB. That didn’t correspond to the Create or update file contents endpoint which has a file size limit of 100 MB. Now, both endpoints have a file size limit of 100 MB. However, requests for file contents larger than 1 MB must include the .raw custom media type in the Accept HTTP header, as shown here:
Accept: application/vnd.github.v3.raw
Read more about GitHub's REST API endpoints for repository contents.
From today the OAuth Device Authorization flow feature must be manually enabled for all OAuth and GitHub Apps. This change reduces the likelihood of Apps being used in phishing attacks against GitHub users by ensuring integrators are aware of the risks and make a conscious choice to support this form of authentication.
If you own or manage an OAuth App or GitHub App that makes use of the OAuth Device Authorization flow, you can enable it for your App via its settings page:
The OAuth Device Authorization flow API endpoints will respond with status code 400 to Apps that have not enabled this feature.
We recently announced a plan to sunset deprecated Teams API endpoints over the coming weeks. On March 1, we conducted the first scheduled brownout for 12 hours.
As we gathered metrics and consumer feedback on the brownout, we formed a new understanding of its impact on our consumers and parallel work. Consequently, we are deciding to pause the remainder of the sunset. Instead, we will sunset deprecated Teams API endpoints over a new timeline in the coming months as we invest more deeply into API versioning and our Octokit SDKs.
If you are using a deprecated endpoint under a /teams/:team_id path, we continue to encourage you to switch to the /organizations/:org_id/team/:team_id path. Please refer to the REST API documentation to learn more about supported Teams API endpoints.
On March 16 2022 the OAuth Device Authorization flow will become an "opt in" feature for all OAuth and GitHub Apps. This change reduces the likelihood of Apps being used in phishing attacks against GitHub users.
If you own or manage an OAuth App or GitHub App that makes use of the OAuth Device Authorization flow, you should enable it for your Apps via its settings page:
The OAuth Device Authorization flow API endpoints will respond with status code 400 to Apps that have not opted in to this feature.
Update on March 4, 2022: We have temporarily paused the sunset. Please read the official announcement for more information.
In early 2020, we moved the Teams API from a top-level path under /teams/:team_id to a scoped path under the organization that owns the team like /organizations/:org_id/team/:team_id and added support to make the API available under a named path like /orgs/:org/teams/:team_slug.
Over the next few weeks, we will be sunsetting the API endpoints under /teams/:team_id.
If you make a request to an affected endpoint during the brownouts, GitHub will respond with a client error.
GET /teams/:team_idPATCH /teams/:team_idDELETE /teams/:team_idGET /teams/:team_id/teamsGET /teams/:team_id/reposGET /teams/:team_id/repos/:owner/:repoPUT /teams/:team_id/repos/:owner/:repoDELETE /teams/:team_id/repos/:owner/:repoGET /teams/:team_id/projectsGET /teams/:team_id/projects/:project_idPUT /teams/:team_id/projects/:project_idDELETE /teams/:team_id/projects/:project_idGET /teams/:team_id/membersGET /teams/:team_id/members/:usernamePUT /teams/:team_id/members/:usernameDELETE /teams/:team_id/members/:usernameGET /teams/:team_id/memberships/:usernamePUT /teams/:team_id/memberships/:usernameDELETE /teams/:team_id/memberships/:usernameGET /teams/:team_id/invitationsThe easiest way to update your code is to switch to the /organizations/:org_id/team/:team_id path. If you're unsure of what org_id to use, you can GET the current team under /teams/:team_id and find the id field inside the organization hash in the response.
Please refer to the REST API documentation to learn more about supported Teams API endpoints.
This release adds support for viewing fixed alerts to the GraphQL API. This update also adds the ability to access and filter by state, as well as access unique numeric identifier.
The additions include these new fields to a RepositoryVulnerabilityAlert:
numberfixed_atfix_reasonstateAnd we're adding the ability to filter by state on the vulnerability alert object.
For more information, see Dependabot alerts in the GraphQL API reference.
In February 2020 we announced the deprecation of the general purpose "Delete reactions" REST API in favor of separate REST APIs for each place reactions can be applied. The old endpoint has been removed, which sets us up to scale and support the Reactions API better in the long run.
Learn more about the supported REST APIs for deleting reactions for issues, pull request comments, and more.
Users can now retrieve all their code scanning alerts at the GitHub organization level via the REST API. This new API endpoint supplements the existing repository level endpoint.
This API is available on GitHub.com starting today and will also be available to GitHub Enterprise Server users starting version 3.5.
Learn more about the code scanning REST API
Learn more about GitHub Advanced Security
The GitHub metadata endpoint now contains our SSH host keys.
(We'll continue offering host key fingerprints as well.)
{
// new entry
"ssh_keys": [
"ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl",
"ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=",
"ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ=="
],
// existing entry
"ssh_key_fingerprints": [
"SHA256_RSA": "nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8",
"SHA256_ECDSA": "p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM",
"SHA256_ED25519": "+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU"
],
// ... rest of payload
}These keys are in the OpenSSH known_hosts format for easy inclusion into existing known_hosts files.
This will make it easier to preconfigure systems which expect to connect via SSH.
For example, you can prime your CI runners with these keys before starting to fetch from GitHub.
The keys returned from the API include both SSH host keys that we're actively using, plus any that we're advertising via host key rotation for future use.
Currently, we're not offering any keys via rotation that aren't actively in use, but if we announce new host keys in the future, you can find them here as well during the rotation period.
See the meta API endpoint to learn more.
GitHub upgraded its OpenAPI description to the OpenAPI Specification (OAS) 3.1.
Upgrading to OAS 3.1 will enable us to add GitHub Webhooks to the description, simplify the description of nullable schemas, and reduce the description size by removing duplicate nullable reference schemas.
The GitHub OpenAPI description contains more than 600 operations exposed in our API. For visual exploration of the API, you can load the description as a Postman Collection. Programmatically, the description can be used to generate mock servers, test suites, and bindings for languages not supported by Octokit.
The description is provided under two formats. The bundled version is preferred for most use cases as it makes use of OpenAPI components for reuse and readability. For tooling that doesn't support inline references to components, we also provide a fully dereferenced version.
We are currently still publishing the 3.0 version of the description, which is now generally available in the latest release. The 3.1 version of the description is being published in parallel and can be found in the descriptions-next folder in the github/rest-api-description repository. More information about GitHub's OpenAPI description can also be found in our documentation.
We have released improvements to the code scanning API:
fixed_at timestamp to alerts. This is the first time that the alert was not detected in an analysis. You can use this data to better understand when code scanning alerts are being fixed.sort and direction on either created, updated or number. Use this to see the alerts that are most important to you first. For more information, see List code scanning alerts for a repository.Last-Modified header to the alerts and alert endpoint response. For more information, see Last-Modified in the Mozilla documentation.relatedLocations to the SARIF response when you request a code scanning analysis. The field may contain locations which are not the primary location of the alert. See an example in the SARIF spec and read about getting a code scanning analysis for a repository.help and tags data to the webhook response alert rule object. For more information, see Code scanning alert webhooks events and payloads.public_repo scope now have write access for code scanning endpoints on public repos, if the user has permission. This is a bug fix and is now inline with the documentation. For more information, see the Code scanning in the API reference.
It is now possible to list, add, and remove runner labels for Actions self-hosted runners via API. For more info on using the new APIs at a repository, organization, or enterprise level, see our docs (for repositories, organizations, and enterprises).
GitHub recently introduced the ability to set an expiration date when creating or regenerating a personal access token (PAT). For a PAT that is authorized to access an organization protected by SAML single sign-on (SSO), the expiration date of that PAT is now available via the GET /orgs/{org}/credential-authorizations API.
Organization administrators can use the following gh command to see the expiration dates of all PATs that are authorized to access their org by authenticating with a PAT that has the read:org scope:
gh api --paginate /orgs/:org/credential-authorizations --jq='.[] | [.authorized_credential_expires_at]'Learn more about authorizing a personal access token for use with SAML single sign-on.