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

Copilot Chat in JetBrains IDEs is now available in Private Beta

We are happy to announce that a private beta of GitHub Copilot Chat is now available for users of JetBrains IDEs, including IntelliJ, PyCharm, WebStorm, Android Studio, and more.
GitHub Copilot Chat is a powerful AI-assistant capable of helping every developer build at the speed of their minds in the natural language of their choice.

This private beta is available to Copilot Business customers and Copilot Individual users.

To get access to the private beta, sign up for this waitlist.

GitHub Enterprise Cloud (GHEC) administrators interested in participating in the private beta should reach out to your GitHub account manager or contact our sales team to make the feature available for your enterprise.

We’d love your feedback on this new release. Please use this link to share your feedback or ideas on how to improve the product.

Copilot Chat in IntelliJ

A new Copilot welcome guide is available for JetBrains IDEs

We recently introduced a new welcome guide in our Copilot for JetBrains IDEs extension. Now you will be guided through the various features of GitHub Copilot and how to make the most of it!

Copilot welcome guide in IntelliJ

The welcome guide will activate when you install the GitHub Copilot plugin.

See more

Secret scanning will now detect the following non-provider patterns:

  • HTTP basic authentication header
  • HTTP bearer authentication header
  • MongoDB connection string
  • MySQL connection string
  • Postgres connection string
  • OpenSSH private key
  • PGP private key
  • RSA private key

Detection of these patterns must be enabled within a repository or organization’s security settings by checking the box next to “Scan for non-provider patterns.” Resulting secrets will appear in a new, separate tab on the secret scanning alert list called “Other.”

screenshot of secret scanning alerts showing a tab called Other with alerts for five non-provider patterns

Detection of non-provider patterns is currently in beta and is available for enterprises with a GitHub Advanced Security license only. Additional patterns will be added throughout the beta.

See more

Subversion brownouts

As announced earlier this year, GitHub is removing support for the Subversion protocol. Before permanent removal, we're running two brownouts where we will temporarily disable Subversion support.

Those brownouts are scheduled for:

  • An 8 hour period on November 13, 2023, from 14:00 – 22:00 UTC / 7:00am – 3:00pm Pacific
  • A 24 hour period beginning December 5, 2023 at 10:00 UTC / 2:00am Pacific and ending at the same time on December 6

As a reminder, Subversion support will be permanently removed on January 8, 2024.

See more

GitHub.com now remembers multiple accounts in your browser. You can find the account switcher in your profile picture context menu, letting you more easily switch between user accounts without re-entering your credentials.

image

The account switcher helps developers alternate between Enterprise Managed User accounts provided by an employer and personal accounts for use with personal projects and open source contributions. It also helps administrators manage service accounts they use for automation and integration purposes.

Because these accounts often have significantly different privileges, there's never any mixing of user permissions between saved accounts. When you visit a page that your current account can't access, you'll see a prompt to switch accounts if you have more than one signed in.

When you switch accounts, you won't need to sign in again or perform 2FA unless the account session has expired. Session expiration occurs after two weeks without activity. SAML/OIDC SSO authorization is also saved for sessions, but often expires every 1 or 24 hours, and may need to be done again before you can access your organization resources.

To learn more, see "Switching between accounts".

See more

GitHub Enterprise Cloud customers with Enterprise Managed Users (EMU) now have access to additional administrative capabilities for SCIM information. Troubleshooting user management at scale can take time and effort. To make this easier on administrators, we have added several new audit log fields, external identity metadata, and a new team membership synchronization status. The audit log field updates include the following:

  • New field external_group.update_display_name: Our logs will now capture and report any changes made to an external group’s display name.
  • New field external_group.add_member: When a team member is added to an external group, this action will be audit logged.
  • New field external_group.remove_member: When a team member is removed from an external group, this action will be audit logged.
  • Enhancements to external_group.update and external_identity.update to ensure consistency whenever an external group or identity is updated.

The SSO page for each user also now includes SCIM metadata for that user in addition to existing SAML metadata. Check out what’s new by filling in this url https://github.com/enterprises/your-enterprise/people/username/sso with your enterprise and a valid username.

Team membership synchronization status checks GitHub’s understanding of identity groups against the current members of linked teams. This allows us to flag mismatches for administrators related to license allocation or other concerns.

image

Learn more about external group audit log fields and troubleshooting EMU team memberships.

See more

Starting today, apps and tokens used to create a release via the REST API endpoint will require the workflow scope or workflows:write permission in certain cases.

The workflow scope or workflows:write will be required when creating a release that targets a commit SHA (target_commitish) that modifies an Actions workflow file and that SHA does not have an existing ref (branch head or tag).

For more details see the REST API documentation or visit the GitHub Actions community if you have any questions.

See more

GitHub Advanced Security users can now filter their secret scanning alerts by validity in the UI at the repository, organization, and enterprise level. Valid statuses are active, inactive, or unknown. Validity checks must be enabled for the repository, organization, or enterprise.

See more

Today we're announcing that Private Networking for GitHub-hosted runners with Azure Virtual Networks (VNET) is now in public beta. This feature allows GitHub Enterprise customers using Azure to integrate their GitHub-hosted runners directly into an Azure VNET under their Azure account.

Key Benefits

What sets this apart is the dual advantage it offers. On one hand, you can continue to enjoy the benefits of GitHub-managed resources. On the other hand, you gain full control over the networking policies applied to those resources. Once your GitHub-hosted runners are connected to your Azure VNET, your Actions workflows can securely access Azure services like Azure Storage and on-premises data sources such as artifactory through existing, pre-configured connections like VPN gateways and ExpressRoutes.

Security is also front and center in this update. Any existing or new networking policies, such as Network Security Group (NSG) rules, will automatically apply to GitHub-hosted runners giving platform administrators comprehensive control over network security.

To further simplify the management of Azure private networking settings across different business units, we're introducing Network Configurations. This feature allows administrators to consolidate various networking settings and assign them to runner groups based on specific operational needs. For example, production-grade runners can be configured with stricter networking policies using a dedicated Azure VNET, as opposed to runners used for testing or staging environments.

image

Starting today, Azure Private Networking and Network Configurations are available in public beta for GitHub Enterprise Cloud users. To get started, navigate to the 'Hosted Compute Networking' section within your Enterprise settings. For more details, consult our documentation.

We're eager to hear your feedback to further improve this feature. Share your thoughts on our GitHub Community Discussion.

See more

Users who are not part of the mandatory 2FA program will now be added to it within 24 hours of creating their first release. In August we expanded the 2FA requirement to include most GitHub.com users that had created a release. Those groups have now completed their 2FA enrollment, but additional developers have since created their first release. They will be added to the 2FA program in the coming days, as will more users over time as they create releases.

Enterprise or organization administrators can learn more about their users' current 2FA requirements by visiting the People page for their enterprise or organization.

To learn more about the 2FA program, see our May 2023 blog post, as well as the “About the mandatory 2FA program” documentation.

See more

We are excited to announce the beta release of Copilot in GitHub Support, a faster way to find answers to your GitHub related questions! In August, we launched the Alpha to a limited number of randomly selected GitHub Enterprise Cloud customers. We have made lots of improvements to the experience since and are excited to welcome more customers into the new experience. Copilot in GitHub Support is now trained on the latest GitHub Enterprise Server documentation in addition to GitHub Enterprise Cloud documentation it was previously trained on.

Initially, we’re offering the Copilot experience to a limited number of randomly selected GitHub Enterprise customers. We hope to continue rolling out the experience to a wider audience over the coming months.

During the beta, GitHub will be reviewing answers provided and collecting feedback from participating customers to improve the accuracy.

Copilot in GitHub Support is part of our ongoing effort to make GitHub the best place for all developers to collaborate, innovate, and ship great software. We believe that Copilot in GitHub Support will enhance your experience and productivity.

We look forward to hearing from you and learning from your feedback.

See more

We are excited to announce a significant update to the comment box used in GitHub issues, discussions, and pull requests, aiming to refine and enhance how you interact and collaborate. This release is a testament to our ongoing efforts to provide an exceptional user experience, making GitHub more intuitive, consistent, and accessible across the platform.

A screenshot of the new comment box

The updated comment box is designed to integrate seamlessly with the existing GitHub environment, ensuring a familiar yet improved experience for all users. Highlights and improvements include:

  • Enhanced User Experience: The newly revamped comment box brings an elevated experience to a wider range of users across various devices. With this update, we've enhanced the responsiveness and streamlined the markup to better accommodate keyboard and screen reader users. This ensures a uniform and smooth user experience across issues, discussions, and pull requests, promoting seamless communication and collaboration.
  • Consistency and Familiarity: Our design philosophy for the new comment box was clear: keep it familiar, make it better. We’ve developed the updated version to closely resemble the original while enhancing it with improved accessibility, consistency, and ease of use across various screen sizes. The transition for you will be smooth, with no disruptions to your workflow.
  • Commitment to Accessibility: This update contributes to our continuous journey to make GitHub more accessible to everyone. The comment box now aligns more closely with our accessibility commitment, enhancing the experience in features such as issues, pull requests, and discussions. Check out our Accessibility Commitment to learn more about how we are making GitHub more inclusive.

We are excited for you to experience the new comment box and we welcome feedback to continue improving GitHub for everyone.

See more

GitHub is introducing GPU hosted runners for GitHub Actions to provide teams working with ML models to have a single platform to build, test and deploy from.

GPU accelerated Builds

GitHub enables teams working with GPU accelerated ML models as part of their applications to fully adopt Actions as their DevOps platform to test and deploy their services. These new runners empower teams working with models such as large language models (LLMs) to run these more efficiently as part of their CI/CD process, empowering teams to do complete application testing, including the ML components, in Actions.

We know that developers and data scientists love GitHub Actions. Data scientists are moving away from ‘working in isolation’ towards a model of ML Ops and trying to understand how this feeds into the wider DevOps practices of their teams.

These runners will be entering private beta in November.

Interested?

Click here to join the waitlist for the private beta.

See more

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 Onfido to scan for their tokens to help secure our mutual users in public repositories. Onfido tokens allow developers to interact with Onfido's API in order to integrate secure and reliable identity verification solutions into their applications and services, helping to enhance user onboarding processes and protect against fraud. GitHub will forward any exposed tokens found in public repositories to Onfido, who will then notify the customer about the leaked token. Read more information about Onfido API tokens.

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

See more

Arm-based hosted runners are coming to GitHub Actions!

Unlock the power of Arm in Actions

By leveraging the power and efficiency of the Arm® architecture, GitHub is offering a new solution that will accelerate software development in GitHub. These new capabilities empower GitHub users to shift-left software development on the Arm architecture across the embedded edge, IoT and cloud infrastructure while providing significant power, performance and sustainability improvements to all users. Developers can now take advantage of Arm hardware hosted by GitHub to build and deploy their release assets anywhere Arm’s architecture is used.

Seamlessly integrated into GitHub Actions, these runners are powered by Arm-based Ampere® Altra® processors. Preloaded with a base image that contains a foundational set of development tools to build upon, these runners are extremely versatile and can handle any embedded software project from key markets such as automotive, IoT and industrial. The benefits do not stop at the embedded edge, as non-embedded, cloud native and everything in between will benefit by reducing their carbon footprint and getting more done within existing budgets.

These runners will be entering private beta in January 2024.

“With Arm-based GitHub-hosted runners, software developers can move faster while taking full advantage of the efficient Arm architecture, from cloud to edge,” said Bhumik Patel, director of software ecosystem development, Infrastructure Line of Business, Arm. “Our partnership with GitHub allows developers to optimize their Arm-based software development workflows and leverage GitHub’s ubiquitous deployment capability to more efficiently deliver code wherever they deploy – all while reducing costs and time to market.”

Interested?
Click here to join the waitlist for the private beta.

See more

The GitHub Advanced Security billing REST API and CSV download now includes the email addresses for active committers. This provides information for insights into Advanced Security license usage across your business. Here is an example response from the GitHub Advanced Security billing REST API:

      "advanced_security_committers_breakdown": [
        {
          "user_login": "octokitten",
          "last_pushed_date": "2023-10-26",
          "last_pushed_email": "octokitten@email.com"
        }

Read more about the GHAS billing API here and the GHAS billing CSV download here.

This is available now on GitHub.com and will ship to GitHub Enterprise Server 3.12

See more

GitHub Advanced Security users can now use the REST API to retrieve the validity status of a secret scanning token and retrieve all tokens of a particular validity status. The API will return the status of the token as of the last validity check. Valid statuses are active, inactive, or unknown. Validity checks must be enabled for the enterprise, organization, or repository.

See more

Starting today, in Actions workflows, the pull_request_target trigger is now supported for repository rulesets that require a successful workflow run. This is in addition to pull_request and merge_group, making pull_request_target the third workflow trigger supported by repository rulesets.

Read our recent general availability announcement to learn more about how organizations can set up policies with repository rules that require a successful workflow run before code can be merged into its repositories.

Learn more in our repository rulesets documentation and don’t forget to ask questions or leave feedback in the community discussion.

See more

Auto-triage rules are a powerful tool to help you reduce alert and pull request fatigue substantially, while better managing your alerts at scale.

What's changing?

Starting today, you can define your own rules to control and enforce Dependabot behaviors across organizations and individual repositories.

  • You can now define which alerts receive pull requests to resolve them, rather than targeting all alerts.
  • You can enable and enforce those Dependabot security update rules across organizations, in addition to individual repositories.
  • You can enable, disable, or enforce how GitHub default rulesets are applied across your organization.
  • You can also now enable and enforce custom auto-dismiss (alert ignore and snooze) rules across organizations.

Dependabot auto-triage rules list

Auto-triage rules are defined by alert targeting criteria, the behaviors you'd like Dependabot to automatically perform for these alerts, as well as how you want the rule to be enabled or enforced across your organization.

Alerts can be targeted based on metadata related to the advisory, dependency, and how it's used. For this public beta, currently supported attributes at the organization level are: severity, scope, package-name, cwe, and ecosystem. At the repository level, you can also target specific manifest files.

Create a stacked Dependabot auto-triage ruleset

For any existing or future alerts that match a custom rule, Dependabot will perform the selected behavior accordingly. You can proactively filter out false positives, snooze alerts until patch release, choose which alerts open Dependabot security updates, and – as rules apply to both future and current alerts – manage existing alerts in bulk.

This feature is free for open source (all public repositories) and available for use in private repositories through GitHub Advanced Security.

Frequently asked questions

Why is GitHub making this change?

At GitHub, we’ve been thinking deeply about how to responsibly address long-running issues around alert fatigue and false positives. Rather than over-indexing on one criterion like reachability or dependency scope, we believe that a responsibly-designed solution should be able to detect and reason on a rich set of complex, contextual alert metadata.

That’s why, moving forward, we’re releasing a series of ships powered by a flexible and powerful alert rules engine. Our first ship – Dependabot presets – leveraged our rules engine with GitHub-curated vulnerability patterns and has helped millions of repositories filter out false positive alerts. Today’s ship exposes our rules engine at the organization and repository levels, so you can create and enforce custom rules, too.

How do I create a rule?

From your organization or repository settings page, admins and security managers can navigate to Code security and analysis settings. Under Dependabot, select Dependabot rules to add or modify your own custom rules or modify GitHub presets.

How do I enforce rules for my organization?

Enforce a Dependabot auto-triage rule

At the organization level, rules can be set with the following states.

State Description
Enabled This rule will be enabled across all eligible repositories in your organization. It will be on by default (new repositories are included). Any individual repository can choose to disable the rule.
Enforced This rule will be enabled across all eligible repositories in your organization. It will be on by default (new repositories are included). Individual repositories cannot override this setting.
Disabled This rule will be disabled and hidden across your organization.

At the repository level, rules can be set to enabled or disabled if they're not enforced.

Which criteria are supported?

Rules can be created across the following attributes:

Attribute Description
severity Alert severity, based on CVSS base score, across the following values: low, medium, high, and critical.
scope Scope of the dependency: development (devDependency) or runtime (production).
package-name Packages, listed by package name.
cwe CWEs, listed by CWE ID.
ecosystem Ecosystems, listed by ecosystem name.
manifest Manifest files, listed by manifest path.

Note: manifest is only available at the repository level.

Target alerts based on attributes

How do I control how Dependabot automatically generates pull requests for alerts?

You can use the alert criteria (above) to indicate which alerts Dependabot will attempt to open pull requests to resolve. To use auto-triage rules with Dependabot updates, you must disable Dependabot's option to always open pull requests to resolve all open alerts from the repository Code security and analysis settings.

How do I control how Dependabot automatically closes or reopens alerts?

Similar to Dependabot pull request rules, you can control how Dependabot filters out false postives (with dismiss indefinitely) or snoozes alerts (with dismiss until patch).

How many custom rules can I create?

At the time of public beta, you can create 20 rules per organization and 10 rules for each repository. Want more? Let us know!

How will this activity be reported?

Auto-dismissal activity is shown in webhooks, REST, GraphQL, and the audit log for Dependabot alerts. Alerts are dismissed without a notification or new pull request and appear as a special timeline event. As these alerts are closed, you’ll still be able to review any auto-dismissed alerts with the resolution:auto-dismissed filter.

Who can create and modify rules?

Auto-triage rules are free for open source repositories. Anyone who can enable Dependabot alerts for a public repository will be able to create custom rules for it. Customers of GitHub Advanced Security can create and manage custom rules across private repositories and at the organization level.

How do I reopen an automatically dismissed alert?

Like any manually dismissed alert, you can reopen an auto-dismissed alert from the alert list view or details page. This specific alert won’t be auto-dismissed again (by any other auto-dismiss rule).

What happens if alert metadata changes or advisory information is withdrawn?

Dependabot recognizes and immediately responds to any changes to metadata which void auto-dismissal logic. For example, if you change the dependency scope and the alert no longer meets the criteria to be auto-dismissed, the alert will automatically reopen.

How do I learn more?

How do I provide feedback?

Let us know what you think by providing feedback — we’re listening!

See more