Changelog

Subscribe to all Changelog posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

→ ~ cd github-changelog
→ ~/github-changelog|main git log main
showing all changes successfully

Enterprises can create GitHub Apps for use within the Enterprise

Enterprise owners can now create GitHub Apps owned by their enterprise, with access restricted to just the organizations and members in the enterprise. Previously, if you wanted to share an app across multiple organizations within your enterprise, you had to either:

  • Duplicate the app for each organization, leading to management overhead and potential inconsistencies, or
  • Make the app public, potentially exposing it to users outside your enterprise.

With this update, you can now safely share an app across your entire enterprise without exposing it to the rest of GitHub.com, and manage your critical apps in a more secure and centralized location.

This also simplifies distribution and management for Copilot Extensions. You can now build custom extensions and share them across your enterprise without making them public – allowing you to create tools specific to your company’s needs and workflows, while keeping them private. Use of a single app across your enterprise ensures consistency and makes it easier to update extensions across all of your teams.

A screenshot of the GitHub app creation page, showing a single visibility option that reads "Only avocado-corp-owned organizations"

These apps can only be installed on organizations in your enterprise, and only members of your enterprise can sign in to them. To ensure the security of your app, user accounts cannot install these apps, only sign in to them. When users or organizations leave your enterprise, they immediately lose access to enterprise-owned apps, and the apps lose access to those users and organizations.

Besides the limitations on where they can be installed and who can sign in, these are standard GitHub Apps. Organization and repository administrators can install them depending on the permissions requested, and they have access to all of the organization and repository APIs that other apps do. Like other apps, they support Copilot Extensions and can be used in Copilot Chat.

Today, only enterprise owners can create and manage these applications. In the future we’ll add support for the App Manager role that exists for organization-owned applications as well, to make it easier for administrators to delegate access to apps in a secure manner.

To learn more about this public beta, see our documentation on GitHub Apps and the enterprise.

See more

Secret scanning: improvements for alerts with known public leaks and enterprise duplicates

You can now view exact locations of known public leaks for a secret scanning alert, as well as any repositories with duplicate alerts across your enterprise. Public leak and duplicate alert labels are now also surfaced via the REST API.

What are public leak and multi-repo labels?

To help you triage and remediate secret leaks more effectively, GitHub secret scanning now indicates if a secret detected in your repository has also leaked publicly with a public leak label on the alert. The alert also indicates if the secret was exposed in other repositories across your organization or enterprise with a multi-repo label.

These labels provide additional understanding into the distribution of an exposed secret, while also making it easier to assess an alert’s risk and urgency. For example, a secret which has a known associated exposure in a public location has a higher likelihood of exploitation. Detection of public leaks is only currently supported for provider-based patterns.

The multi-repo label makes it easier to de-duplicate alerts and is supported for all secret types, including custom patterns. You can only view and navigate to other enterprise repositories with duplicate alerts if you have appropriate permissions to view them.

Both indicators currently apply only for newly created alerts.

Learn more

Learn more about reviewing alert labels and how to secure your repositories with secret scanning. Let us know what you think by participating in our GitHub community discussion or signing up for a 60 minute feedback session.

See more

Copilot secret scanning for generic passwords is generally available

Copilot secret scanning is now generally available. Copilot secret scanning, which detects generic passwords using AI, offers greater precision for unstructured credentials that can cause security breaches if exposed. Over 350,000 repositories have already enabled this password detection.

To enable Copilot secret scanning, select “Scan for generic secrets” within your code security and analysis settings at the repository level, or the code security global settings at the organization level. You can also use the Update a repository API endpoint for enablement at the repository level. Support for enablement through your organization’s code security configurations, as well as enablement for organizations and enterprises with the API, will come in a future release.

Password detection is backed by the Copilot API and is available for all repositories with a GitHub Advanced Security license. You do not need a Copilot license to enable generic secret detection. Passwords found in git content will create a secret scanning alert in the “Experimental” tab, separate from regular alerts.

In effort to reduce false positives and detections of secrets that are used in tests, Copilot secret scanning will not:
– detect more than 100 passwords per push
– detect secrets in media files (.svg, .png, .jpeg)
– detect secrets in language files (.js, .py, .ts, .java, .cs, or .rb) that contain test, mock, or spec in the filepath
– detect additional secrets in files where five or more alerts have been marked as false positive

Note that passwords will not be detected in non-git content, like GitHub Issues or pull requests. Passwords are also excluded from push protection, another feature of secret scanning designed to prevent sensitive information from being pushed to your repository.

Learn more about secret scanning and generic secret detection or join our community discussion.

See more

New PAT rotation policies preview and optional expiration for fine-grained PATs

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.

Screenshot of the policy UI for fine-grained PATs, showing that fine-grained PATs must expire within 90 days and that enterprise administrators are exempt

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.

Allowing infinite-lifetime fine-grained PATs

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.

See more

New Terminology for GitHub Previews

As part of our commitment to improving your experience at GitHub, we’re simplifying the terminology we use to refer to products that are in testing and validation stages. Starting on October 18, 2024, you’ll start seeing the word “Preview” instead of “Alpha” or “Beta” to describe our features that are not yet generally available.

What’s Changing?

Our goal with this update is to create a more consistent, clear process that helps our customers understand the state of new features and how they fit into their development workflows.

  • As shown in the table below, we’re reducing the number of terms we’re using but keeping the same flexibility for giving early access and gathering customer feedback before a General Availability (GA) launch.
  • The key difference between “Private” and “Public” previews is whether the release is publicly announced.

What to Expect

These changes are now live in customer-facing documentation as of today.

Here’s an overview of the changes:

Previous Terminology New Terminology Details
Alpha Private Preview
  • Not publicly announced
  • Limited number of customers
Private Beta
Technical Preview Technical Preview
  • Used for experiments and research projects primarily from GitHub Next
  • Limited number of customers
Limited Public Beta Public Preview
  • Publicly announced on the GitHub Changelog and includes GitHub Docs
  • May be open to all, or limited to selected customers behind a waitlist
Public Beta
General Availability General Availability
Deprecation Closing Down
  • Signals that a product or service is being phased out
Sunset Retired
  • Marks the official end of a product or feature’s life
  • No longer available, supported, or maintained

Thanks for being part of the GitHub community! These updates are designed to provide clearer communication and a smoother experience as we roll out new features.

See more

New code security configurations let you set security features at the organization level

Now you can simplify the rollout of GitHub security products within your organization. Code security configurations now allow you to define collections of security settings and apply those settings to groups of repositories. Configurations help you maintain security settings for important features like code scanning, secret scanning, and Dependabot.

As previously announced in August, starting today, you can no longer enable or disable GitHub security features from the organization-level security coverage view, which has been deprecated and replaced with code security configurations for managing these settings.

Learn more about code security configurations and send us your feedback.

See more

Actions: Runner groups now available for organizations on Free plan

Starting today, organizations on all plans, including the Free plan, can now utilize GitHub Actions runner groups with self-hosted runners. Runner groups enable you to manage runner permissions and control access to these runners across your organization.

Please note that GitHub-hosted larger runners are not available to free organizations and therefore cannot be included in runner groups. For more details about managing access to self-hosted runners using runner groups, please refer to our documentation.

See more

What’s New in Mobile, October Update

In the landscape image, a dark red gradient shape is positioned partially off-canvas from the top-right. The text "What's New in GitHub Mobile" is centered in the foreground and followed by a description of the October update.

August and September contained a number of improvements to GitHub Mobile, including Focused Notifications for those high-priority items in your Inbox, a contribution graph widget on Android, and a continued focus on accessibility.

Introducing Focused Notifications

View important notifications first with the new Focused filter in the Inbox.

A screenshot of the GitHub Mobile app showing certain notifications filtered down by priority

Learn more about Focused Notifications in the Changelog blog post.

iOS

What’s new

  • When accessing content protected by SAML single sign-on (SSO) login, authenticate directly with your organization without logging out.
  • Achievement badges rotate in your palm, just as it would in real life.

Bug fixes

  • Activate filters in Explore via keyboard navigation.
  • Assistive technologies iterate through reviewer information in the pull requests.
  • Confirm saving draft or deleting content before dismissing modal forms.
  • Description of a forked repository isn’t cut off when using large text sizes.
  • Dismiss triage sheet view with mouse on iPadOS.
  • Dismiss user status update, repository watch settings or the edit “My Work” view using the Escape key on a connected hardware keyboard.
  • Filter bar doesn’t clip at large accessibility sizes.
  • Font sizes respect the user’s Dynamic Type preference when composing comments.
  • Hide “Read More” button when Explore item doesn’t include truncated content.
  • Hovering over Copilot button with trackpad or mouse on iPadOS shows a pointer effect.
  • Improved support for large accessibility sizes within user profiles, account lists, pull request review line numbers, repository headers, the Explore view, code review view, comment author usernames, and editing Home “My Work” items.
  • Items in the Explore feed no longer truncate when using large text sizes.
  • Merge confirmation dialog appears as a modal on iPadOS.
  • Merging or marking a pull request as ready for review updates the pull request state in the Inbox and Recent Activity list.
  • Moving an item from one project group to another updates the title of the group.
  • Project pickers for a repository shows projects owned by the repository owner.
  • Repositories in lists no longer truncate their content when using large text sizes.
  • Scale badge icons on repository profile with font size.
  • Tapping a user avatar or username within comments navigates to the user profile.
  • Tapping on links to issue and pull request comments scrolls to the destination comments.
  • The area next to floating elements no longer blocks scrolling.
  • Toast messages no longer overlap with other floating elements on the screen.
  • Toolbars for user input fields scale with font size.
  • User and organization details no longer truncate when using large text sizes.
  • Username in a comment doesn’t disappear when using large text sizes.
  • VoiceOver announces “Jump to file” and “Dismiss line selection” buttons when reviewing file changes.
  • When sharing an issue or pull request, assistive technologies distinguish between the two types of content.
  • When viewing a list of workflow runs that have no runs yet, an empty state displays on the screen.

Android

What’s new

Bug fixes

  • Actions workflow logs show clearer error messages.
  • Editing a file opened via permalink no longer shows an endless spinner.
  • Filtering notifications by repository is more accessible for TalkBack users.
  • Improved accessibility for bulk selection of notifications.
  • Improved keyboard accessibility when reordering shortcuts.
  • Improved keyboard navigation on Home tab.
  • Pull request review suggestions are accessible via keyboard navigation.
  • Releases are more accessible via keyboard navigation.
  • Replying to and resolving comments is more accessible with large fonts.
  • Subscribing or unsubscribing to an issue or pull request considers custom repository watch settings.
  • The code options screen is more accessible with large fonts.
  • When viewing a list of workflow runs that have no runs yet, an empty state displays on the screen.
See more

EPSS Scores in the GitHub Advisory Database

The GitHub Advisory Database now features the Exploit Prediction Scoring System (EPSS) from the global Forum of Incident Response and Security Teams (FIRST), helping you better assess vulnerability risks.

EPSS scores predict the likelihood of a vulnerability being exploited, with scores ranging from 0 to 1 (0 to 100%). Higher scores mean higher risk. We also show the EPSS score percentile, indicating how a vulnerability compares to others.

For example, a 90.534% EPSS score at the 95th percentile means:

  • 90.534% chance of exploitation in the next 30 days.
  • 95% of other vulnerabilities are less likely to be exploited.

Learn more in the FIRST’s EPSS User Guide.

This feature will be available in GitHub Enterprise Server version 3.16 and later.

See more

Now you can choose a specific branch when using Copilot Autofix for code scanning

When using Copilot Autofix for historical alerts, you can now choose the branch to which you want to commit an autofix. You can also decide whether to then open a pull request, check out the branch locally, or open it in GitHub Desktop.

Copilot Autofix provides automatic fix suggestions for code scanning alerts in your codebase.

Example of committing Copilot Autofix to branch

This update integrates Autofix more closely within the developer workflow, so you can quickly iterate on fix suggestions and collaborate on those with your team.

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.

See more

Introducing Focused Notifications

Focused Notifications is now generally available on iOS and Android, helping you focus on the most important updates. Focused Notifications shows you notifications from the past 30 days that are more relevant to you, such as items that you’ve authored, items in which you’ve been directly mentioned, and items to which you’re assigned or you’ve manually subscribed. This helps you stay on top of what matters most while reducing notification noise.

focused notification screenshot on Github mobile

Learn more about GitHub for mobile, download GitHub for iOS today, and send us your feedback to help us improve.

See more

Upcoming replacement of enterprise code security enablement UI and APIs

In the coming months, the current interface for managing code security settings for an enterprise will be deprecated and replaced with new and improved code security configurations that will provide you a more consistent and scalable way to manage security settings across repositories within your enterprise.

The current REST API endpoint to enable or disable a security feature for an enterprise is now deprecated. It will continue to work for an additional year in the current version of the REST API before being removed in September of 2025, but note that it may conflict with settings assigned in code security configurations if the configuration is unenforced, potentially resulting in a security configuration being unintentionally removed from a repository. To change the security settings for repositories at the enterprise level, you can use the current enterprise-level security settings UI or the upcoming code security configurations API.

Send us your feedback!.

See more

Deprecation notice – Dependabot will no longer support Composer v1

As of November 6, 2024, Dependabot will no longer support Composer version 1, which has reached its end-of-life. If you continue to use Composer version 1, there’s a risk that Dependabot will not create pull requests to update dependencies. If this affects you, we recommend updating to a supported release of Composer. As of October 2024, the newest supported release of Composer is 2.8, and the long-term supported version is 2.2. View Composer’s official documentation for more information about supported releases.

See more

Copilot content exclusions now available for enterprise admins

Enterprise admins can now manage and apply content exclusions at the enterprise level. This expands upon previous capabilities where only org admins and repo admins could apply exclusions. Enterprise admins can now implement exclusions that apply to all users within the enterprise, providing a more comprehensive and centralized approach to managing content exclusions.

How to get started?

Enterprise admins can access Copilot Content Exclusions by navigating to the Policies tab, clicking on Copilot, and then selecting the Content Exclusions tab.

Enterprise admin Copilot Content Exclusions

Enterprise admins can learn more about excluding content with Copilot in our detailed documentation: Configuring Content Exclusions For GitHub Copilot

How will repo-level rules change with the introduction of enterprise-level rules?

There are no changes to repo-level rules with the introduction of enterprise-level settings. If a repo admin has excluded certain files from that repository, those exclusions will continue to apply to all users working on that repo within the enterprise.

How will org-level rules change with the introduction of enterprise-level rules?

Currently, org-level rules apply to all users across the enterprise. However, once enterprise-level settings are available and applied by enterprise admins, org-level rules will only affect users who are assigned Copilot seats from that specific org. This change allows for more targeted control within each organization, ensuring that org rules are scoped more precisely.

Important Details for Org Admins

If you haven’t set any rules at the org level yet, any rules you set going forward will only apply to users getting Copilot seats from your org.

If you are an existing org with rules already set up for content exclusions, here’s what you need to know:

Before November 8th:

  • If Enterprise Admins Do Not Set Rules: Org-level rules will continue to apply to all users across the enterprise, functioning as they do today.
  • If Enterprise Admins Set Rules: Once enterprise-level rules are applied, org-level rules will only apply to users with Copilot seats from your specific org.

After November 8th:

  • 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.

Please coordinate with your enterprise admins to ensure that rules are set correctly for your organization.

Read Copilot content exclusions document to learn more about our exclusion rules.

See more

Copilot Chat in VS Code upleveled with new GitHub skills

New skills have been added to Copilot Chat in VS Code, enabling you to search across GitHub to find commits, issues, pull requests, repositories, and topics. GitHub Copilot will either automatically infer when to use the @github agent, or you can invoke it directly by asking questions like:
– @github What are all of the open PRs assigned to me?
– @github What are the latest issues assigned to me?
– @github When was the latest release?
– @github Show me the recent merged pr's from @dancing-mona

This functionality is available to all Copilot users, with Copilot Chat v0.20.3 or later and VS Code or VS Code Insiders 1.93 or later. Learn more about asking questions in Copilot Chat on VS Code and available skills

Let us know your feedback and join the discussion within the GitHub Community!

See more

Deprecation – Dependabot no longer supports Bundler v1

As of October 7, 2024, Dependabot no longer supports Bundler version 1, which has reached its end-of-life. If you continue to use Bundler version 1, Dependabot will be unable to create pull requests to update your dependencies. If this affects you, we recommend updating to a supported release of Bundler. As of October 2024, the newest supported version is 2.5.

View Bundler’s official support policies for more information about supported releases.

See more

Secret scanning non-provider patterns are generally available

Secret scanning support for non-provider patterns is now generally available for all GitHub Advanced Security customers.

Non-provider patterns are generic detectors that help you uncover secrets outside of patterns tied to specific token issuers, like HTTP authentication headers, connection strings, and private keys. You can enable them in your repository’s code security and analysis settings, or through code security configurations at the organization level.

Learn more about secret scanning and non-provider patterns, and join the GitHub Community discussion.

See more

Secret scanning alert lists renamed to “Default” and “Experimental”

The secret scanning alert lists are now named “Default” and “Experimental,” better reflecting the alert categories and making it easier for you to tell experimental alerts from default alerts.

The Default list includes alerts for provider patterns and custom patterns. The Experimental list includes alerts for non-provider patterns and AI-detected passwords. You can view the alert counts of these two lists in the organization-level Security tab in the sidebar, bringing more clarity and visibility into your alerts.

You can filter within the alert list using results:default and results:experimental.

Learn more about secret scanning and the supported patterns.

See more

Code security configurations now support archived repositories

You can now apply code security configurations to archived repositories. This makes it simpler to roll out configurations without having to filter for archived repos, and ensures features like Dependabot, code scanning, and secret scanning are automatically reapplied if a repo is unarchived.

If a repository has configurations applied and later becomes archived, the settings will persist and still apply.

Note: when a repository is archived, the only security feature that will still run is secret scanning. However, if the repository is ever unarchived, all other features in the applied configuration, such as Dependabot or code scanning, will be reapplied automatically.

This release also adds a new filter to the repository table on the code security configurations UI page, allowing you to filter for archived repositories with archived:true.

Learn more about code security configurations, the REST API and send us your feedback.

See more

Streamlined coding, debugging, and testing with GitHub Copilot Chat in VS Code

A list of the GitHub Copilot Chat updates in the September VS Code release.

In the latest Visual Studio Code release, you will find a suite of enhancements to GitHub Copilot Chat, designed to streamline your coding, debugging, and testing processes.

These features are now available for you to try out in the latest version of Visual Studio Code.

Pick your language model

Sign up for early access to the latest OpenAI o1 models for more precise and efficient coding assistance. Once you have access, you will have the model picker control in Copilot Chat in VS Code. You can then choose which model version to use for your chat conversations.

Screenshot of the language model picker control in Cpilot Chat.

Enhanced code quality with GPT-4o

Copilot Inline Chat now uses GPT-4o, giving you faster, more accurate, and higher-quality code and explanations when you use Chat in the editor.

Public code matching in chat

You can allow GitHub Copilot to return code that could match publicly available code on GitHub.com. When this functionality is enabled for your organization subscription or personal subscription, Copilot code completions already provided you with details about the matches that were detected. We now show you these matches for public code in Copilot Chat as well.

If this is enabled for your organization or subscription, you might see a message at the end of the response with a View matches link. If you select the link, an editor opens that shows you the details of the matching code references with more details.

Screenshot of GitHub Chat in VS Code. A red rectangle highlights the end of a response that reads "Similar code found with 2 license types - View matches."

File suggestions in chat

In chat input fields, you can now type # to get file name suggestions and quickly attach them to your prompt as context. This works in chat locations that support file attachments, such as the Chat view, Quick Chat, Inline Chat, and Notebook Chat.

Drag and drop files to add chat context

You can now attach additional files as context for a chat prompt by dragging files or editor tabs from the workbench directly into chat. For Inline Chat, hold Shift and drop a file to add it as context instead of opening it in the editor.

File attachments included in history

When you attach a file or editor selection as relevant context to your chat request, Copilot Chat will include them in the history of follow-on requests so that you can keep referring to them without having to reattach them. Previously, this context was added only for the current request and was not included in the history of follow-on requests.

Chat conversation shows that Copilot keeps track of attached files across multiple prompts.

Inline Chat and completions in Python native REPL

The native REPL editor, used by the Python extension, now supports Copilot Inline Chat and code completions directly in the input box.

Semantic search results (Preview)

Setting: github.copilot.chat.search.semanticTextResults

You can perform an exact search across your files with the Search view. It also now uses Copilot to give search results that are semantically relevant.

This functionality is still in preview and by default, the setting is not enabled. Try it out and let us know what you think!

Fix test failure (Preview)

Setting: github.copilot.chat.fixTestFailure.enabled

New fix test logic now helps you diagnose failing unit tests. This logic is triggered in some scenarios by the /fix slash command, and you can also invoke it directly with the /fixTestFailure slash command. The command is enabled in chat by default but can be disabled via the setting github.copilot.chat.fixTestFailure.enabled.

Automated test setup (Experimental)

Setting: github.copilot.chat.experimental.setupTests.enabled

You can now use an experimental /setupTests slash command to configure the testing set up for your workspace. This command can recommend a testing framework, provide steps to set up and configure it, and suggest a VS Code extension to provide testing integration in VS Code.

When you use the /tests command to generate tests for your code, Copilot Chat can recommend /setupTests and testing extensions if it looks like such an integration has not been set up yet in your workspace.

Start debugging from Chat (Experimental)

Setting: github.copilot.chat.experimental.startDebugging.enabled

You can use the /startDebugging slash command to find or create a launch configuration and start debugging your application. When you use @vscode in Copilot Chat, /startDebugging is now available by default.

A user types /startDebugging flask app port 3000 in the panel chat and is provided with the launch configuration.

Chat in Command Center (Experimental)

Setting: chat.commandCenter.enabled

You can now access chat via the Command Center, which provides access to all relevant chat commands, like starting the different chat experiences or attaching context to your prompt. Note that the Command Center itself needs to be enabled for the chat Command Center entry to show.

Chat Command Center button and the drop-down menu with relevant chat actions.

Custom test generation instructions (Experimental)

Generating tests with Copilot helps you write code that is more robust. With custom instructions you can ensure that the generated tests meet your specific coding style and requirements.

Setting: github.copilot.chat.experimental.testGeneration.instructions

In addition, you can now define instructions for test generation in settings or import them from a file. For example, if you always want to use a particular unit testing framework for your tests. Configure the test-generation instructions in the github.copilot.chat.experimental.testGeneration.instructions setting.

✍️ We want your feedback

Try out these new features and share your experiences and feedback in our issues.

See more
View more changes