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

Following on from our announcement of the end of Node16 support we have a new timeline for Node16 end of life in Actions.

On June 30th 2024, we will change the default from Node16 to Node20.
To opt out of this and continue using Node16 while it is still available in the runner, you can choose to set ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true

We will then continue to monitor Node16 usage and will communicate a timeline for the removal of Node16 at the start of October, based on the volume of continued use. This means that customers who use the environment variable to continue to use Node16 now have until October to complete their migrations.

Join the discussion within GitHub Community.

See more

The GitHub Enterprise Server 3.13 release candidate is here

GitHub Enterprise Server 3.13 gives customers more fine-grained control over deployment requirements, and enhanced security controls. Here are a few highlights:

  • We are introducing a new feature for repositories called custom properties, a major enhancement to how repositories are managed and classified across GitHub organizations. Properties offer a flexible way to add meaningful metadata to your repositories that simplifies repository classification, enhances discoverability, and seamlessly integrates with rulesets. Check out the demo! For more information, see custom properties for repositories.
  • Elasticsearch will be upgraded from version 5 to version 8, when the appliance is upgraded to 3.13. Elasticsearch powers all search experiences in GHES including code search and audit logs. Upgrading ES5 to ES8 allows the platform to take advantage of better performance and improved security posture in ES8. For more information regarding what to expect during ES8 upgrade, see Preparing for Elasticsearch upgrade in GHES 3.13. Downnload the 3.13 RC candidate now, upgrade your staging environment and share your feedback with us!

  • Enterprise and organization audit log events now include the applicable SAML and SCIM identity data associated with the user. For more information, see Reviewing the audit log for your organization.

  • Developers who use devcontainer.json files to define their development containers will now be able to use Dependabot version updates to keep their dependencies in the container up-to-date. Once configured in dependabot.yml, Dependabot will open PRs on a specified schedule to update the listed dependencies to latest.

  • Pull Requests rebases are now faster! Under the hood, rebase commits now use the merge-ort. Rebases that timed out for large repositories before are now a lot more likely to be successful.

  • Using Project Status Updates, you can now provide high level details on the status, timing, and progress of your project, directly from the project! This makes it easy to know and share with others how your work is progressing, any risks, and a history of when and why something changed, all in the same place where you’re tracking your work.

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.

Read more about GitHub Enterprise Server 3.13 in the release notes,
or download the release candidate now.
If you have any feedback or questions, please contact our Support team.

See more

Updating our announcement we made on the 16th of April, we have a new timeline for the removal of multi-labels for larger runners.

Brownouts will now be run on the 29th of May.
Customers will then no longer be able to use multiple labels or target non-name labels on larger runners after the 17th of June.

To prepare for this change and avoid any disruption, please ensure the runs-on: references only the runner name in your workflows prior to the dates above.

Join the discussion within GitHub Community.

See more

The enterprise support portal at https://enterprise.githubsupport.com/ has been deprecated since November 1, 2021. However, it has continued to remain accessible to view past tickets. That is now changing. In order to streamline your support experience, we are going to turn the portal off and it will no longer be accessible after May 31st, 2024.

Action required: If you have used this portal to reference old tickets not available on support.github.com, we recommend that you copy any important information from those tickets to another location before the end of this month.

You must visit support.github.com with a support entitled account to open new support tickets about your GitHub enterprise cloud account.

See more

We are happy to announce the beta release of the Ubuntu 24.04 image for GitHub Actions hosted runners. To start using this in your Actions workflows, update your workflow file to include runs-on: ubuntu-24.04

jobs:
  build:
    runs-on: ubuntu-24.04
     steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g bats
      - run: bats -v

Some users may notice differences in workflows as the Ubuntu 22.04 image has different tools and tool versions, see the full list of changed software.

If you spot any issues with your workflows when using Ubuntu-24.04, or if you have feedback on the software installed on the image, please let us know by creating an issue in the runner-images repository.

While the runner image is in beta, you may experience longer queue times during peak usage hours.

See more

We’re excited to announce that the dependabot-core project is being relicensed under the MIT License, making it easier for the community to contribute to Dependabot.

Keeping dependencies updated is a crucial part of securing your software supply chain, and Dependabot has been helping GitHub users do this since 2019. It’s used by millions of developers each month to keep their dependencies up-to-date and free of known security vulnerabilities. We don’t charge anyone to use Dependabot, because we think everyone should be able to use open source without fear of vulnerabilities.

dependabot-core is the component of Dependabot that defines the logic to create pull requests for dependency updates across the 20+ languages and package managers it supports today. The update logic in dependabot-core is tightly integrated with the rest of GitHub’s Dependabot features, such as grouped updates and auto-triage rules, and contributions from collaborators have helped with its support of Swift and improvements to NuGet. By adopting the MIT license, we will simplify the process for members of the community to contribute to Dependabot and innovate together.

Dependabot-core was previously available under the Prosperity Public License 2.0, and has received contributions from more than 300 developers over the past few years. Now, the MIT license will make it easier than ever for members of the community to join our cause to improve the security of all the world’s software. If you’d like to learn more about contributing to dependabot-core, please check out the repository, and drop us an issue or pull request!

See more

We’ve updated how we calculate Last Activity to give you better clarity and are pausing access to the Team endpoint in the Metrics API.

Updating the Last Activity calculation

Ahead of the GitHub Copilot Metrics API launch, we made an update to how we calculate Last Activity in order to provide more useful information for admins. Previously, this data point indicated the last time a user generated a Copilot authentication token, which happened automatically if the user’s editor was active. This did not mean the user was engaging with Copilot but rather, the extension was ensuring it could provide completions or chat access if needed.

To align this data point with actual usage, we updated our system to grab the most recent instance where the user deliberately engaged with the Copilot system. These actions include but are not limited to:
– Code completion suggestions show
– Chatting with Copilot Chat in IDEs
– Creating or updating a knowledge base
– Creating a pull request summary
– Interacting with Copilot on GitHub.com

As part of this update, we also needed to perform system cleanup on the vast amount of previous token generated events that were no longer relevant to providing this data point. Some data was erroneously removed but has since been restored.

The Last Activity date should be consistent across the CSV generated via Get Report in Copilot Access settings as well as through the Seats Management API.

Pausing access to Team slicing in the GitHub Copilot Metrics API.

Based on trends in feedback, the product team has learned that the Teams route of the Metrics API returns data that is not meeting the goals of our intended customer experience. In light, they have made the decision to temporarily pull the Teams route from production as of May 9th, 2024. During this time, the team will implement a collection of fixes intended to improve end users’ data experience and plan to re-enable the route by the end of June, at latest.

We understand this may be disappointing but the team is working to restore access as soon as possible. You can provide feedback and follow along for updates via this Discussion.

See more

The new Tool group-by option on the security overview trends graph provides a visualization of alert trends, organized by the security tools that detected each vulnerability. It’s designed to improve your ability to track and analyze the effectiveness of your scanning tools, enabling more strategic decision-making.

Example of the alert trends chart grouped by security tool

With this new functionality, you can:
* Pinpoint which tools are detecting the most critical vulnerabilities.
* Monitor the performance of your scanners over time.
* Prioritize your remediation efforts based on detailed insights.

To access this feature, navigate to the Security tab at the organization level on GitHub, and choose the Tool option in the Group by dropdown.

This functionality is now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.14.

Learn more about the security overview dashboard for your organization and send us your feedback

See more

We’ve simplified the signup flow to make it easier for maintainers to join Sponsors. If you’re in a supported region, your profile will be accepted immediately.

If you live in a region that isn’t already supported by GitHub Sponsors, you can sign up for the waitlist to participate in GitHub Sponsors. For a list of supported regions, see GitHub Sponsors.

Haven’t signed up for GitHub Sponsors yet? Join now at GitHub Sponsors.

See more

Azure private networking was made generally available in April 2024 with 11 available regions. GitHub Actions has expanded the number of supported regions to 17, with the following new additions:

  • Germany West Central
  • Sweden Central
  • North Central US
  • South Central US
  • West US 3
  • Japan East

Azure private networking is available for GitHub Enterprise Cloud & Team plans. For the entire list of supported regions, see our documentation. If your desired region is not currently available, please use this form to submit a region request.

To start using Azure private networking for Actions, follow this guide to walk you through configuring Azure resources and creating an Actions network configuration.

See more

Secret scanning is expanding coverage for push protection to repository file uploads made via a browser. If push protection is enabled for a repository, secret scanning will now also block contributors from uploading files with detected secrets.

Learn more about push protection or sign up for a 60 minute feedback session on secret scanning and be compensated for your time.

See more

When uploading a SARIF file that contains multiple SARIF runs for the same tool and category,
Code Scanning combines those runs into a single run.

Combining multiple runs within the same SARIF file is an undocumented feature that was originally intended to simplify uploading multiple analyses for the same commit. Since then, we have introduced the explicit concept of category to be able to upload multiple analysis for the same commit, thus better aligning with the SARIF Specification.

Today, we are starting the deprecation path for the combination of multiple SARIF runs with the same tool and category within the same file. Specifically, in the next few days, the github/codeql-action/upload-sarif action will start showing a deprecation warning when using 3rd party tools that rely on the combination of multiple SARIF runs with the same tool and category within the same file. While showing the deprecation warning, the upload of the SARIF file will succeed.

We expect to fully stop combining multiple SARIF runs with the same tool and category within the same file in June 2025 (for github.com) and in GHES 3.18, at which point the upload of the SARIF file will fail.

How does this affect me?

You are affected if you are using the github/codeql-action/upload-sarif action to upload results from a 3rd party Code Scanning tool and the tool generates multiple runs with the same category in a single SARIF file.
If that is the case, you will start seeing the deprecation warning, and you should work with the tool provider so that each run in the SARIF file has a distinct tool or category.

You are affected if you are using github/codeql-action/upload-sarif action to upload multiple SARIF files from a 3rd party tool. You can end up with multiple SARIF files if the tool either generates multiple SARIF files itself or if you are using a matrix build to run multiple analyses. Specifically, if you are doing a matrix build that generates multiple SARIF files and have a dedicated job to upload all the SARIF files together. For example, your workflow might look like the following if you analyze two apps using a matrix build but then have a dedicated upload job to upload all the SARIF files together:

jobs:
  analyze:
    ...
    strategy:
      matrix:
        app: ['app1', 'app2']

    steps:
    - name: SAST Scan
      ...

    - name: Temporary store SARIF file
      uses: actions/upload-artifact@v4
      with:
        name: sarif-${{ matrix.app }}
        path: "results"

  upload:
      name: Upload SARIF
      needs: analyze
      steps:
      - name: Fetch SARIF files
          uses: actions/download-artifact@v4
          with:
          path: ../results
          pattern: sarif-*
          merge-multiple: true

      - name: Upload Results
          uses: github/codeql-action/upload-sarif@v3

In this case, you need to make the call to the github/codeql-action/upload-sarif action to include a distinct category. For example, you can embed the step in the matrix job and use the matrix variables to generate a unique category. In this way, the example above becomes:

jobs:
  analyze:
    ...
    strategy:
      matrix:
        app: ['app1', 'app2']

    steps:
    - name: SAST Scan
      ...

    - name: Upload Results
      uses: github/codeql-action/upload-sarif@v3
      with:
        category: ${{ matrix.app }}

Note that changing the value of the category causes older alerts to remain open, and you might want to delete the configuration using the previous category value.

You are not affected if you are only using CodeQL via the github/codeql-action action. For the few repositories that rely on this behavior, the CodeQL CLI (starting version 2.17.0) includes backwards compatible logic.

You are not affected if you are uploading multiple SARIF files for the same commit using one of the documented approaches.

What’s next?

In June 2025, SARIF uploads to github.com that contain multiple runs with the same tool and category will be rejected.

See more

Guest Collaborators for GitHub Enterprise Cloud EMUs are now generally available. Originally announced in public beta at the end of last year, this feature allows an identity provider to assign the guest collaborator role to a user which will restrict that user’s default access to internal repositories.

Our thanks go to the thousands of public beta participants that guided our hand to the GA experience. By popular request, today we also released a public beta for repository collaborator access in EMU enterprises! This brings the “outside collaborator” access style to EMUs, limited to selecting users that are members of the enterprise account. Combining these two features together lets you grant the most granular possible access rights to specific repositories and organizations that fit your needs for contractors and other limited access use cases.

Learn more about guest collaborators

See more

Enterprise Managed Users can now be added directly to a repository in their enterprise as a collaborator, without becoming a member of the organization. These users function like outside collaborators, with a few differences:
1. Only user accounts from within the enterprise can be added to the repository. This means that users you want to collaborate with must still come from your linked identity provider (IDP).
2. EMU users can only be collaborators on repositories in their enterprise. EMU accounts cannot collaborate outside their enterprise.
3. Repo Collaborator invitations can only be sent by an EMU’s enterprise owner by default, while in non-EMU enterprises and organizations both enterprise and organization owners can manage outside collaborators.

Like outside collaborators – users do not have to SSO authorize their credentials in order to access repositories that they have been granted access to as a repository collaborators. This aligns to the current access model for internal repositories on GitHub.

You can try out repository collaborators by going to the repository policies section of your Enterprise settings and selecting which tiers of administrators are allowed to invite collaborators.

For more information about repository and outside collaborators, see “Roles in an organization“.

See more

Previously, developers who used private registries to host their packages on internal networks could not use Dependabot to update the versions of those packages in their code.

With this change, users can choose to run Dependabot pull request jobs on their private networks with self-hosted GitHub Actions runners, allowing Dependabot to access on-premises private registries and update those packages.

A prerequisite for enabling self-hosted runners includes enabling GitHub Actions for the repositories of interest. It’s important to note that running Dependabot does not count towards GitHub Actions minutes – meaning that using Dependabot continues to be free for everyone.

To get started, check out our documentation on managing self-hosted runners with Dependabot Updates.

If you’re interested in learning more about what it means to run Dependabot as a GitHub Actions workflow, check out our changelog and FAQ or Dependabot on Actions documentation.

See more

Create a tamper-proof papertrail for anything you build on Actions

Artifact Attestations lets you sign builds in GitHub Actions, capturing provenance information about the artifact and making it verifiable from anywhere. There are no keys or PKI to manage, and verification happens with the GitHub CLI tool. The solution is based on Sigstore, an open source project that simplifies signing for software artifacts.

To add provenance to a GitHub Actions workflow, you just need to invoke the new attest-build-provenance Action with the path to an artifact. Here’s a simple example:

permissions:
  id-token: write
  contents: read
  attestations: write

#
# (build your artifact)
#

- name: Generate artifact attestation
  uses: actions/attest-build-provenance@v1
  with:
    subject-path: 'PATH/TO/ARTIFACT'

Then verify it with the CLI tool:

gh attestation verify PATH/TO/ARTIFACT -o myorganization

To learn more check out the blog and join the discussion in the GitHub Community.

See more

Developers of GitHub Apps can simplify their application by using the client ID for both OAuth flows and the installation token flow.

To date, GitHub Apps have had two different IDs to manage – the application ID and the client ID. The application ID was only used to mint a JWT, subsequently used to fetch an installation token. The client ID is used with the OAuth flow to sign in users and request installations. These two values equally identify the application and the question of which one to use where caused unnecessary developer friction. You can now use the client ID in the place of the application ID when minting JWTs.

The application ID is not being deprecated at this time, nor are their plans to remove it. However, compatibility with future features will rely on use of the client ID, so updating is recommended.

The specific change allowed here is that when minting the JWT that proves your app is in posession of an application’s private key, you can use the client ID for the iss claim. Note that application IDs are ints, while client IDs are strings, if using a typed language.

require 'openssl'
require 'jwt'  # https://rubygems.org/gems/jwt

# Private key contents
private_pem = File.read("YOUR_PATH_TO_PEM")
private_key = OpenSSL::PKey::RSA.new(private_pem)

# Generate the JWT
 payload = {
 # issued at time, 60 seconds in the past to allow for clock drift
  iat: Time.now.to_i - 60,
  # JWT expiration time (10 minute maximum)
  exp: Time.now.to_i + (10 * 60),
--- # GitHub App's App ID
--- iss: "12345"
+++ # GitHub App's Client ID
+++ iss: "Iv23f8doAlphaNumer1c"
}

jwt = JWT.encode(payload, private_key, "RS256")
puts jwt

Note that Octokit still expects the use of the App ID in its setup – the Octokit SDK will be updated in the future to support use of the client ID.

You can find the client ID for your application in its settings page:

A screenshot of an app's settings, showing both the client ID and the application ID

Client IDs and application IDs are not secrets, and are expected to be visible to the end user – you do not need to change how you handle your IDs when making this update.

For more information about minting JWTs to get an installation token, see ‘Generating a JWT for a GitHub App’.

See more

GitHub’s audit log streaming health check is now generally available! The purpose of the audit log health check is to ensure audit log streams do not fail silently. Every 24 hours, a health check runs for each stream. If a stream is set up incorrectly, an email will be sent to the enterprise owners as notification that their audit log stream is not properly configured.

Example email notification for misconfigured stream

Streamed audit logs are stored for up to seven days on GitHub.com. To avoid audit log events being dropped from the stream, a misconfigured stream must be fixed within six days of email notification. To fix your streaming configuration, follow the steps outlined in “Setting up audit log streaming.”

See more