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

Add repository permissions to custom organization roles

You can now add repository permissions to custom organization roles, granting a specific level of access to all the repositories in your organization.

This builds on the release of organization-wide permission grants in GitHub’s pre-defined organization roles. These updates enable admins to easily scale access management across large teams and organizations.

Creating a custom organization role using the new repository permissions. The role is based on the Write base role, and adds 3 permissions - delete issues, request solo merge, and update repo properties

Using repository permissions in organization roles

Organization roles do not have to contain organization permissions (i.e. read_org_audit_log) in order to include a repository role and permissions (i.e. close_issue). This lets you create your own versions of the pre-defined organization base roles like Write or Triage, assigning those roles to everyone in your organization to ensure a set standard of access that matches your requirements.

A popular use case is to create elevated roles for your on-call rotation. For instance, a role based on Write with the “Jump the merge queue” and “Request a solo merge” repository permissions added so that your on-call team can get that fixed quickly. Using the APIs you can automate assignment of this role to your current on-call, granting them those elevated permissions as a break-glass or shift-based privilege.

Managing repository access

Both the UI for organization role creation and the REST API have been updated to support repository permissions.

In addition, we’ve updated the repository access management page to distinguish between access granted by the repository owner to a user or team versus organization-wide grants made by the organization owner. This helps explain how a user got access to a specific repository.

The new repository collaborators view, showing the organization based access.

For more information, see GitHub’s documentation as well as the REST API methods for automating role creation and assignment.

See more

Unkey is now a GitHub secret scanning partner

For Unkey users, GitHub secret scanning now scans for Unkey tokens to help secure your public repositories. Unkey’s Root API Key enables users to create and manage Unkey resources including APIs, API keys, global rate limiting, and access controls. GitHub will forward any exposed tokens found in public repositories to Unkey, who will then revoke the compromised tokens and notify the affected users. Read more information about Unkey tokens.

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.

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

See more

Secret scanning fine-grained permissions for bypasses

You can now grant fine-grained permissions to review and manage push protection bypass requests within your organization.

Anyone with this permission will have the ability to approve and manage the list of bypass requests. You can still also grant these permissions by adding roles or teams to the “Bypass list” in your code security and analysis settings.

Next month, GitHub will be removing custom role support from the bypass list along with this change. To avoid disruption, existing custom roles that were added as bypass reviewers previously will be granted the fine grained permissions to review and manage bypass requests.

Delegated bypasses for secret scanning push protection allow organizations and repositories to control who can push commits that contain secrets. Developers can request approval from authorized users to push a blocked secret.

Learn more

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

See more

What’s New in GitHub Sponsors

View all your organization’s Sponsors activity in one place.

It’s now easier for organizations to view GitHub Sponsors related activities in one place. From the Sponsors dashboard you can view your current and past sponsorships, create bulk sponsorships, and view your dependencies. You can search for a specific project or export all of your dependencies to easily find maintainers to sponsor.

Learn more about the Sponsors dashboard.

Share Sponsorships on Social Media

Maintainers and sponsors can share and celebrate sponsorships on social media with a click of a button. Maintainers can connect with their sponsors and share their goals.

Learn more about sharing on social.

See more

Copilot Chat in GitHub.com now can search across GitHub entities

Image

With this change, you can now use natural language within Copilot Chat in GitHub.com to search across GitHub to find commits, issues, pull requests, repositories, and topics.

Try it yourself:
– What are the most recent issues assigned to me?
– What repos are related to [insert topic]?
– What is the most recent PR from @user?

We’ve also made some changes under the hood to make Copilot more efficient with how it stores conversation histories. This means that Copilot can now remember more of the history of your conversation which should result in more informed and reliable responses ✨.

Join the discussion within GitHub Community.

See more

GitHub Enterprise Server 3.14 is generally available

GitHub Enterprise Server 3.14 is generally available

GitHub Enterprise Server 3.14 gives customers enhanced deployment requirements and security controls. Here are a few highlights in the 3.14 release:

  • SCIM for GHES is a popularly requested enterprise identity management feature, now available in public beta! SCIM stands for “System for Cross-domain Identity Management” and is a leading standard for user lifecycle management in SaaS applications. Enterprise administrators can configure SCIM for their GitHub Enterprise Server instance, which supports automatic provisioning of new user accounts and groups through our SCIM API. We support several paved path applications such as Entra ID and Okta that combine SAML and SCIM support in one place. Additionally, you may bring your own SAML identity provider and SCIM implementation to GitHub Enterprise Server to satisfy your unique identity and user lifecycle management needs. To get started, visit our SCIM documentation for GitHub Enterprise Server. While in public beta, we recommend testing SCIM support for your identity system in a non-production GHES environment before adding SCIM to your current setup. SCIM support can be added onto existing SAML implementations, but it will require using a new application that supports automated provisioning via SCIM in your IdP. Existing private beta customers should also reconfigure their implementation with updated IdP applications.

  • SAML settings are now visible as a read-only configuration in the enterprise settings page. Enterprise administrators are able to view these settings in the same place where SCIM support is configured for your enterprise instance.

  • We’re introducing custom organization roles, allowing you to delegate some of the organization’s administrative duties to trusted teams and users. Organization admins will have both the UI and API to manage these custom roles. See custom organization roles.

  • Code scanning option for repository rules is now available in public beta in GHES. Now, you can create a dedicated code scanning rule to block pull request merges instead of relying on status checks. This makes it easier than ever to prevent new vulnerabilities from being introduced into a code base. See set code scanning merge protection.

  • Dependabot grouped security updates are now generally available. This feature automatically groups Dependabot pull requests and lets you specify several additional options to fine tune groupings. You can enable grouped security updates for Dependabot at the repository or organization-level. If you would like more granular control over Dependabot’s grouping, you can also configure the dependabot.yml file in a repository.

  • With Generation 2 VM support, Operators can scale the GHES appliance vertically. New installs of 3.14 and later will boot on newer generation hardware by supporting both boot firmwares, BIOS, and UEFI. See Generation 2 VMs.

  • On an instance with multiple replica nodes, to start or stop replication for all nodes in a single configuration run, Operators can use the ghe-repl-start-all and ghe-repl-stop-all commands.

Read more about GitHub Enterprise Server 3.14 in the release notes, or download it now. If you have any issues upgrading your GitHub Enterprise Server Appliance to version 3.14, or problems using new features, please contact our Support team.

Join the community discussion to share your feedback and ask questions.

See more

CodeQL code scanning can analyze Java and C# codebases without needing a build (GA)

CodeQL code scanning can now analyze Java and C# code without having to observe a build. This makes it easier to roll out the security analysis on large numbers of repositories, especially when enabling and managing repositories with GHAS security configurations.

CodeQL is the analysis engine that powers GitHub code scanning. When analyzing source code, it is important that the analysis engine has detailed knowledge of all aspects of the codebase. Now, the analysis engine no longer depends on observing the build process for Java and C# code, resulting in higher setup success and adoption rates for CodeQL code scanning (Java and C#).

During the testing of this feature, we validated that the analysis results were as accurate as the previous methodology. This feature was previously in public beta earlier this year (Java, C#), when it became the new default analysis mode for new users of CodeQL code scanning for these languages. Some customers experienced time significant savings as some tasks that previously took weeks now are achievable in minutes.

CodeQL’s new zero-configuration analysis mechanisms for both Java and C# are available on GitHub.com. If you are setting up CodeQL code scanning for these repositories, you will benefit from this analysis mechanism by default. If you set up CodeQL code scanning for Java or C# before their respective public beta releases of this feature, your analysis will remain unchanged (but can be migrated by disabling the current configuration and re-enabling code scanning using default setup). This new functionality will also be released to our GitHub Enterprise Server (GHES) customers starting with version 3.14 for Java and 3.15 for C#.

Repositories that use code scanning advanced setup will continue to use whichever analysis mechanism is specified in the Actions workflow file. The template for new analysis configurations now uses the new analysis mechanism by specifying `build-mode: none`. The old analysis mechanisms remain available. Users of the CodeQL CLI can find more documentation here.

Learn more about GitHub code scanning. If you have any feedback about these new analysis mechanisms for Java and C#, please join the discussion here.

See more

Custom models for GitHub Copilot are now in Limited Public Beta

Custom models for GitHub Copilot are now available in Limited Public Beta for Copilot Enterprise. This new capability lets you fine-tune Copilot to better understand and align with your organization’s unique coding practices, improving the relevance and accuracy of code suggestions across your projects.

What are custom models?

Custom models are large language models (LLMs) that have been fine-tuned using your organization’s codebases. By training a model on your proprietary libraries, specialized languages, and internal coding patterns, Copilot delivers code suggestions that are more context-aware and tailored to your organization’s needs.

During this beta, you can create a custom model using your GitHub repositories. Optionally, you may also enable the collection of code snippets and telemetry from developers’ Copilot prompts and responses to further fine-tune the model. This process closely aligns Copilot’s suggestions with your coding practices, making them more relevant and accurate. As a result, your development teams will spend less time on code reviews, debugging, and manual code adjustments, ultimately boosting team productivity and ensuring more consistent code quality.

Custom-Model-Training-Config

Importantly, your data remains entirely yours. It is never used to train another customer’s model, and your custom model is kept private, ensuring full control, security, and privacy.

When to Use Custom Models

Custom models enable you to make Copilot’s suggestions more relevant to your specific needs, which can lead to higher acceptance rates of the code suggested by Copilot among your developers. Consider using custom models in the following scenarios:

  • Enhance Library and API Usage: When your organization relies heavily on custom libraries or APIs that aren’t well-represented in public datasets, a custom model can prioritize these in its suggestions, making it easier for your developers to follow internal standards.

  • Improve Support for Specialized Languages: If your team works with less common or proprietary languages, custom models can make Copilot much more effective. Fine-tuning helps Copilot understand these languages better, reducing friction and improving productivity.

  • Adapt to Evolving Codebases: As your codebase changes, you have full control over when and how often to retrain your custom model. By regularly retraining, you can ensure that Copilot keeps up with the latest coding patterns, so it continues to provide relevant and accurate suggestions.

How to Get Started

  1. Sign Up for the Beta:
    Sign up here to participate in the Limited Public Beta and make sure your organization is on the Copilot Enterprise plan.

  2. Prepare Your Repositories:
    Choose the repositories that best reflect your organization’s coding standards. Include those with proprietary libraries, specialized languages, or key internal frameworks to get the most out of fine-tuning. If your enterprise has multiple GitHub organizations, note that only one organization and its repositories can be used for training during this beta.

  3. Enable Telemetry Collection:
    To further customize your model, consider enabling the collection of code snippets and telemetry related to developers’ prompts and Copilot’s suggestions. This data will be securely collected and used for additional fine-tuning, improving the accuracy and relevance of Copilot’s output for your team. Your data will only be used to enhance your custom model and will not be shared with others. For more details about our data-handling practices, please visit the Trust & Security Center or review GitHub’s data protection agreement.

  4. Training and Usage:
    After setup, your custom model will be trained using the selected repositories. Once it’s ready, your developers’ IDEs will automatically start using the custom model, which will inform all in-line code completions.

  5. Monitoring & Quality Assessment:
    Regularly retrain your custom model to keep it aligned with new code and evolving practices. Use the Copilot Usage Metrics API to track metrics like suggestion acceptance rates and see how much it’s improving.

Additional Resources

See more

Secret scanning displays branch and file paths for push protection bypasses

Push protection bypass requests will now show file path and branch information for the secret. This improvement helps you more effectively triage any secrets for which you’ve requested push protection bypasses. Branch information is only available for pushes to single branches.

Delegated bypasses for secret scanning push protection allow organizations and repositories to control who can push commits that contain secrets. Developers can request approval from authorized users to push a blocked secret.

Learn more

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

See more

Client IDs are now included in App API responses

The client_id field is now included in all API responses that describe a GitHub App. We are shifting to use the client ID as the primary identifier for an app, as client IDs are globally unique while application IDs and names are not.

Historically GitHub has used the app_name (aka slug) or the app_id (a database ID) to identify applications in our APIs. However, the app name is not immutable and the app ID is not sufficiently globally unique. We are gradually moving all App-related APIs to support the use of the client_id of an application as their primary identifier instead of the name or database ID – this was first seen in our change to support using the client ID to mint JWTs used for installation tokens.

We are making this change to prepare for upcoming features that allow programmatic management of applications in your enterprise. This additional data will make it easier to find the client ID of an application that you are interested in.

For more information about how to get application information, see our REST API documentation.

See more

Secret scanning non-provider patterns inclusion in recommended security configuration

Now, secret scanning non-provider patterns are included in the GitHub-recommended security configuration. Non-provider patterns have also been automatically enabled for any repositories with the recommended configuration previously attached.

Secret scanning non-provider patterns are generic detectors which help you uncover secrets outside of patterns tied to specific token issuers, like HTTP authentication headers, connection strings, and private keys.

Learn more

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

Secret scanning now deduplicates non-provider patterns

To help you triage and remediate secret leaks more effectively, GitHub secret scanning now dededuplicates non-provider patterns (generic patterns) against provider patterns.

Secret scanning non-provider patterns are generic detectors that help you uncover secrets outside of patterns tied to specific token issuers, like HTTP authentication headers, connection strings, and private keys.

Note: Custom patterns are not deduplicated, as removing a custom pattern will also delete those alerts. We recommend adjusting your custom patterns to avoid overlap with any GitHub-defined detectors.

Learn more

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

Secret scanning non-provider patterns are included in security configurations

You can now enable non-provider patterns (generic patterns) through security configurations at the organization level.

Non-provider patterns will also be included in the GitHub-recommended security configuration on August 23, 2024. At that time, non-provider patterns will be automatically enabled for any repositories with the recommended configuration attached.

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

Anthropic is now a GitHub secret scanning partner

For Anthropic users, GitHub secret scanning now scans for Anthropic tokens to help secure your public repositories. Anthropic tokens enable users to access Claude through the Anthropic API. GitHub will forward any exposed tokens found in public repositories to Anthropic, who will then revoke the compromised tokens and notify the affected users. Read more information about Anthropic tokens.

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.

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

See more

Notice of upcoming deprecations and breaking changes in GitHub Actions runners

GitHub Actions will be making the following deprecations and breaking changes in our runners and services over the next 6 months.

Exclude hidden files by default in Upload Artifact GitHub Actions
From September 2nd, 2024, we will no longer include hidden files and folders as part of the default upload of the v3 and v4 upload-artifact actions. This reduces the risk that credentials are accidentally uploaded into artifacts. Customers who need to continue to upload these files can use a new option, ‘include-hidden-files’, to continue to do so.

Ubuntu 20 & Ubuntu 22 arm64 Images
On September 3rd, 2024, we are deprecating the Ubuntu 22/20 base images for our arm64 hosted runners as these are not widely used and customers are better served using the new Arm owned images. At that time all workflows using the Ubuntu 22 or 20 base image on arm64 will begin to fail. To change the image your runner is using, you can delete the runner and recreate a runner with the same name, to prevent failures. We recommend using the partner images provided by Arm:

  • Ubuntu 24.04 by Arm Limited
  • Ubuntu 22.04 by Arm Limited

.NET6 deprecation in the runner
In October, 2024, at the same time as we move to Node20 on the Actions runner, we will be deprecating .NET6 in the Actions runner and moving to .NET8. This is because .NET6 will reach end of life in November 2024. Any customers who are still using operating systems which are reliant on unsupported binaries will need to upgrade prior to this change. The removal of support for .NET6 means the following operating systems will no longer be supported from this time:
– Debian 10
– macOS 11.0
– macOS 10.15

Along with those already marked as unsupported in our changelog for the removal of Node16.

macOS12 runner image
We are beginning the deprecation process for the macOS 12 runner image, which allows us to balance our fleet capacity ahead of our upcoming macOS 15 launch. This image will be fully retired by the December 3rd, 2024. We recommend updating workflows to use `macos-14`, `macos-13`, or `macos-latest`.

Unsupported macOS labels
On December 3rd, 2024, we are deprecating some of our older and less used labels which are used for smaller numbers of workflows. The following runner labels will stop working from that time:

  • macos-11.0
  • macos-12-xl
  • macos-13-xl
  • macos-13-xl-arm64
  • macos-latest-xl
  • Macos-latest-xl-arm64

See more

Prevention and autofix insights for CodeQL pull request alerts

You can now track prevention metrics for CodeQL pull request alerts with the new CodeQL pull request alerts report—available at both the organization and enterprise level. These insights empower you to proactively identify and mitigate security risks before they reach your default branch.

Enterprise-level CodeQL pull request alerts report

With this report, you can historically track metrics for CodeQL pull request alerts as code moves from feature branches to the default branch. Gain insights into:

  • Unresolved and merged alerts: Understand what security vulnerabilities made it to the default branch.
  • Fixes (autofix and manual): Track which alerts were addressed before merging.
  • Dismissed alerts: See which alerts were deemed false positive or risk accepted.

Additionally, analyze metrics by CodeQL rule, autofix status, and repository.

Historical data is available starting from May 1, 2024.

To access these reports, 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 find CodeQL pull request alerts in the sidebar. For enterprises, click Code Security in the sidebar, then select CodeQL pull request alerts.

These reports are now generally available on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.15.

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

See more

Content Exclusion beta now supports non-Git files

You can now exclude non-Git files from being accessed by Copilot, in addition to Git files. This update gives you greater control over the content Copilot can access, ensuring that it will not access files that an organization owner has marked for exclusion, whether the files are part of a Git repository or not.

How to exclude non-Git files

The wildcard scope has expanded to include both files within and outside Git repositories, supporting the exclusion of non-Git files.

Previously

Wildcard rules applied exclusively to files within the Git repository. For example:

"*":
  - /test1 # => Blocks from the root of all git repositories: `/test1`

Now

Wildcard rules apply to files within the Git repository and the filesystem root. For example:

"*":
  - /test1 # => Blocks from the root of all git repositories AND the filesystem root: `/test1`, `/test1`

Note: These changes to our Content Exclusion beta apply to the latest versions of both the VS Code and JetBrains Copilot extensions, covering the code completions and chat features in each.

See more

Secret scanning for non-code GitHub surfaces is now generally available

GitHub secret scanning now detects and alerts you on secrets found in GitHub issues, wikis, discussions, and pull requests.

Secrets, like API keys, passwords, and tokens, can hide in many places. Throughout 2024, we’ve discovered over 100k unique secrets hiding in mediums outside of code. If these leaks aren’t managed correctly, each one of them could pose a substantial risk.

To help protect you from leaked secrets – anywhere within your GitHub perimeter – GitHub provides visibility across all major surfaces. We scan these surfaces for over 200+ token formats and work with relevant partners to help protect you from publicly leaked secrets. GitHub also supports generic patterns like RSA private keys and Copilot-detected passwords.

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

Retrieve the code security configuration currently applied to a repository via API

You can now retrieve the code security configuration applied to a specific repository via the repos endpoint in the REST API. Previously, you could only retrieve all the repositories associated with a configuration rather than the inverse.

Code security configurations help you manage and enforce the enablement of your security features like Dependabot, code scanning, and secret scanning.

To learn more about retrieving code security configurations with our repository REST API endpoint, check out our docs here.

See more

High contrast theme improvements

A screenshot showing the adjusted UI elements for the high and dark color contrast themes

The light and dark high contrast themes have been updated to improve readability.

Now:

  • Both themes aim to meet a minimum contrast ratio of 7:1 for all elements, and the secondary or “muted” text and icons appear slightly lighter or darker than the default text, enhancing the visual hierarchy throughout GitHub’s interface.
  • In the light high contrast theme, the global navigation bar appears inset with a darker background color.
  • In the dark high contrast theme, the foreground text over solid backgrounds is now white, and higher contrast borders have been added to all interactive elements.

See more
View more changes