To support better content moderation, you can now disable comments on individual gists in the UI as well as with the APIs. Once commenting is disabled, existing comments on the gist will be hidden and no new comments can be posted.
To learn more check out the documentation.
Questions or suggestions? Join the conversation in the community discussion.
As a GitHub Enterprise Cloud organization owner, you and your designated users can now use API insights to visualize REST API activity for your entire organization or specific apps and users. This new feature helps you understand the sources of your REST API activity and manage against your primary rate limits—giving you visibility into the timeframe, apps, and API endpoints involved.
The API insights feature is available only at the organization level. By default, only organization owners can access it. However, organization owners can grant access to non-owners by creating a custom role at the organization level, assigning the permission named View organization API insights to the custom role, and then assigning the custom role to an organization member or team. See the documentation for managing organization custom roles.
The API insights feature is available to all GitHub Enterprise Cloud organizations. To access it on your organization home page, select Insights near the top of the page, and then select REST API on the left side of the page.
Use the Period and Interval drop-downs to choose the range of time displayed in the chart and how granularly to display REST API requests on the chart. These drop-downs also set the time range for the “Total REST requests,” the “Primary-rate-limited requests,” and the Actors table below the chart.
The Actors table displays the GitHub Apps and users that made REST API requests in the current organization within the selected time period. Select a GitHub App to display its REST API activity and any primary rate-limiting. Select a user to display their personal REST API activity from personal access tokens (PATs) and OAuth apps acting on their behalf.
We welcome your feedback in the Enterprise community discussions.
Refer to the documentation for API insights for more details about understanding your organization’s REST API activity and investigating primary rate-limiting.
New REST API endpoints for code scanning allow you to request the generation of Copilot Autofix for code scanning alerts. These endpoints also provide the Autofix generation status, along with metadata and AI-generated descriptions for the fixes, and enable you to apply Autofix to a branch. This functionality can be particularly useful for addressing security vulnerabilities programmatically and for tracking the status of alerts with Copilot Autofixes in your system.
To generate Copilot Autofix, call the POST /repos/{owner}/{repo}/code-scanning/alerts/{number}/autofix endpoint.
Additionally, you can retrieve the Autofix and commit it by using the GET /repos/{owner}/{repo}/code-scanning/alerts/{number}/autofix endpoint followed by POST /repos/{owner}/{repo}/code-scanning/alerts/{number}/autofix/commits.
For more information, see: About Copilot Autofix for CodeQL code scanning. If you have feedback for Copilot Autofix for code scanning, please join the discussion here.
Announcement banner fields in GraphQL for enterprises and organizations are being replaced with a new announcementBanner object to simplify their access and better follow our standard styles. The new fields are available today, and the old fields will be removed on April 1, 2025.
The following fields are being removed from the enterprise and organization GraphQL objects:
announcementannouncementCreatedAtannouncementExpiresAtannouncementUserDismissibleThe new GraphQL structure for these fields is:
announcementBanner {
message
createdAt
expiresAt
isUserDismissible
}
Learn more about announcement banners for organizations on GitHub Enterprise Cloud.
Following our “Evolving GitHub Issues” announcement we’ve continued to improve the experience based on your feedback, including closing an issue as a duplicate, a REST API for sub-issues, and expanding the limits for both sub-issues and issue types.
These new features are all available in public preview for you to try. To gain access for your organization, please sign up here.
You can now close an issue as a duplicate of another issue, making it easier to manage your issues and provide more clarity on why they were closed.
When closing an issue, select Close as duplicate from the dropdown to search for and select the duplicate issue. You’ll then see an event in the timeline and note at the top making it clear why it was closed.
You can now use the REST API to view, add, remove, and reprioritize sub-issues, making it easier to automate your use of sub-issues. Check out the documentation to learn more.
You can now have up to 100 sub-issues per parent issue (up from 50), as well as up to 25 issue types in an organization (up from 10), making it easier to manage, classify, and break down work.
You can now view, add, and update issue types on GitHub Mobile.
You can use the has: and no: filters to search for sub-issues and issue types both from a project and the repository issues page, making it easier to find the exact set of issues you’re looking for and make updates.
Example filters include:
– no:type to find all issues that do not yet have a type
– no:parent-issue to find all issues without a parent issue
– has:sub-issue to find all issues that have sub-issues
On top of the many bug fixes we’ve shipped, we’ve also introduced the following improvements:
– If the sub-issue is from a different repository than the parent issue, you will now see the repository name in the sub-issues list.
– In GitHub markdown, pasting in a project link will now show the project name as well as more project details on hover.
– Projects insights charts now use Highcharts, which is an industry standard library for charts, improving our accessibility of projects insights.
– You can now use the UpdateProjectV2Field GraphQL API mutation to directly update all single select field options in one API.
Join the discussion in the community discussion to share your feedback.
See how to use GitHub for project planning with GitHub Issues, check out what’s on the roadmap, and learn more in the documentation.
Based on customer feedback, we have updated how the created_at timestamp works in the Copilot seat details portion of responses from the following REST API endpoints:
/organization/{org}/billing/copilot/seats/enterprises/{enterprise}/billing/copilot/seats/organization/{org}/members/{username}/copilotThe created_at timestamp now shows when a user received Copilot access, rather than when their team, enterprise team, or organization was granted access. This matches the timestamp of the seat’s corresponding seat_added event in the Audit Log.
Currently, you are able to query back up to 90 days worth of events from data tables you have access to when reviewing or utilizing specific events features: Events API (including push events), Atom feed, /timeline, or /dashboard-feed. On January 30th, 2025, we will be modifying the window of data retention for these features from 90 days to 30 days.
We are making this change to help GitHub continue to scale for all our users, while continuing to provide existing customers of these features with the ability to still query and view recent important event information.
The relevant APIs that will be affected are:
– /events : List public events
– /networks/{owner}/{repo}/events : List public events for a network of repositories
– /orgs/{org}/events : List public organization events
– /repos/{owner}/{repo}/events : List repository events
– /users/{username}/events : List events for the authenticated user
– /users/{username}/events/orgs/{org} : List organization events for the authenticated user
– /users/{username}/events/public : List public events for a user
– /users/{username}/received_events : List events received by the authenticated user
– /users/{username}/received_events/public : List public events received by a user
– /feeds : Get feeds
On January 30th, 2025, we will be reducing the window that can be queried across those specified events features from 90 days to 30 days. In advance of that, we will test this change for 24 hours on December 3rd, 2024.
As part of this change, we are adding an additional event (DiscussionEvent) as a new EventType for the Events API. This will allow you to query for an event related to Discussions that was not previously available.
We recommend leveraging a workflow that uses weekly or daily exports if you require further historical access.
If you have concerns, comments, or feedback, please join us in this Discussion in the GitHub Community.
As a GitHub Enterprise Cloud organization owner, you and your designated users can now use API insights to visualize REST API activity for your entire organization or specific apps and users. This new feature, currently in public preview, helps you understand the sources of your REST API activity and manage against your primary rate limits—giving you visibility into the timeframe, apps, and API endpoints involved.
The API insights feature is available only at the organization level. By default, only organization owners can access it. However, organization owners can grant access to non-owners by creating a custom role at the organization level, assigning the permission named View organization API insights to the custom role, and then assigning the custom role to an organization member or team. See the documentation for managing organization custom roles.
The API insights public preview feature is enabled for all GitHub Enterprise Cloud organizations. To access it on your organization home page, select Insights near the top of the page, and then select REST API on the left side of the page.
Use the Period and Interval drop-downs to choose the range of time displayed in the chart and how granularly to display REST API requests on the chart. These drop-downs also set the time range for the “Total REST requests,” the “Primary-rate-limited requests,” and the Actors table below the chart.
The Actors table displays the GitHub Apps and users that made REST API requests in the current organization within the selected time period. Select a GitHub App to display its REST API activity and any primary-rate-limiting. Select a user to display their personal REST API activity from personal access tokens (PATs) and OAuth apps acting on their behalf.
We welcome your feedback in this community discussion.
Refer to the documentation for API insights for more details about understanding your organization’s REST API activity and investigating primary-rate-limiting.
Enterprise and organization administrators can now set limits on token lifetimes for the personal access tokens (PATs) used against their resources. These policies mandate token rotation on a regular basis and reduce how long a compromised token is good for, while also providing a lever to reduce the use of less-secure PATs in your company. This public preview is available for all enterprises and organizations, and will be included in GHES 3.16.
Administrators can choose a maximum lifetime between 1 and 366 days for fine-grained PATs and PATs (Classic).
The policies for each token type are distinct, so you can promote the use of fine-grained tokens with a longer lifetime while driving down PAT (Classic) usage with a very short lifetime requirement.
The policies apply when tokens are created, regenerated, or used.
If you want to create a PAT for a specific organization, but that organization or enterprise has a lifetime policy, your lifetime options will be restricted. Additionally, if you try to use an already-created PAT in an organization or enterprise with a policy, the call will fail if the token has too long a lifetime.
If your enterprise has audit log streaming enabled, you’ll be able to track when this policy has blocked a PAT from being used.
With this change, developers can now create fine-grained tokens with no expiration for personal projects, an option that developer feedback said was needed to migrate from PATs (Classic) to more secure fine-grained PATs.
Enterprises and organizations have a 366 day expiration policy for fine-grained tokens by default, so developers still can’t create infinite lifetime fine-grained PATs for use against an organization they’re a member of, unless the administrator relaxes the policy.
For more information, see our documentation on Enterprise and Organization PAT policies.
Join the discussion within GitHub Community for feedback and questions.
The client_id field is now included in all API responses that describe a GitHub App. We are shifting to use the client ID as the primary identifier for an app, as client IDs are globally unique while application IDs and names are not.
Historically GitHub has used the app_name (aka slug) or the app_id (a database ID) to identify applications in our APIs. However, the app name is not immutable and the app ID is not sufficiently globally unique. We are gradually moving all App-related APIs to support the use of the client_id of an application as their primary identifier instead of the name or database ID – this was first seen in our change to support using the client ID to mint JWTs used for installation tokens.
We are making this change to prepare for upcoming features that allow programmatic management of applications in your enterprise. This additional data will make it easier to find the client ID of an application that you are interested in.
For more information about how to get application information, see our REST API documentation.
You can now retrieve the code security configuration applied to a specific repository via the repos endpoint in the REST API. Previously, you could only retrieve all the repositories associated with a configuration rather than the inverse.
Code security configurations help you manage and enforce the enablement of your security features like Dependabot, code scanning, and secret scanning.
To learn more about retrieving code security configurations with our repository REST API endpoint, check out our docs here.
Push protection blocks you from pushing secrets to a repository and generates an alert whenever you bypass the block.
Push protection is now supported for the following REST API endpoints:
* Create a blob
* Create or update file contents
If the content of a PUT request to these endpoints includes a secret, the API will respond with a 409 error and provide a link for bypassing push protection, along with a placeholder_id.
There is also a new API endpoint to bypass push protection programatically, Create a push protection bypass. You or your application can use the placeholder_id from your push protection block in your call to this endpoint.
You need to be the individual or application that initially got blocked to be able to bypass the block successfully.
Today’s changelog brings you GraphQL and webhook support for project status updates and project custom field changes directly in the webhook event!
Following our release earlier this year for project status updates, you can now interact with project status updates using GraphQL and webhooks. This unlocks new ways to automate how you provide and gather project status update information.
There is a new ProjectV2StatusUpdate GraphQL object to interact with project status updates, so you can view, create, update, and delete status updates.
Below is an example query to create a new project status update.
mutation {
createProjectV2StatusUpdate(
input: {projectId: "0123456", body: "We wrapped up our bug bash following the beta rollout. We're back on track for our GA date in August! 🚀", startDate: "2024-06-03", targetDate: "2024-08-09", status: ON_TRACK}
) {
statusUpdate {
id
startDate
targetDate
body
bodyHTML
status
}
}
}
Project status updates are included in the new projects_v2_status_update webhook event, so you can understand and be notified when a new project status update is provided.
You must be subscribed to this event from the organization settings page to receive this information.
Below is an example of a webhook event.
{
"action": "edited",
"projects_v2_status_update": {
"id": 32633,
"node_id": "PVTSU_lADOBH2n9s4Ajp6VzX95",
"project_node_id": "PVT_kwDOBH2n9s4Ajp6V",
"creator": {
...
},
"body": "We've kicked off this project and are feeling confident in our rollout plan. More updates and demos to come next week!",
"start_date": "2024-06-24",
"target_date": "2024-08-16",
"status": "ON_TRACK",
"created_at": "2024-06-24T20:27:48Z",
"updated_at": "2024-06-24T20:30:47Z"
},
"changes": {
"body": {
"from": "We're still planning this out and are kicking off soon.",
"to": "We've kicked off this project and are feeling confident in our rollout plan. More updates and demos to come next week!"
},
"status": {
"from": "INACTIVE",
"to": "ON_TRACK"
},
"start_date": {
"from": null,
"to": "2024-06-24"
},
"target_date": {
"from": null,
"to": "2024-08-16"
}
},
"organization": {
...
},
"sender": {
...
}
}
Project custom field changes are now included directly in the project_v2_item webhook event when a project item’s fields are edited, removing the need to send an additional GraphQL query. This gives you the previous and current field values to understand how project fields change over time and how long they have a particular value, allowing you to understand how long an item was In progress before moving to Done status.
Below is an example of the webhook which includes the previous and current value for single select, text, number, iteration, and date project custom fields using the changes parameter.
"changes": {
"field_value": {
"field_node_id": "PVTSSF_lADOBH2n9s4Aje1Izgb1kEs",
"field_type": "single_select",
"field_name": "Status",
"project_number": 18,
"from": {
"id": "f75ad846",
"name": "Todo",
"color": "GREEN",
"description": "This item hasn't been started"
},
"to": {
"id": "47fc9ee4",
"name": "In Progress",
"color": "YELLOW",
"description": "This is actively being worked on"
}
}
},
convertProjectV2DraftIssueItemToIssue GraphQL mutation to convert drafts to issuesJoin the conversation in the community discussion to share your feedback.
See how to use GitHub for project planning with GitHub Issues, check out what’s on the roadmap, and learn more in the documentation.
Developers of GitHub Apps can simplify their application by using the client ID for both OAuth flows and the installation token flow.
To date, GitHub Apps have had two different IDs to manage – the application ID and the client ID. The application ID was only used to mint a JWT, subsequently used to fetch an installation token. The client ID is used with the OAuth flow to sign in users and request installations. These two values equally identify the application and the question of which one to use where caused unnecessary developer friction. You can now use the client ID in the place of the application ID when minting JWTs.
The application ID is not being deprecated at this time, nor are their plans to remove it. However, compatibility with future features will rely on use of the client ID, so updating is recommended.
The specific change allowed here is that when minting the JWT that proves your app is in posession of an application’s private key, you can use the client ID for the iss claim. Note that application IDs are ints, while client IDs are strings, if using a typed language.
require 'openssl'
require 'jwt' # https://rubygems.org/gems/jwt
# Private key contents
private_pem = File.read("YOUR_PATH_TO_PEM")
private_key = OpenSSL::PKey::RSA.new(private_pem)
# Generate the JWT
payload = {
# issued at time, 60 seconds in the past to allow for clock drift
iat: Time.now.to_i - 60,
# JWT expiration time (10 minute maximum)
exp: Time.now.to_i + (10 * 60),
--- # GitHub App's App ID
--- iss: "12345"
+++ # GitHub App's Client ID
+++ iss: "Iv23f8doAlphaNumer1c"
}
jwt = JWT.encode(payload, private_key, "RS256")
puts jwt
Note that Octokit still expects the use of the App ID in its setup – the Octokit SDK will be updated in the future to support use of the client ID.
You can find the client ID for your application in its settings page:
Client IDs and application IDs are not secrets, and are expected to be visible to the end user – you do not need to change how you handle your IDs when making this update.
For more information about minting JWTs to get an installation token, see ‘Generating a JWT for a GitHub App’.
You can now use the REST API to check if a repository has private vulnerability reporting enabled.
Learn more about:
– Evaluating a repository’s security settings
– Repository security advisories
– Private vulnerability reporting