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

Accessibility improvements for security overview

New accessibility enhancements to the security overview data visuals make it easier and more inclusive for everyone to interact with and understand code security insights.

Graph showing open alerts by severity on the security overview dashboard, with enhanced accessibility

What’s new?

  • Improved visual accessibility: Enhanced color contrast and better support for users with low vision, making it easier to interpret data visuals.
  • Keyboard navigation enhancements: Full keyboard-only navigation, including a clearly visible focus indicator, for smoother interactions without a mouse.
  • Assistive technology support: Improved compatibility with screen readers for better navigation and understanding of content.

These updates are now generally available on GitHub Enterprise Cloud and will be included in GitHub Enterprise Server 3.16.

Join the discussion in the GitHub Community and read more about GitHub’s commitment to accessibility

See more

Dependabot can now perform version updates for the .NET SDK

Dependabot can now keep you up to date with the latest version of the .NET SDK by updating the global.json file in your repository. You can enable updates for the .NET SDK by adding a dotnet-sdk entry to your dependabot.yml file. At this time, Dependabot will not create security alerts for the .NET SDK, although performing regular version updates will ensure you’re always using the latest .NET SDK.

See our documentation to learn more about configuring Dependabot.

See more

Build Copilot Extensions faster with skillsets

Skillset header image

Today we’re introducing skillsets, a new lightweight way to build GitHub App-based Copilot Extensions alongside our existing agents approach. While agents offer full control over the user interaction, skillsets make it easy to integrate external tools and services into Copilot Chat by defining simple API endpoints – no AI expertise needed!

What’s new ✨

  • Let Copilot handle all AI interactions and response formatting
  • Define up to 5 skill endpoints that Copilot can call
  • Simple JSON schema configuration
  • Quick setup with minimal code

Benefits for builders ⚡️

  • Faster Development: Focus on your core functionality instead of AI interactions
  • Simple Implementation: Just define API endpoints, without managing LLM logic
  • Minimal Setup: No complex server infrastructure required, with the option to use existing APIs
  • Consistent Experience: Copilot maintains natural chat interactions automatically

Choosing your integration path 🛠

  1. Skillsets: Perfect for straightforward integrations like data retrieval and basic actions. You provide the API endpoints, and Copilot handles workloads like prompt crafting and response generation.
  2. Agents: Ideal for complex workflows needing custom logic, flexible prompt crafting, or specific LLM models. You control the entire interaction.

How it works 🏗️

End users interact with skillset-based extensions just like any other Copilot Extension. Just type @ followed by the extension name and ask in natural language. Behind the scenes, Copilot:

  • Analyzes the query to determine which skill to call
  • Structures the API request based on your JSON schema
  • Calls your endpoint to get the data
  • Formats and generates the response in chat

Architecture

architecture diagram

Requirements for extension builders

  • Access to GitHub Copilot
  • For organizational builds: Free, Team, or supported Enterprise Cloud organization types
  • Skillsets only apply to extensions built as GitHub Apps, and not VS Code chat participants

Getting started 🚀

Check out our documentation to learn how to build your first skillset.

Already built a Copilot Extension as an agent? Existing agent extensions can be converted into skillsets, but one extension cannot be both a skillset and an agent.

We want to hear your feedback!

See more

Persistent commit signature verification now in public preview

We’re excited to introduce persistent commit signature verification, a powerful new feature designed to elevate the security and reliability of your repository’s commit history.

Starting today, GitHub verifies commit signatures when they are first pushed, and once a commit’s signature is verified, it remains verified within its repository’s network. This supports organizations in maintaining a secure and accurate record of contributions without constantly rechecking the validity of every signature. You can view these persistent verifications directly on GitHub, where a quick hover over the Verified badge displays the timestamp of the original verification.

Efficient, Secure, and Transparent Verification

Previously, commit signatures were verified on demand, via a process that was not performant and had risks of previously verified signatures becoming “unverified” due to various reasons like service outages or key rotations.

Persistent commit signature verification solves these issues by validating signatures at the time of the commit and storing the verification details permanently. This also brings consistency to the commit history as git commits are immutable and they do not natively support key rotation.

Managing commit signatures can be a challenge, but persistent records ensures that verified commits remain verified over time, even if signing keys are rotated, revoked, or contributors leave the organization.

How to tell if the verification has a persistent record?

When a commit’s signature is verified upon being pushed to GitHub, the verification record is stored alongside the commit. This record is immutable, ensuring that the verified status is maintained permanently.

You can view the verification timestamp by hovering over the Verified badge on GitHub or via the GitHub REST API which now includes a verified_at field.

Learn more about commit signature verification on GitHub.

Designed for Real-World Key Rotation and Contributor Management

For organizations managing signature verification – whether GPG, SSH, or X.509 keys using S/MIME – persistent commit signature verification provides a robust way to ensure signature integrity across the board. Now, any commit with a verified status can retain that status, even when the signing key is rotated or removed.

Persistent commit signature verification is applied to new commits only. For commits pushed prior to this update, persistent records will be created upon the next verification, which happens when viewing a signed commit on GitHub anywhere the verified badge is displayed, or retrieving a signed commit via the REST API. This ensures that your repository remains secure while providing flexibility in managing your verification practices.

This approach lays the groundwork for future improvements aimed at enhancing repository integrity and authenticity of contributions within GitHub.

Key Management Caveat: Revocation and Expiration

Persistent commit signature verification ensures that verified commits retain their status indefinitely, it’s important to note this records the state of the signature at the time of the commit. If a signing key is later revoked, expired, or otherwise changed, GitHub will not re-verify previously signed commits or retroactively modify the verification status.

For organizations using S/MIME keys, this does introduce a minor change: revoked S/MIME keys will not verify new commits or those without an existing persistent record. Since git commits are immutable, persistent commit signature verification aligns with this concept by maintaining the original verification status without change. Organizations may need to manage key states directly to align with their security policies, especially in cases involving frequent key rotation or revocation.

This approach ensures that once a commit is verified, it remains trusted based on the record at the time, bringing consistency and long-term reliability to your commit history.

Moving Towards a Future with Secure and Authentic Contributions

With this launch, we’re addressing a key issue: commit verification that isn’t fragile or temporary. Teams can now implement signing key policies, without worrying about losing the verified status of past work.

Stay tuned for more updates as we continue to enhance commit verification. If you have feedback or suggestions, please let us know through our GitHub Discussions forum.

See more

The GitHub Enterprise Server 3.15 Release Candidate is available

The GitHub Enterprise Server 3.15 release candidate is here

You can now download the GitHub Enterprise Server 3.15 release candidate to try out the new features in this latest version. Version 3.15 gives customers enhanced deployment requirements and security controls. Here are a few more highlights in the 3.15 release:

  • We have updated root disk size requirements. New installations of GitHub Enterprise Server version 3.15 and upgrades to 3.15 now require a root disk size of at least 400GB. System will not boot otherwise. For more information on how to increase the root disk size in the appliance, see increasing storage capacity.

  • We have also updated minimum server specs recommended to run GHES. For more information, see minimum recommended requirements.

  • 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. For more information, see GitHub Projects.

  • Custom properties now support new property types: multi select and true/false. Organization repositories can now be queried and filtered via properties. Both the UI and API are supported. Read about filtering repositories.

  • Code security configurations are now available in GHES. These configurations simplify the rollout of GitHub security products at scale. They help you define collections of security settings and apply them across groups of repositories. We have retired the old organization-level code security settings UI experience along with the API parameters that complemented it. For more information, see code security configurations.

  • Secret scanning push protection is now supported for content upload REST API endpoints – create a blob and create or update file contents. Push protection blocks you from pushing secrets to a repository and generates a secret scanning alert whenever you bypass the block.

  • CodeQL‘s support for Swift and Kotlin is now generally available. CodeQL is the static analysis engine that powers GitHub code scanning.

  • Organization owners can now grant a user or team access to all of the repositories in their org with a single click. New pre-defined roles have been added to the organization settings, under Organization Roles > Role Management, where all organization owners can view and assign them. These can be further customized as well to grant specific repository permissions across your organization. For more information, see organization roles.

Release Candidates are a way for you to try the latest features early, and they help us gather feedback to ensure the release works in your environment. They should be tested on non-production environments. Read more about the release candidate process.

To learn more about GHES 3.15, check out release notes, or download the 3.15 release candidate now.

If you have any feedback or questions about the release candidate, please contact our Support Team.

See more

Secret scanning: ability to add an optional comment when reopening alerts

To remediate and triage alerts more effectively, you can now add an optional comment when reopening a secret scanning alert. Comments will appear in the alert timeline. Previously, you could only add a comment when closing the alert.

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

See more

Push protection bypass request details are included in the REST API, webhooks, and audit logs for secret scanning alerts

Secret scanning alerts resulting from an approved push protection bypass request will now show relevant details in the alert information surfaced in the REST API, webhooks, and audit logs. This allows information currently visible in the UI to be used in automated workflows.

Secret scanning alert REST API endpoints and webhook events now include the following fields:
– push_protection_bypass_request_reviewer
– push_protection_bypass_request_comment
– push_protection_bypass_request_html_url

Audit log events for push protection bypasses now include the following fields:
– push_protection_bypass_request_reviewer
– push_protection_bypass_request_reviewer_id

Learn more about secret scanning and bypass controls for push protection.

See more

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.

See more

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

Organizations can now enable 2FA requirement without removing non-compliant members [GA]

Enterprises can now broadly roll out two-factor authentication (2FA) to all members of their organization through an enhanced 2FA enrollment experience in GitHub. With this update, non-compliant users will no longer be removed from organizations when an organization begins enforcing 2FA.

2FA will be enforced via conditional access policies, which means members who have not yet enabled 2FA will continue to have their organization membership, but be blocked from visiting any organization resources until they enable 2FA.

This enables organizations to enable a broader 2FA enrollment without disrupting the membership status of their members who are yet to enable 2FA. This also enables members without elevated privileges to enable or disable 2FA on their accounts without losing organization membership.

Learn more about how GitHub is securing developer accounts using 2FA, and why we’re urging more organizations to join us in these efforts.

See more

Copilot Immersive update for Copilot Enterprise customers

Screenshot showing the empty state of the new Copilot immersive experience with a number of suggestions how to get started and an a message in the input that reads - Who contribute to those files - with a repository and two files selected for context.

We’ve enhanced the fullscreen Copilot chat experience on github.com/copilot with a streamlined UI and an even easier way to handle context:

  • Effortlessly see and navigate previous conversations with a new collapsible sidebar
  • Dynamically set and remove repository context to suit your workflow
  • Manage all your resources seamlessly in a unified attachment menu

These updates are available in preview for Copilot Business and Copilot Individual users. Check out the updates, and let us know what you think using the in-product feedback option.

See more

Deprecation – Dependabot no longer supports Composer v1

As of November 6, 2024, Dependabot no longer supports Composer version 1, which has reached its end-of-life. If you continue to use Composer 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 Composer. As of October 2024, the newest supported version 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

EMU OIDC CAP support is now enhanced to protect web sessions [Public Preview]

If you are using GitHub Enterprise Cloud with EMU and using OpenID Connect (OIDC) SSO, this new feature, currently in public preview, will help enforce IdP-defined IP restrictions to protect all web interactions on GitHub.

Currently, when your enterprise uses OIDC-based SSO and if any of the enterprise members change their IP address, GitHub can validate their access to your enterprise and its resources using your IdP’s Conditional Access Policy (CAP). IdP CAP validations previously covered only non-interactive flows where users authenticate with a personal access token or SSH key.

With this launch, we are now extending these validations to include all interactive web flows. If you already had IdP CAP turned ON previously, you will need to explicitly opt-in into extended protection for web sessions from their enterprise’s “Authentication security” settings. If you enable IdP CAP support after today’s public preview launch, you will get the coverage across web flows by default.

When this feature is generally available, we plan to have both interactive and non-interactive flows protected by the IdP CAP validations for all customers by default and remove the additional step of requiring to opt-in.

Learn more about GitHub’s support for your IdP’s Conditional Access Policy.

See more

Notice of breaking changes for GitHub Actions

Ubuntu-latest upcoming breaking changes

We will migrate the ubuntu-latest label to ubuntu 24 starting on December 5, 2024 and ending on January 17, 2025. The ubuntu 24 image has a different set of tools and packages than ubuntu 22. We have made cuts to the list of packages so that we can maintain our SLA for free disk space. This may break your workflows if you depend on certain packages that have been removed. Please review this list to see if you are using any affected packages.

Artifacts v3 brownouts

Artifact actions v3 will be closing down by December 5, 2024. To raise awareness of the upcoming removal, we will temporarily fail jobs using v3 of actions/upload-artifact or actions/download-artifact. Builds that are scheduled to run during the brownout periods will fail. The brownouts are scheduled for the following dates and times:
– November 14, 12pm – 1pm EST
– November 21, 9am – 5pm EST

Changes to workflow validation for pull requests originating from forked repositories

Currently, you can prevent Actions workflows from automatically running on pull requests made from forked repositories. Actions evaluates whether the actor initiating the request is trusted based on the repository’s settings. Effective today, Actions will require validation of both the pull request author and the event actor to determine if a workflow should run from a pull request event originating from a forked repository. For more information on for pull request approvals, see our documentation.

New webhook rate limit

As GitHub continues to invest in availability, GitHub Actions is introducing a new webhook rate limit per repository. Each repository is now limited to 1500 triggered events every 10 seconds. For more details about the new webhook rate limit, please refer to our documentation.

Updates to the network allow list for self-hosted runners and Azure private networking

With the upcoming GA of Immutable Actions, Actions will now be stored as packages in the GitHub Container Registry. Please ensure that your self-hosted runner allow lists are updated to accommodate the network traffic. Specifically, you should allow traffic to ghcr.io and *.actions.githubusercontent.com. If you require more specific domains, you can use pkg.actions.githubusercontent.com instead of *.actions.githubusercontent.com.

This update also affects runners in all versions of GitHub Enterprise Server that use the GitHub Connect feature to download actions directly from github.com. Customers are advised to update their self-hosted runner network allow lists accordingly. For further guidance on communication between self-hosted runners and GitHub, please refer to our documentation.

Additionally, our guidance for configuring Azure private networking has been updated to account for the the addional domains. The following IP addresses have been add to the NSG template in our documentation.
– 140.82.121.33/32
– 140.82.121.34/32
– 140.82.113.33/32
– 140.82.113.34/32
– 140.82.112.33/32
– 140.82.112.34/32
– 140.82.114.33/32
– 140.82.114.34/32
– 192.30.255.164/31
– 4.237.22.32/32
– 20.217.135.1/32
– 4.225.11.196/32
– 20.26.156.211/32

See more

Copilot subscription-based network routing is now enforced

Network requests for Copilot are routed based on a user’s Copilot subscription. Requests for Copilot Individual, Copilot Business, and Copilot Enterprise users now route through different endpoints.

This change enables Copilot Business and Copilot Enterprise customers to make sure all Copilot users on their networks are accessing Copilot through their Copilot Business or Copilot Enterprise subscription, and that all Copilot user data is handled according to the terms of their Copilot Business or Copilot Enterprise agreement. In essence, customers will be able to use their network firewall to explicitly allow access to Copilot Business or Copilot Enterprise, and/or block access to Copilot Individual.

Today we enabled enforcement of the user’s subscription on the new endpoints, ensuring only Copilot Business users can connect to Copilot Business endpoints and only Copilot Enterprise users can connect to Copilot Enterprise endpoints.

Read more about subscription-based network routing here.

See more

Claude 3.5 Sonnet is now available to all Copilot users in public preview

Claude 3.5 Sonnet is now available in public preview

Announced at GitHub Universe 2024, Claude 3.5 Sonnet is now available to all GitHub Copilot customers. To see Claude 3.5 Sonnet in action in Visual Studio Code check out the video below.

Copilot Individual users

You can start using the new Claude 3.5 Sonnet today via the model selector in Copilot Chat in VS Code and immersive chat on GitHub.com.

Copilot Business or Enterprise users

Copilot Business and Enterprise organization administrators will need to grant access to Claude 3.5 Sonnet in Copilot via a new policy in Copilot settings. Once enabled, you will see the model selector in VS Code and chat on GitHub.com. You can confirm availability by checking individual Copilot settings and confirming the policy for Claude 3.5 Sonnet is set to enabled.

Share your feedback

We’re excited to hear from you! Please use our Community Discussions to provide feedback and share tips with others.

For additional information, check out the docs on Claude 3.5 Sonnet in Copilot.

See more

SAST vulnerabilities summary now available on the security overview dashboard

Now you can better manage and mitigate your security vulnerabilities with a new SAST vulnerabilities summary table, available directly on the security overview dashboard. This feature highlights your top 10 CodeQL and third-party open alerts by count, grouped by vulnerability type.

The SAST vulnerabilities table on the Detection tab of the overview dashboard

When prioritizing which alerts to address first, it’s crucial to consider various factors. One significant factor is the number of instances of a vulnerability across your codebase. The more areas of code affected by a vulnerability, the higher the potential risk for exploitation.

To access the new SAST vulnerabilities table, click your profile photo in the top-right corner of GitHub.com and select the organization or enterprise you want to view. For organizations, go to the Security tab and scroll to the bottom of the Detection view on the Overview dashboard. For enterprises, click Code Security in the sidebar, then select Overview and scroll to the bottom of the Detection view.

The SAST vulnerabilities summary is now generally available on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.16.

Learn more about security overview insights and join the discussion within the GitHub Community

See more

Actions Performance Metrics in public preview

Today, Actions Performance Metrics is now in public preview for all users of GitHub Actions. Actions Performance Metrics is an observability UI that gives you insights into your workflow or job performance for your organizations or repositories. To access the feature, on your organization home page, select Insights near the top of the page, and then select ‘Actions Performance Metrics’ on the left side of the page.

Performance metrics can help you answer these commonly asked questions about your Actions workflow runs:

  • How long does it take for my workflows or jobs to complete?
  • How long are my workflows or jobs waiting to run?
  • Which of my workflows or jobs are consistently failing?
  • Where are my longest running workflows or jobs originating from?

Actions Performance metrics dashboard job view

GitHub Actions Metrics for Free, Pro, and Team plans

We are also pleased to announce that with today’s release, GitHub Actions Metrics are now available to Free, Pro, and Team plans. Previously, this feature was only available to those on the GitHub Enterprise Cloud plan.

To learn more about GitHub Actions Metrics, check out our public documentation or head to our community discussion to ask questions and provide feedback.

See more

GitHub Copilot Metrics API GA release now available

We’re excited to announce the GA release of the GitHub Copilot Metrics API, available to all customers of GitHub Copilot Business and GitHub Copilot Enterprise.

What is the Copilot Metrics API?

The GitHub Copilot Metrics API is designed to supply you with information about Copilot’s usage within your GitHub enterprise, organizations, and teams. The data from the API is intended to be consumed and combined with your organization’s own data to create greater visibility into how Copilot fits into the bigger picture of your software development cycle. It offers visibility into utilization of individual Copilot features and the volume of daily active users.

What’s included in the GA release?

  • New metrics for Pull Request summaries.
  • New metrics for Copilot Chat in GitHub.com.
  • Improved clarity for code completions and Copilot Chat in IDE metrics.
  • Daily summary of total engaged users.
  • Built in support for slicing data on custom models, arriving shortly after release.
  • Aggregation by GitHub enterprise, organization, and team.
  • Up to 28 days of history is available.
  • Metrics are loaded end of day UTC, and are summarized by day.
  • Terminology alignment with the User Management API.

Will my current reporting be impacted?

The GA release of the Copilot Metrics API introduces a newly revised schema. To ensure that your existing reports are not interrupted, the Beta route will remain online through the end of the calendar year.

Documentation and Resources

  • Docs: Explore detailed API documentation, including schema and metrics definitions here.
  • Questions or suggestions? Join the community conversation.
See more
View more changes