Copilot content exclusion is now generally available in IDEs

We’re excited to announce that content exclusion for Copilot is now generally available for all Copilot Business and Copilot Enterprise users! This feature, previously available only in beta, allows you to control which code Copilot can access to generate suggestions. When you exclude content from Copilot:

  • Code completion will not be available in the affected files.
  • The content in affected files will not inform code completion suggestions in other files.
  • The content in affected files will not inform GitHub Copilot Chat’s responses.

How to exclude content using content exclusions for Copilot?

Enterprise, organization, and repository admins can set up exclusions through their settings, as outlined in our documentation: Excluding content from GitHub Copilot

For availability across surfaces, please check the information here: Availability of content exclusion

Enterprise admin Copilot Content Exclusions

For users previously in beta:

Previously Used Enterprise-Level Rules:

  • If you already had enterprise-level exclusion rules set up (as described in previous changelog), you won’t experience any changes. These rules will continue to function as intended.

Previously Used Organization-Level Rules:

  • If your exclusions were previously set at the organization level but not the enterprise level: Org-level rules will no longer apply enterprise-wide. They will be limited to users who are assigned Copilot seats from your org, regardless of whether enterprise-level rules are applied.

Join the discussion within GitHub Community.

Upcoming changes to data retention for Events API, Atom feed, /timeline and /dashboard-feed features

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.

Why are we making changes?

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.

Which APIs will be impacted in this change?

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

When can you expect the changes to occur?

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.

Additional support

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.

Where can I learn more?

If you have concerns, comments, or feedback, please join us in this Discussion in the GitHub Community.

See more

Updated limits for GitHub App private keys and scoped tokens

GitHub Apps are now subject to a limit of 25 private keys per application and can create scoped tokens with access to more repositories. These changes support safer key management and access practices in your applications.

25 key limit for GitHub Apps

There is now a limit (25) on the number of private keys a GitHub App can have registered at one time. 99.99%+ of apps are below this limit – the ones above this limit will be unable to create more keys until they have deleted all but 24 of their keys.

Use of multiple keys for zero-downtime key rotation is encouraged. However, sharing keys among multiple parties is not recommended, which an unlimited number of keys lead developers towards. This new limit should help app developers look for safe alternatives earlier in the development lifecycle.

See our documentation on GitHub App key management for more details and best practices.

No limit on repositories for permissions-scoped tokens

In February 2024, GitHub placed a limit on the complexity of the scoped tokens that apps could request. Now, part of this limit no longer applies. Apps can now be installed on any number of repositories in an organization and request a scoped token for all those repositories. The limitation on tokens that request a subset of both permissions and tokens remains.

To learn about scoped tokens, and how they can improve the least-privilege access of your App’s tokens, see our GitHub App authentication documentation.

See more
View all changes