Skip to content

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

macOS 14 (Sonoma) is generally available and the `latest` macOS runner image

macOS 14 (Sonoma) is now generally availaile. Over the next 12 weeks, jobs using the macos-latest runner label will migrate from macOS 12 (Monterey) to macOS 14 (Sonoma). During migration, you can determine if your job has migrated by viewing the Runner Image information in the Set up job step of your logs. This announcement also applies to larger macOS runners, for which the following runner labels can be used:

  • macos-latest-xlarge
  • macos-latest-large 
jobs:
  build:
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: swift build
      - name: Run tests
        run: swift test

To use macOS 14 directly, update runs-on: in your workflow file to macos-14, macos-14-xlarge, or macos-14-large:

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: swift build
      - name: Run tests
        run: swift test

The macOS 14 runner image has different tools and tool versions than macOS 12. See the full list of changed software.

Please note that once your workflows run on macOS 14 using latest they will not revert to run on older image versions. If you spot any issues with your workflows when using macOS 14, please let us know by creating an issue in the runner-images repository.

See more

GitHub Education Redesign

New GitHub Education user experience image

GitHub Education is excited to announce the launch of our redesigned experience for Learners! Our goal was to enhance the GitHub Education experience, with a focus on learning new skills, finding opportunities, and helping Learners connect and build their network.

The redesign promotes user-friendliness, accessibility, and intuitive navigation, to provide Learners with the ability to find the resources they need to pursue a career in tech.

You can explore the new design at https://education.github.com/ and share your feedback with us on the GitHub Community Discussions.

Not a GitHub Education Learner yet? Join now at https://education.github.com/discount_requests/application.

See more

Updated GitHub App visibility for Enterprise Managed Users

We’ve clarified the GitHub App creation experience for Enterprise Managed Users (EMUs), updating it for both users and organizations that would like to create an app.

GitHub Apps created within an EMU enterprise are only accessible within the enterprise – they’re blocked for anyone else. In addition, EMU user accounts are unable to install GitHub applications.

To reflect this limitation, we’ve updated the creation UI to disable the “Private” option for EMU users, which prevents users from creating apps that no one can install. We’ve also updated the “Public” option to instead read “This enterprise”, more accurately reflecting where the app can actually be installed.

image

For more information about EMUs, see “About Enterprise Managed Users“. For more about GitHub Apps, see “About GitHub Apps“.

See more

SSH CA support for enterprise-owned user accounts

Enterprises that own their user accounts can now use SSH CAs to access user-owned repositories. This is an optional setting that enterprises can enable in their enterprise SSH CA settings page. Enabling this setting allows developers to use a single SSH certificate for all of their interactions with GitHub across their user account’s repositories and their enterprise’s repositories.

This is available now for customers using Enterprise Managed Users in GHEC, and will be included in GHES 3.14. It is not available to GHEC Classic enterprises, where developers bring their own personal accounts to the enterprise; the enterprise does not own those accounts and cannot gain access to their repositories.

For more about SSH certificate authorities, see “Managing SSH certificate authorities for your enterprise“.

See more

GitHub Copilot Enterprise – March 2024 update

GitHub Copilot Enterprise banner

It’s been a little over a month since GitHub Copilot Enterprise became generally available. Check out what’s new below!

Enhanced contextual understanding and more relevant suggestions in GitHub.com

Copilot Chat in GitHub.com now uses faster and smarter embedding models to power content retrieval, giving Copilot higher quality and more relevant context when searching code and knowledge bases.

Copilot Chat in GitHub.com now knows about the programming languages used in the repository you’re looking at: Copilot could sometimes give answers based on a programming language not used by your project. Copilot now knows what programming languages a repository uses, so it can give code examples more tailored to your context.

Faster help with understanding pull request changes

It’s now easier to ask Copilot about the changed files in a diff: From the files changed view, you can now pick the files you’re most interested in asking Copilot about.

GitHub Copilot in Pull Request files changed view

You can also now ask Copilot about specific lines in a diff more easily by clicking on the Copilot icon when you hover on a line of code.

GitHub Copilot icon when hovering on a line in a diff

Usability improvements

A big thank you to all of our customers for the great feedback you’ve been providing. We’ve made a whole bunch of small fixes, including:

You can now start typing your next question to Copilot while the current response is still generating: Previously you had to wait for Copilot’s message to complete generating before a follow-up question could be composed.

Keyboard up/down arrows can now be used to cycle through past messages: Perhaps you want to ask a similar question from earlier in the conversation history? Hitting the up key on your keyboard will now enable you to cycle through previous messages.

Copilot Chat in GitHub.com now has better support for Japanese and Chinese characters: Previously the message could be submitted to Copilot after the IME conversion selection but before the user was ready to send the message to Copilot.

See more

Actions Usage Metrics public beta

Customers desire clear, relevant, and actionable insights about how Actions workflows are being used in their organization. Today, we are thrilled to announce that Actions Usage Metrics is available in public beta for GitHub Enterprise Cloud plans.

Actions Usage Metrics screenshot

Time is the most important metric for DevOps and DevEx teams. The question they want answered is, “where are all my minutes going?” Actions Usage Metrics addresses this question and others by focusing on minutes used per workflow, job, repository, runtime OS, and runner type. This data helps organizations locate areas of improvement in their software delivery lifecycle, saving time and money.

Customers can filter data by any combination of workflows, jobs, repositories, runtime OS, and runner type to view total minutes, number of jobs, workflow executions, and more. All usage metrics, filtered or not, can be downloaded as a .csv file to use with your tool of choice.

By default, organization owners can access Actions Usage Metrics. However, access permissions can be granted to other members or teams using Actions fine-grained permissions. This ensures the right level of access to Actions Usage Metrics data, enabling informed decisions and improvements.

To learn more about Actions Usage Metrics, check out our docs or head to our community discussion.

See more

Dependabot grouped security updates generally available

Dependabot grouped security updates are now generally available. This feature automatically groups Dependabot pull requests, lets you specify several additional options to fine tune your groupings.

You can enable grouped security updates for Dependabot at the repository or organization-level. To enable this feature, go to your repository or organization settings page, then go to the Code security and analysis tab, and click “Enable” for grouped security updates (this also requires each affected repository to enable Dependency graph, Dependabot alerts, and Dependabot security updates). When you enable this feature, Dependabot will collect all available security updates in a repository and attempt to open one pull request with all of them, per ecosystem, across directories.

If you would like more granular control over Dependabot’s grouping, you can also configure the dependabot.yml file in a repository to group by any of the following:

  • Package name
  • Dependency type (production vs development)
  • Semver update level (patch, minor, major)

For additional information, check out the Dependabot configuration file documentation.

For GitHub Enterprise Server users, grouped security updates will be available in Version 3.14.

See more

Mergify is now a GitHub secret scanning partner

We have partnered with Mergify to scan for their tokens to help secure our mutual users in public repositories. Mergify’s API key enables users to interact with Mergify’s API in order to retrieve information on their merge queues. GitHub will forward any exposed API keys found in public repositories to Mergify, who will then revoke the key and notify the key owner. Read more information about Mergify API keys.

GitHub Advanced Security customers can also scan for and block Mergify tokens in their private repositories.
– Learn more about secret scanning
– Partner with GitHub on secret scanning

See more

Volcengine is now a GitHub secret scanning partner

GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, we help protect users from data leaks and fraud associated with exposed data.

We have partnered with volcengine to scan for their access tokens, which are used for cloud computing services. We’ll forward access tokens found in public repositories to volcengine, who will notify the user by email without making any changes to the tokens. Users can request support for their volcengine API tokens.

We continue to welcome new partners for public repository secret scanning. GitHub Advanced Security customers can also scan their private repositories for leaked secrets.
– Learn more about secret scanning
– Partner with GitHub on secret scanning

See more

Lightspeed is now a GitHub secret scanning partner

GitHub secret scanning protects users by searching repositories for known types of secrets such as tokens and private keys. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with Lightspeed to scan for their tokens to help secure our mutual users in public repositories. Lightspeed Retail Personal Tokens enable users to interact with Lightspeed Retail POS programmatically. Read more information about Lightspeed tokens.

GitHub Advanced Security customers can also scan for and block Lightspeed tokens in their private repositories.

See more

WorkOS is now a GitHub secret scanning partner

GitHub secret scanning protects users by searching repositories for known types of secrets such as tokens and private keys. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with WorkOS to scan for their tokens to help secure our mutual users in public repositories. WorkOS’ API key enables access to WorkOS’ API for adding Enterprise Ready features to your application. GitHub will forward any exposed API keys found in public repositories to WorkOS, who will then notify admin users on your WorkOS account. Read more information about WorkOS API keys.

GitHub Advanced Security customers can also scan for and block WorkOS tokens in their private repositories.

See more

CodeQL can scan Java projects without a build

With the 2.16.5 release of CodeQL, we’re introducing a new mechanism for creating a CodeQL database for Java codebases, without relying on a build. This enables organizations to more easily adopt CodeQL for Java projects at scale. Note: this release announcement contains details for users of the CodeQL CLI and advanced setup for code scanning. If you’re using GitHub code scanning default setup (which is powered by the CodeQL engine), this related release announcement will likely contain the information you’re looking for.

Previously, CodeQL required a working build to analyze Java projects. This could either be automatically detected or manually specified. Starting with CodeQL 2.16.5, you can now scan Java code without the need for a build. Our large-scale testing has shown that CodeQL can be successfully enabled for over 90% of Java repos without manual intervention.

This feature is currently in public beta and is accessible to all GitHub.com advanced setup for code scanning and CodeQL CLI users scanning Java code:

  • Repositories using advanced setup for code scanning via workflow files will have the option to choose a build-mode. The default value for newly configured Java repos will be build-mode: none.

  • CodeQL CLI users will not experience any change in the default behaviour, for compatibility with existing workflows. Users that want to enable this feature can now use the --build-mode none option. Generally, we also recommend users set the --build-mode option when using the CLI to make it easier to debug and persist the configuration should default behaviour change at any point in the future.
    codeql database create test_no_build_db --language java --build-mode none

  • Repositories containing a mix of Kotlin and Java code still require a working build for CodeQL analysis.

The new mechanism for scanning Java is available on GitHub.com and in CodeQL CLI 2.16.5. While in public beta, this feature will not be available on GitHub Enterprise Server for default setup or advanced setup for code scanning. As we continue to work on scanning Java projects without the need for working builds, send us your feedback.

See more

Improvements to security overview insights, secret scanning metrics

Today, we’re releasing a host of new insights to the security overview dashboard, as well as an enhanced secret scanning metrics page.

New dashboard insights

overview dashboard with third-party tools, the trend indicator for age of alerts, and reopened alerts tile highlighted

  • Third-party alerts integration: Beyond GitHub’s own CodeQL, secret scanning, and Dependabot security tools, you can now view alert metrics for third-party tools directly on the overview dashboard. Use tool:[third-party-tool name] to view metrics for a specific third-party security tool, or tool:third-party to view metrics for all third-party security alerts.
  • Reopened alerts tracking: Uncover recurring vulnerabilities with the new reopened alerts metric tile, which identifies vulnerabilities that have resurfaced after being previously resolved. This data point helps assess the long-term effectiveness of your remediation efforts.
  • Trend indicators: Review changes over time with trend indicators for key metrics like age of alerts, mean time to remediate, net resolve rate, and total alert count. These indicators offer a clear view of performance shifts and trends between a given date range and that same range reflected backward in time.
  • Advisories tab: Stay informed with the new advisories table, which details the top 10 alert advisories affecting your organization, including the advisories’ CVE IDs, ecosystems, open alert counts, and severities.

Secret scanning metrics page enhancements

secret scanning metrics page with filter bar highlighted

You can now refine your insights with filters for dates, repository custom properties, teams, and more on the secret scanning metrics page. These new filters empower you to pinpoint specific repositories and view changes over time, enabling a more targeted analysis. Additionally, if you are an organization member, you can now view metrics for the repositories you have access to.

These features are now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.13.

Learn more about security overview and send us your feedback

See more

GitHub Copilot General Availability in the CLI

GitHub Copilot in the CLI banner demonstrating "ghcs" alias for supporting command execution

GitHub Copilot in the CLI is now generally available

We are excited to announce Copilot in the CLI is now generally available (GA) for all our Copilot Individual, Business, and Enterprise customers.

Copilot in the CLI allows users to access the power of GitHub Copilot to get command suggestions and explanations without leaving the terminal. Starting today, developers can also use GitHub Copilot to execute suggested commands based on feedback shared during the public beta.

GitHub Copilot in the CLI has also gained a couple of helper aliases for Bash, PowerShell, and Zsh. The new gh copilot alias command generates shell-specific configuration for ghcs and ghce aliases. These aliases use fewer keystrokes to jump into the gh copilot experience. Additionally, the new ghcs alias streamlines the process for executing commands suggested while making them available for later reuse!

How to get started?

If you were already using Public Beta:

  • Update the extension to v1.0.0 by running gh extension upgrade gh-copilot.

If you haven’t enabled Copilot in the CLI yet or coming from the GitHub Next technical preview

  • Copilot Individual users: You automatically have access to the Copilot in the CLI.
  • Copilot Business and Enterprise users: Your organization admins will need to grant you access to Copilot in the CLI.

After receiving access to Copilot in the CLI, consult our guide on how to install the tool and get started.

How to give us your feedback?

We are dedicated to continuous improvement and innovation. Your feedback remains a crucial part of our development process, and we look forward to hearing more about your experiences with GitHub Copilot in the CLI. Please use our public repository to provide feedback or ideas on how to improve the product.

See more

Java projects no longer require a build when using code scanning via default setup

CodeQL, the static analysis engine that powers GitHub code scanning, can now analyze Java projects without needing a build. This enables organizations to more easily roll out CodeQL at scale. This new way of analyzing Java codebases is now enabled by default for GitHub.com users setting up new repositories with default setup for code scanning.

Previously, CodeQL required a working build to analyze Java projects. This could either be automatically detected or manually specified. By removing that requirement, our large-scale testing has shown that CodeQL can be successfully enabled for over 90% of Java repos without manual intervention.

This feature is currently in public beta and is accessible to all users scanning Java code using default setup for code scanning on GitHub.com:

  • Anyone setting up their repo using code scanning default setup will automatically benefit from this new analysis approach.
  • Repositories containing a mix of Kotlin and Java code still require a working build for CodeQL analysis. CodeQL will default to the autobuild build mode to automatically try and detect the right build command.
  • Repositories with an existing code scanning setup will not experience any changes. If code scanning is working for you today it will continue to work as-is, and there is no need to change your configuration.

GitHub.com users using advanced setup for code scanning and users of the CodeQL CLI will be able to analyze Java projects without needing a working build as part of CodeQL CLI version 2.16.5. While in public beta, this feature will not be available for GitHub Enterprise Server. As we continue to work on scanning Java projects without needing a working build, send us your feedback.

See more

Security overview dashboard: Alert age trends, custom repository and severity filters, and date pickers

Starting today, you can take advantage of the new “age” grouping for the alert trends graph and explore enhanced filter options on the security overview dashboard, aimed at improving your analytical process and security management.

alert trends grouped by age

Explore the dynamics of your security alerts with the new alert age grouping on the alert trends graph. This new functionality offers a refined view into the lifecycle of your security alerts, enabling you to better evaluate the timeliness and effectiveness of your response strategies.

New filter options

repository custom property filter on the security overview page

Leverage enhanced filters to fine-tune your security insights on the overview dashboard:
* Custom repository property filters: With repository custom properties, you can now tag your repositories with descriptive metadata, aiding in efficient organization and analysis across security overview.
* Severity filters: Severity-based filters allow you to concentrate on the vulnerabilities that matter most, streamlining the process of security risk assessment and prioritization.
* Improved date picker controls: Navigate through time with ease using the new date picker options, allowing for quick selection of rolling periods like “Last 14 days,” “Last 30 days,” or “Last 90 days.” Bookmark your preferred time window to keep your analysis current with each visit.

You can access these new functionalities in security overview by navigating to the “Security” tab at the organization level.

These features are now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.13.

Learn more about security overview and send us your feedback

See more

New SSH CAs must sign expiring certificates

SSH CAs uploaded to GitHub.com after March 27th, or in GHES 3.13 and beyond, can only sign certificates that expire. They must expire within 366 days of being created.
While expirations on certificates are not required by signing tools such as ssh-keygen, we are enforcing this best practice in order to protect against a weakness in how SSH certificates are linked to users.

CAs uploaded before the cutoff date or release will be marked in the UI as being allowed to sign non-expiring certificates:

image

An “upgrade” option on the CA lets you enforce expiration of signed certificates. Once you’ve validated that you are indeed using a lifetime on your certificates, we recommend upgrading your CAs. This upgrade step is irreversible, and new CAs cannot be downgraded to allow non-expiring certificates.
If a certificate is signed with no expiration, or a too-long expiration, it will be rejected during SSH connection with an error indicating The SSH certificate used was issued for a longer period than allowed.

This change forces the valid_after issuance timestamp to be written to the certificate, which allows GitHub to detect if the user changed their username after the certificate was issued for that username. This prevents a reuse attack vector where the former holder of a username is able to use certificates issued to them to sign in as the new holder of that username.

To learn more about managing SSH CAs, see “Managing your organization’s SSH CAs” and “Managing SSH CAs for your enterprise.” For information on using SSH CAs, see “About SSH CAs.”

See more

Improved error handling for Dependabot updates for NuGet

Dependabot will now fail gracefully with informative error messages when an unsupported NuGet project type is encountered. If you were using an unsupported project type previously, Dependabot might have failed silently without producing updates. Dependabot is able to process updates to NuGet project files in the .csproj, .vbproj, and .fsproj formats.

See more

OpenSSF Scorecard info is now available in the Dependency Review Action

Dependency review helps you understand dependency changes and the security impact of these changes at every pull request. We have updated the dependency review action to include information from the OpenSSF Scorecard project into the review, helping you better understand the security posture of the dependencies that you’re using.

See more
View more changes