A GraphQL mutation is now available for reverting a merged pull request: revertPullRequest.
Like the revert action on the pull request page in the web, calling this API creates a new pull request that reverses the changes made by the merged pull request.
Learn more about reverting a pull request.
The actions and reusable workflows from private repositories can now be shared with other private repositories within the same organization, user account, or enterprise.
See managing the repository settings and managing the enterprise repository settings to allow access to workflows in other repositories.
We have also added the API support to configure Actions share policy. Refer to API support or API support for Enterprise for more details.
Learn more about Sharing actions and workflows from your private repository, Sharing actions and workflows with your organization, and Sharing Actions and workflows with your enterprise.
Today, we’re introducing calendar-based versioning for the REST API to give API integrators a smooth migration path and plenty of time to update their integrations when we need to make occasional breaking changes to the API.
You can learn more in today’s blog post and on the new “API Versions” page in our docs.
If you’re using the REST API, you don’t need to take any action right now. We’ll get in touch with plenty of notice before we drop support for any old versions.
Recently, GitHub added webhooks to our OpenAPI schema. Now, Webhook events and payloads in the GitHub documentation is built from the OpenAPI schema. The schema-generated documentation is more accurate and comprehensive and includes the payload structure for each event and action type.
Currently, the new webhook docs are available for the Free/Pro/Team and GitHub Enterprise Cloud plans. GitHub Enterprise Server and GitHub AE will get the new docs with the next version release.
Do you have ideas for improvement? Open a documentation issue to let us know.
As part of the ongoing initiative to deprecate legacy global IDs, you will begin to see deprecation warnings for GraphQL node queries using the legacy ID format.
The deprecation warnings will look like this:
{
"data": {
"node": {
"login": "ahoglund",
}
},
"extensions": {
"warnings": [
{
"type": "DEPRECATION",
"message": "The id MDQ6VXNlcjM0MDczMDM= is deprecated. Update your cache to use the next_global_id from the data payload.",
"data": {
"next_global_id": "U_kgDOADP9xw"
},
"link": "https://docs.github.com"
}
]
}
}This will not impact the data portion of the payload. We recommend using these deprecation warnings along with the X-Github-Next-Global-ID to begin migrating any of your caches that contain legacy IDs. More information on how to migrate can be found in our last update as well as in the GitHub documentation.
If you have any concerns about the rollout of this change impacting your usage of the GitHub GraphQL API, please contact us and include any relevant information, so that we can better assist you.
We recently released organization-level API support that enables administrators to programmatically manage their organization-owned codespaces at scale. Today we're announcing that these APIs are generally available.
With organization APIs providing a wide range of management operations, organizations can seamlessly integrate GitHub Codespaces into their existing workflows to automate and manage their development processes at scale.
Organization-level APIs are generally available to GitHub Team and Enterprise Cloud plans. Here is a link to our documentation to get started:
Organization administrators can now filter fine-grained personal access tokens (PATs) by their permissions in the organization settings UI. Both pending token requests and active tokens can be filtered by permission, such as issues_write and members_read.
After setting a filter, only tokens with that permission will be shown in the table.
To learn more about fine-grained PATs, see "Reviewing fine-grained personal access tokens" and "Managing requests for fine-grained personal access tokens".
You can now retrieve all your Dependabot alerts at the GitHub enterprise level via the REST API. This new API endpoint supplements the recently introduced Dependabot alerts REST API, Dependabot alerts org-level REST API, and Dependabot alerts webhook.
For more information, see Dependabot alerts in the REST API reference or learn more about Dependabot alerts in our documentation.
We've added GraphQL API support for creating a branch linked to an issue. Learn more about creating a branch for an issue in the UI in the documentation.
The GraphQL API supports:
linkedBranches field on the Issue ObjectYou can now retrieve all your Dependabot alerts at the GitHub organization level via the REST API. This new API endpoint supplements the recently introduced Dependabot alerts REST API and Dependabot alerts webhook.
This API is available on GitHub.com starting today and will also be available to GitHub Enterprise Server (GHES) users starting with version 3.8.
For more information, see Dependabot alerts in the REST API reference or learn more about Dependabot alerts in our documentation.
Today we're enabling fine-grained personal access tokens (PATs) in Public Beta for all user accounts on GitHub.com. This new type of token gives developers and resource owners more control and visibility around token access. Learn more about this new token type in today's blog post.
These new tokens offer many more permissions to choose from, must be scoped to a specific organization or account, and must expire. Organization owners will also find new tools to manage tokens that can access their organization, and can require approval of those tokens before they may be used.
You can try out the new token creation flow, and provide feedback in our community discussion.
For more information, see "Creating a fine-grained personal access token".
API users can now integrate with a new dependabot_alert webhook, which matches the naming and structure of the recently introduced Dependabot alerts REST API. You should use this webhook in place of the existing repository_vulnerability_alert.
Improvements with the new webhook include:
read permission.created, dismissed, reopened, fixed, or reintroduced. See below for descriptions:| Action | Action definition |
|---|---|
created |
github has opened the Dependabot alert |
dismissed |
GitHub user dismissed the alert with dismissed_reason and an optional dismissed_comment |
reopened |
GitHub user manually reopened the previously-dismissed alert |
fixed |
github detected the Dependabot alert is resolved |
reintroduced |
github reopened the previously-fixed alert |
The repository_vulnerability_alert webhook is being deprecated. In 2023, we plan to remove the existing repository_vulnerability_alert webhook, which is superseded by the dependabot_alert webhook. We will give integrators at least 3 months notice of this removal — keep an eye on the GitHub Changelog in 2023 for more information.
Learn more about the Dependabot alerts webhook in our documentation.
We recently released a set of organization-level APIs (in beta) to enable administrators to programmatically manage their organization-owned codespaces at scale. Today we're releasing support for additional organization-level APIs based on the feedback that you shared with us. With this release, we've added support for the following REST API commands:
Organization-level APIs are in beta for GitHub Team and Enterprise Cloud plans. Here are links to our documentation to get started:
If you have any feedback to help improve this experience, be sure to post it on our discussions forum.
Custom repository roles enable Enterprise organization administrators to define and assign least-privilege roles for their repositories, beyond the standard Read, Triage, Write, Maintain, and Admin roles.
Now, REST API endpoints to create and update custom repository roles are available in a public beta for GitHub Enterprise Cloud customers. These new endpoints build on the existing custom repository role APIs that allow assignment of those roles to a team or user. The endpoints accept PATs from organization admins, as well as calls from properly authorized OAuth and GitHub apps.
These REST APIs will be supported in GitHub Enterprise Server 3.8, after they reach general availability in GitHub Enterprise Cloud.
Find out more about programmatically creating custom repository roles.
We'd love to get your feedback through your account team, or in our community Discussions board topic.