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

More love for innersource collaboration and enterprise fork policies

In June 2022 we updated fork capabilities to include forking a repository into the same organization as its upstream repository, forking internal repositories to enterprise organizations, and for enterprise owners to limit where forks can be created. This opened up a lot of new possibilities for collaboration!

We recently updated fork capabilities again to unblock an additional workflow: fork repositories into another organization more than once. Before, when you tried to fork a repository into another organization that already had a fork of that repository, your option to finish forking into that organization was grayed out and GitHub let you know that a fork already exists in the target organization. With this update, you will have the option to continue forking it using a unique name.

screenshot of forking when the repo already exists and has a red warning triangle

screenshot of forking when the fork has been renamed and has a green check

We welcome your feedback on this in GitHub’s public feedback discussions.

See more

Code scanning adds support for Kotlin 1.8.0 analysis (beta)

Back in November 2022 we announced the public beta for Kotlin analysis. We continue to invest in Kotlin and we now support Kotlin 1.8.0 analysis in beta.

If you have any feedback or questions, please use this discussion thread or open an issue in the open source CodeQL repository if you encounter any problems.

Kotlin beta support is available by default in GitHub.com code scanning, the CodeQL CLI, and the CodeQL extension for VS Code. GitHub Enterprise Server (GHES) version 3.9 will include this beta release.

See more

GitHub Actions – Removal of additional label option for GitHub-hosted larger runners

Starting on February 14, 2023, users of GitHub-hosted larger runners will no longer be able to add, edit or remove additional labels on existing or new runners. Customers will continue to be able to use the runner group as a runs-on target to use ‘groups’ of larger runners. This provides a more determinstic approach to targetting groups of machines compared to labels and aligns with our future work to improve the runner management experience.

Existing runners with additional labels will continue to support these labels, if you wish to remove these you will need to delete the runner and create a new one with the same name. Users will continue to be able to target their runners using the runner name as the default label.

See more

GitHub Copilot for Business is now widely available

GitHub Copilot for Business is now available to Free, Team, and GitHub Enterprise Cloud customers. This update allows more organizations to give their developers access to GitHub Copilot’s powerful AI while providing administrators with license management and centralized policy controls on top of industry-leading privacy.

With this announcement, we’re also excited to share that we’ve made enhancements to:
– security vulnerability filtering
– improved Codex model
– VPN proxy support via self-signed certs

These improvement mean that GitHub Copilot’s code suggestions are more secure, better utilized, and work in more environments.

See more

WakaTime 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, our scans help prevent data leaks and fraud.

We have partnered with WakaTime to scan for their tokens and help secure our mutual users on public repositories. WakaTime tokens allow users to programmatically access their WakaTime code statistics. GitHub will forward access tokens found in public repositories to WakaTime, who will immediately revoke the leaked token and email the token's owner with instructions on next steps. You can read more information about WakaTime tokens here.

GitHub Advanced Security customers can also scan for WakaTime tokens and block them from entering their private and public repositories with push protection.

See more

GitHub Projects – February 9th update

Today’s changelog brings you the addition of colors and descriptions for single-select fields, as well as improvements to both roadmaps and tasklists!

🎨 Single-select field colors and descriptions

Make it easier for your team to scan projects and take action by adding color and descriptions to single select fields. To update a field, go to settings and select the pencil icon next to the custom single-select field you want to update.

🗺 Roadmaps improvements

If plans change and you need to make adjustments to your roadmap, you can now resize and move items between iterations. Drag and drop your items to quickly make your changes when using an iteration as a Date field on your roadmap.

You are also now able to resize the table in a roadmap view to create the space you need, similar to resizing a column in a table view.

✅ Tasklists improvements

Tasklists are currently in private beta but we’re letting folks in as fast as we can. If you haven’t already, be sure to join the waitlist!

We’ve recently shipped the below improvements, so let us know what you think.
– Navigate via the side-panel when grouped by Tracked by
– Open and navigate in the side-panel by clicking the Tracks completion pill
– Automatically update your filter by clicking on the “Tracked by” text in the Tracked by field in board layout

✨ Bug fixes and improvements

  • Leverage copyProjectV2 in the GraphQL API to copy a project
  • Manually reorder items on a sorted table view
  • Edit single-select fields directly from a board column with the new Edit details menu option
  • Auto-save single-select field changes in project settings

See how to use GitHub for project planning with GitHub Issues, check out what’s on the roadmap, and learn more in the docs.

See more

Dependency submission suggestions on Gradle, Maven, Scala and Mill repositories

Dependency graph automatically supports many ecosystems, but some additional ecosystems require configuration to submit dependencies with the dependency submission API. The community maintains several GitHub Actions that make this easier.

Users with write access to Gradle, Maven, Scala, and Mill repositories now see messaging on their dependency graph that directs them to an action that will scan and submit dependencies for their ecosystem. Users with access to Dependabot alerts will also see messaging on their repository's Dependabot alerts tab.

img

Prompts will display if a repository includes any of the following files: pom.xml, build.gradle, build.gradle.kts, build.sbt, or build.sc.

The dependency graph team is working to have native support for these types of ecosystems with more news to come later this year.

See more

Manage branch protection rules with a new permission

You can now create a custom role to manage branch protections without having to grant the Admin role. Previously, to manage branch protections you had to be an Admin which provides additional permissions that may not be needed. For tighter control of Admin permissions, you can now craft a custom role that has the Edit repository rules permission, allowing just the right amount of access.

Image of Custom roles that shows the new Edit Repository Rules permission

This permission grants the ability to create, edit, and delete both branch protection rules and protected tags.

For more information, visit Managing custom repository roles for an organization in the GitHub documentation.

We appreciate feedback on this in GitHub's public feedback discussions.

See more

Pull request merge queue (public beta)

Today we are announcing the public beta of pull request merge queue for repos on GitHub Enterprise Cloud and open source organizations! 🎉

Merge queue helps increase velocity in software delivery by automating pull request merges into your busiest branches.

Pull request merge queue

Before merge queue, developers were often required to update their pull request branches prior to merging to ensure their changes wouldn't break the main branch when merged. Each update resulted in a fresh round of continuous integration (CI) checks that would have to finish before the developer could attempt to merge. If another pull request got merged, every developer would have to go through the process again.

Merge queue automates this process by ensuring each pull request queued for merging is built with the pull requests ahead of it in the queue.

Queueing a pull request to merge

If your pull request targets a branch that uses merge queue, instead of merging your pull request directly when it meets the requirements to merge, you will add it to the queue by clicking Merge when ready from the pull request page or from GitHub Mobile.

Queue to merge

The queue then creates a temporary branch that contains the latest changes from the base branch, the changes from other pull requests already in the queue, and the changes from your pull request. CI then starts, with the expectation that all required status checks must pass before the branch (and the pull requests it represents) are merged.

If a queued pull request has merge conflicts or fails any required status check, it is automatically removed from the queue when it reaches the front, and a notification is sent. Once the problem is resolved, it can be added back to the queue.

Learn more about merging a pull request with merge queue from the pull request page. You can also queue your pull request on the go using the beta version of GitHub Mobile from iOS TestFlight or Google Play (Beta)!

Viewing the queue

Always know where you are in the queue.

The queue details page, which can be accessed from the Branches page or pull request page, shows the pull requests in the queue and status for each, including the required status checks and estimated time to merge. It also shows how many pull requests have been merged and the trend over the last 30 days.

Merge queue details page

Depending on your permissions, you can also remove a pull request from the queue or clear the queue from this page.

Getting started

Merge queue can help improve overall velocity and avoid manual branch updates that impact developer productivity. Learn more about how to enable merge queue on your busiest branches.

We want to hear from you on how we can improve merge queue! Join the conversation in the merge queue public beta discussion.

See more

Sunset Notice – Team Discussions

Today we are announcing the deprecation of Team Discussions, which will have individual sunset timelines for GitHub.com, API, and GHES users. Please see below for full details.

Last year, we introduced Organization Discussions, a way for teams to scope their discussions to the organization-level rather than the repository-level. Today, Organization Discussions has grown to include a number of features – including Categories, Category forms, Threaded comments, Q&A features (marking a comment as an answer), Polls, and Labels.

As we continue to invest and enhance Organization Discussions, we will be sunsetting Team Discussions. To migrate your existing Team Discussions to Organization Discussions, maintainers can click on the banner at the top of their Team Discussions page:

Screenshot 2023-02-07 at 3 32 28 PM

Following deprecation, access to any unmigrated Team Discussions will be available as raw text, but there won't be any ability to add, modify, or delete Team Discussions.

The deprecation will follow these timelines:

GitHub.com Timeline:

  • Feb 8, 2023: A banner to migrate will be visible to maintainers at the top of their Team Discussions page, with the migration tooling included.
  • May 8, 2023: Team Discussions will be deprecated.
  • After May 8, 2023: Access to unmigrated Team Discussions will be available as raw text, but the UI won’t be available to add, modify, or delete Team Discussions.

GHES Timeline:

  • June 6th, 2023: Team Discussions will be marked for deprecation in version 3.9. A banner to migrate will be visible to maintainers at the top of their Team Discussions page, with the migration tooling included.
  • August 29, 2023: Team Discussions will be removed in version 3.10.
  • After August 29, 2023: Access to unmigrated Team Discussions will be available as raw text, but the UI won’t be available to add, modify, or delete Team Discussions.

API Timeline:

  • The Team Discussions API will be deprecated in the next calendar version (no sooner than April 30th, 2023)

For questions or feedback, please visit our community.

See more

CodeQL code scanning is now 16% faster

CodeQL is the engine that powers GitHub code scanning, used by more than 100,000 repositories to catch security vulnerabilities before they cause issues in deployments.

CodeQL is fully integrated into the Pull Request workflow, so it has to be as fast as possible to keep developers unblocked.

We're constantly working on performance improvements, from incremental optimizations to fundamental research, all with the goal of speeding up the nearly 150,000 checks we run every single day, without compromising our best-in-class precision and low false-positive rate.

With the recent release of CodeQL version 2.12, we looked back at the performance gains compared to version 2.11 (September 2022) to see how far we've come. We compared the analysis time for the same 55,000 repositories on GitHub.com and found an average improvement of 15.7% across all supported languages:

codeql performance 2 11 2 12 improvement

Users on GitHub.com automatically run the latest CodeQL version. Customers on GitHub Enterprise Server can update by following the sync processes explained here.

See more

The GitHub Enterprise Server 3.8 Release Candidate is available

The GitHub Enterprise Server 3.8 release candidate is here

GitHub Enterprise Server 3.8 brings new capabilities to help companies build and deliver secure software, more quickly. With over 100 new features, here are a few highlights:

  • Projects, the adaptable and flexible tool for planning and tracking work on GitHub, is now available on Enterprise Server as a public beta. A project is an adaptable spreadsheet that integrates with your issues and pull requests on GitHub to help you plan and track your work effectively. You can create and customize multiple views by filtering, sorting, grouping your issues and pull requests, and adding custom fields to track metadata specific to your team. Rather than enforcing a specific methodology, a project provides flexible features you can customize to your team’s needs and processes.
  • GitHub Actions support organization-wide required workflows. You can define mandated workflows to run during the lifecycle of a repository’s pipeline. Individual development teams at the repository level will be able to see what required workflows have been applied to their repository, what actions that workflow performs, and whom to contact if they have questions.
  • Code scanning now supports Kotlin. We are launching a public beta for support of Kotlin. In this public beta Kotlin support will be enabled by default for all new code scanning users, and existing users that have already configured a Java analysis.
  • The Management Console now supports multiple users. Authentication in the management console is currently based on a single admin password. In version 3.8 we are introducing a multi-user concept with a user management interface to the Management Console which will allow admins to invite new users with different types of roles.

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

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

See more

Migration of CodeQL CLI Docs to GitHub Docs site

Following feedback from code scanning users, we've moved documentation about the CodeQL CLI from codeql.github.com to docs.github.com, the main GitHub Docs site.

You can now find the articles under the “Using the CodeQL CLI” and “CodeQL CLI reference” categories, which correspond to the categories on the original site. We’ve updated each of the original articles on codeql.github.com with links to the new location of the article and to each subsection, so that if you go to the old location you can easily find the information you need.

The source files now exist in Markdown format in the public, open-source docs repository. If you would like to contribute, you can consult and follow the steps listed in the GitHub Docs contributing guide.

See more

Dependabot alerts default permissions change

What's new?

Starting today, anyone with repository write or maintain roles will be able to view and act on Dependabot alerts by default. Previously, only repository admins could view and act on Dependabot alerts. This change will help ensure that alerts are visible to the same developers responsible for fixing them.

How do I opt in?

No action needed–this change will be applied to all existing and new repositories starting today.

What's not changing?

This doesn’t affect custom roles, the Security Manager role, or organization permissions for Dependabot alerts. Only repository admins can enable or disable Dependabot alerts.

What about alert notifications?

This change also will not affect your alert notification or repository watching settings. So, if you aren’t opted in to Dependabot alert notifications based on your user settings, you won’t receive any.

If you are currently receiving notifications on alerts, any new repositories will be included with existing Dependabot alerts notifications.

Learn more about this change here.

See more

Code scanning can be set up not to fail a pull request check

Code scanning can now be set up to never cause a pull request check failure.

By default, any code scanning alerts with a security-severity of critical or high will cause a pull request check failure.
You can specify which security-severity level for code scanning results should cause the code scanning check to fail, including None, by going to the Code security and Analysis tab in the repository settings.

Screenshot code-scanning-settings

This has shipped to GitHub.com and will be available in GitHub Enterprise Server 3.9. Learn more about severity levels for security alerts and Code scanning results check failures on pull requests.

See more

Category Forms on GitHub Discussions

Maintainers of GitHub repositories can now use Category Forms to create templates for their Discussions, which means that users can start new discussions with all the necessary information already included. We hope this leads to less repetitive back and forth conversation with maintainers, as users are more likely to capture all relevant details in their first Discussion post.

Similar to Issue Forms, maintainers can create a discussion template, which will live in .github/DISCUSSION_TEMPLATE/. Each template will map 1:1 with the available Discussion Categories slugs. For example, the template for the “Announcements” category will be .github/DISCUSSION_TEMPLATE/announcements.yml. Once created, Category Forms in Discussions will be familiar to users who have seen them in issues:

Learn more about Category Forms
For questions or feedback, please visit our community.

See more

Persona 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, our scans help prevent data leaks and fraud.

We have partnered with Persona to scan for their API keys and help secure our mutual users on all public repositories and private repositories with GitHub Advanced Security. Persona API keys allow users to create, update, and interact with their identity-related data. GitHub will forward API keys found in public repositories to Persona, who will notify affected customers and work with them to rotate their API keys. You can read more information about Persona API keys here.

GitHub Advanced Security customers can also scan for Persona API keys and block them from entering their private and public repositories with push protection.

Learn more about secret scanning
Partner with GitHub on secret scanning

See more
View more changes