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

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

GitHub Actions – Updating the default GITHUB_TOKEN permissions to read-only

Previously, GitHub Actions gets a GITHUB_TOKEN with both read/write permissions by default whenever Actions is enabled on a repository.
As a default, this is too permissive, so to improve security we would like to change the default going forward to a read-only token. You can still flip it to read/write if needed.

This change will not impact any existing enterprises, organizations or repositories. Here is how the defaults are set going forward.

  1. Enterprises: New enterprises will have read-only token.
  2. Organizations owned by Enterprise: New organizations will inherit the permissions from parent enterprise.
  3. Organizations not owned by Enterprise: New organizations will have read-only token.
  4. Repositories owned by organization: New repositories will inherit permissions from parent organization.
  5. Repositories owned by personal account: New repositories will have read-only token.
See more

API requests are available via audit log streaming – Private Beta

GitHub Enterprise Cloud customers can now join a private beta which allows API request events to be streamed as part of their enterprise audit log.

In this private beta, REST API calls against enterprise private repositories can be streamed to one of GitHub's supported streaming endpoints. Further iterations on this feature are planned to expand the API events captured and make this data available via the audit log API.

Many GitHub users leverage GitHub's APIs to extend and customize their GitHub experience. However, use of APIs can create unique security and operational challenges for Enterprises.

With the introduction of targeted audit log streaming API requests, Enterprise owners are now able to:

  • Better understand and analyze API usage targeting their private repositories;
  • Identify and diagnose potentially misconfigured applications or integrations;
  • Troubleshoot API activity targeting private repositories that may be contributing to API rate limiting; and
  • Develop API specific anomaly detection algorithms to identify potentially malicious activity.

Enterprise owners interested in participating in the private beta should reach out to your GitHub account manager or contact our sales team to have this feature enabled for your enterprise. Once enabled, you should begin seeing API request events in your audit log stream. Feedback can be provided at our beta feedback community discussion post.

See more

GitHub Actions: Job summary updates

We are making changes to job summaries and logs in GitHub Actions that will impact customers using self-hosted runners. Over the next six months, customers using self-hosted runners will need to ensure machines have appropriate network access to communicate with the GitHub hosts below so that job summaries and logs emitted from Actions workflows can work as expected.

  • actions-results-receiver-production.githubapp.com
  • productionresultssa*.blob.core.windows.net

After July 31, 2023, if you are using self-hosted runners and have not updated your network access settings to allow the aforementioned hosts, your job summaries and logs may not display correctly.

For more details see
Communication between self-hosted runners and GitHub.

For questions, visit the GitHub Actions community.

To see what's next for Actions, visit our public roadmap.

See more

Audit log streaming to AWS S3 integration with AWS CloudTrail Lake

In January 2022, GitHub announced audit log streaming to AWS is generally available. By streaming the audit log for your enterprise, enterprises benefit from:

  • Data exploration: Examine streamed events using your preferred tool for querying large quantities of data. The stream contains both audit and Git events across the entire enterprise account.
  • Data continuity: Pause the stream for up to seven days without losing any audit data.
  • Data retention: Keep your exported audit logs and Git events data as long as you need to.

To expand on this offering, enterprises streaming their audit log to AWS S3 now have the ability to use AWS CloudTrail Lake integration to automatically consolidate and ingest GitHub audit logs into AWS Cloud Trail Lake. AWS CloudTrail Lake is a managed security and audit data lake that allows organizations to aggregate, immutably store, and query events. By deploying this integration in your own AWS account, AWS CloudTrail Lake will capture and provide tools to analyze GitHub audit log events using SQL-based queries.

To learn more, read our documentation on integrating with AWS CloudTrail Lake.

See more
View more changes