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

Secret scanning summary email for historical scans

If you are an organization or enterprise owner, you will now receive a secret scanning summary email when the historical scan completes. The email notification will tell you how many, if any, secrets were detected across all repositories within your organization or enterprise. You'll also receive a link to your security overview page for each secret, where you can view details for each detected secret.

Previously, secret scanning would send one email per repository where secrets were detected, provided that you were watching the repository and had email notifications enabled in your user settings enabled. While repository administrators will still receive an email notification per repository, organization and enterprise owners will now receive only a single notification upon the historical scan's completion.

To receive notifications:

  • For the first historical scan after you enable secret scanning, you must have email notifications enabled in your user settings. You do not need to watch any repositories to receive the secret scanning summary email.
  • For future historical scans, such as for newly added patterns, you will receive an email notification for each repository where a secret was found. You must be watching the repository where the secret was detected and have email notifications enabled in your user settings.

summary email after backfill scan

See more

Codespaces Settings Sync Updates

Codespaces now supports two-way Settings Sync with VS Code for the Web

Visual Studio Code enables users to Sync Settings between VS Code environments. Codespaces exposes this capability as a way to personalize your experience. Prior to this release, Settings Sync for the VS Code web client was one-way by default, and two-way sync had to be enabled manually for each codespace.

With today's release, you can now choose whether to enable Settings Sync. Settings Sync is off by default. If you enable Settings Sync, the sync is two-way for repositories you trust, and one-way for untrusted repositories. Codespaces will also remember your choice.

The quickest way to enable Settings Sync is to start a codespace using the VS Code for the Web client, then choose 'Turn on Settings Sync…'

Turn on Settings Sync in VS Code web client

You will then be prompted for permission to enable Settings Sync for the repository. If you authorize, the Settings Sync setting on your GitHub profile will be enabled, and the repository will be added to a list of trusted repositories so that future codespaces on that repository will automatically have Settings Sync enabled in VS Code for the Web.
cVS Code Settings Sync is requesting additional permissions

You can manage your Settings Sync and GPG verification settings from your GitHub Codespaces Settings page at
https://github.com/settings/codespaces.

On the Codespaces settings page you can manage which repositories you trust for GPG verification and Settings Sync.
Codespaces Settings for GPG verification and Settings Sync

Trusted repositories

Settings Sync and GPG verification now share a single set of trusted repositories. You can enable or disable GPG verification and Settings Sync independently. If you have Settings Sync enabled and you open a codespace from a repository that is not in your list of trusted repositories, the Settings Sync will be read only – your settings will be pulled from the Settings Sync server and applied to your codespace, but no settings changes will be written back. If you open a codespace for a repository you do trust, your settings will be synced both to and from the server.

If you have enabled GPG verification for all repositories, we advise you to restrict the repositories to a trusted list when you first enable Settings Sync.

VS Code Settings Sync is requesting additional permissions when all repositories are trusted

If you choose to enable Settings Sync for all repositories we will keep that setting for GPG verification as well, but we recommend restricting both Settings Sync and GPG verification to trusted repositories to improve your security posture.

See more

GitHub Actions: All Actions will run on Node16 instead of Node12

Node 12 has been out of support since April 2022, as a result we have started the deprecation process of Node 12 for GitHub Actions. We plan to migrate all actions to run on Node16 by Summer 2023.
Following on from our warning in workflows using Node 12, we will start enforcing the use of Node16 rather than Node12 on the 18th of May.

What you need to do
For Actions maintainers: Update your actions to run on Node 16 instead of Node 12 (Actions configuration settings)
For Actions users: Update your workflows with latest versions of the actions which runs on Node 16 (Using versions for Actions)

See more

Doppler is 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 Doppler to scan for their tokens and help secure our mutual users on public repositories. Doppler tokens allow users to access and manage their secrets from their existing tooling and infrastructure. GitHub will forward access tokens found in public repositories to Doppler, who will revoke the tokens and email affected customers. You can read more information about Doppler tokens here.

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

See more

GitHub Desktop makes force pushing and fetching easy and adds pull request comment notifications

GitHub Desktop 3.2.3 makes force pushing and fetching through the newly added fetch/pull dropdown menu items as well as adding pull request comment notifications. Since 3.2.1, GitHub Desktop has also released more than 30 accessibility improvements.

Force-pushing and Fetching

In GitHub Desktop 3.1.5, we added the ability to force-push and fetch to the Repository menu item when applicable. Now, when those menu items would be available, the pull/push/fetch button becomes a dropdown so users can easily force push or fetch.

Gif that shows a user pressing fetch to put the repository in a diverged state. Then, shows the user opening the new dropdown and force pushing their changes to overwrite the changes in the remote.

Pull Request Comment Notifications

If you have been enjoying our Pull Request notifications on your repositories, you will be happy to hear we have expanded those notifications to include when someone has commented on your pull request as well so that you can keep up to date on the latest conversations happening on your pull request.

Accessibility

GitHub Desktop is actively working to improve accessibility in support of GitHub's mission to be a home for all developers.

GitHub Desktop 3.2.1

  • Misattributed warning is announced in 'Git' preferences/options by screen readers – #16239
  • The Preferences/Options dialog content is still visible when zoomed at 200% – #16317
  • Up/down arrow can be used to navigate autocomplete lists like emoji again – #16044
  • Focus history and changes list when accessed via keyboard shortcut or menu – #16360
  • On Windows, app level menu bar and menu items are announced by screen readers – #16315
  • Keyboard shortcuts for resizing app sidebar and file lists – #16332
  • Misattributed commit popover does not clip when app is zoomed – #16407
  • Accessibility improvements for the co-authors input – #16335
  • Commit completion status is announced by screen readers – #16371, #16340
  • Improve accessibility of dialogs for screen reader users – #16350
  • Accessibility improvements for autocompletion suggestions – #16324
  • Learn more links are descriptive for screen readers – #16274
  • Popover titles are announced by screen readers – #16270
  • Show offset focus ring for buttons, vertical tabs etc – #16288
  • Application main menu on Windows doesn't clip when zoom is set to 200% – #16290
  • Button and text box contrast bumps – #16287
  • Other email input in "Git" preferences/Options and misattributed popover email select have a screen readable label – #16240
  • Add/remove co-authors button is now keyboard accessible – #16200

GitHub Desktop 3.2.3

  • NVDA reads number of suggestions when an autocompletion list shows up – #16526
  • The undo commit confirmation modal message is screen reader announced – #16472
  • Clipping and overlapping of the changes list is fixed at 200% zoom – #16425
  • The commit message avatar is now a toggle tip making the commit author details keyboard accessible – #16272
  • The commit length hint is keyboard and screen reader accessible – #16449
  • The changes list header checkbox tooltip description is announced by screen readers – #16457
  • The changes list header checkbox tooltip is keyboard accessible – #16487
  • Announce a file's state of inclusion in the commit on the changes list – #16420
  • Display focus ring around focused control after dismissing a dialog – #16528
  • Identify the changes list and history commit list as the changes and history tab panels for screen readers – #16463
  • Windows title bar controls do not interrupt screen readers in browse mode – #16483
  • Make radio theme selection look like radio buttons. – #16525
  • Improve accessibility of GitHub Enterprise login flow – #16567"
  • Screen readers announce sign in errors – #16556"

Automatic updates will roll out progressively, or you can download the latest GitHub Desktop here.

See more

Dependabot alerts now automatically dismiss false positives for npm (public beta)

Starting today, Dependabot will be able to auto-dismiss npm alerts that have limited impact (e.g. long-running tests) or are unlikely to be exploitable. With this ship, Dependabot will cut false positives and reduce alert fatigue substantially.

On-by-default for public repositories, and opt-in for private repositories, this feature will result in 15% of low impact npm alerts being auto-dismissed moving forward – so you can focus on the alerts that matter, without worrying about the ones that don’t.

What’s changing?

When the feature is enabled, Dependabot will auto-dismiss certain types of vulnerabilities that are found in npm dependencies used in development (npm devDependency alerts with scope:development). This feature will help you proactively filter out false positives on development-scoped (non-production or runtime) alerts without compromising on high risk devDependency alerts.

Dependabot alerts auto-dismissal list view

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 an underlying, all-new, flexible and powerful alert rules engine. Today’s ship, our first application, leverages GitHub-curated vulnerability patterns to help proactively filter out false positive alerts.

Why auto-dismissal, rather than purely suppressing these alerts?

Auto-dismissing ensures any ignored alerts are 1) able to be reintroduced if alert metadata changes, 2) caught by existing reporting systems and workflows, and 3) extensible as a whole to future rules-based actions, where Dependabot can decision on subsets of alerts and do things like reopen for patch, open a Dependabot pull request, or even auto-merge if very risky.

How does GitHub identify and detect low impact alerts?

Auto-dismissed alerts match GitHub-curated vulnerability patterns. These patterns take into account contextual information about how you’re using the dependency and the level of risk they may pose to your repository. To learn more, see our documentation on covered classes of vulnerabilities.

How will this activity be reported?

Auto-dismissal activity is supported across webhooks, REST, GraphQL, and the audit log for Dependabot alerts. In addition, you can review your closed alert list with the resolution:auto-dismissed filter.

How will this experience look and feel?

Alerts identified as false positives will be automatically dismissed without a notification or new pull request, and appear as 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.

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.

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 can I enable or disable the feature?

This feature is on-by-default for public repositories and opt-in for private repositories. Repository admins can opt in or out from your Dependabot alerts settings in the Code Security page.

Is this feature available for enterprise?

Yes! In addition to all free repositories, this feature will ship immediately to GHEC and to GHES in version 3.10.

What’s next?

Next, we’ll expose our underlying engine – which enables Dependabot to perform actions based on a rich set of contextual alert metadata – so you can write your own custom rules to better manage your alerts, too.

How do I learn more?

How do I provide feedback?

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

See more

Rootly 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 Rootly to scan for their tokens and help secure our mutual users on public repositories. Rootly tokens allow users to authenticate against the Rootly API and create incidents programmatically. GitHub will forward access tokens found in public repositories to Rootly, who will notify workspace owners and let them revoke token within a few seconds. You can read more information about Rootly tokens here.

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

See more

Secret scanning now supports validation checks for supported partner patterns

GitHub Advanced Security customers can now enable validity checks for supported partner patterns in their repository, organization, or enterprise level code security settings.

When you enable the checkbox in your settings, GitHub will automatically check validation for patterns on a cadence by sending the pattern to our relevant partner provider. You can use the validation status on leaked secrets to help prioritize secrets needing remediation action.

As we continuously work with our partners to add support for more patterns, we'll update the "Validity check" column in our documented supported patterns list.

auto check for validity checkbox in settings

See more

Grafana Labs 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 Grafana Labs to scan for their tokens and help secure our mutual users on public repositories. Grafana tokens allow users to manage all resources within Grafana installations, and Grafana Cloud tokens can be used to authorize data ingestion requests and to manage the lifecycle of stacks. GitHub will forward access tokens found in public repositories to Grafana Labs, and they will automatically revoke the token and notify affected customers. You can read more information about Grafana's various tokens below:

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

See more

Try our new expandable event payload view in your audit log – Private Beta

GitHub Enterprises and Organzations can now join a private beta to try our new expandable event payload view in their audit log.

Screen_Recording_2023-04-27_at_12_22_29_PM_AdobeExpress (2)

We have gotten a lot of feedback that the information available in the audit log U/I is not the same as the data available in the audit log's exports, API and streaming payloads. In response, GitHub is adding a new expandable view of an event's payload in the audit log U/I. This brings data consistency to all the ways of consuming audit logs.

Enterprise and Organization 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. Make sure to let us know what you think using our beta feedback community discussion post.

See more

GitHub Issues & Projects – April 27th update

Today's Changelog brings you an easy way to set base project permissions and tasklists improvements!

🧑🏻‍🤝‍🧑🏾 Set Base Permissions in Projects

Organization admins can now set default project permissions. Project admins can always update permissions on their projects, but by changing the base permission, organization admins can change the default between admin, read, write or no access upon project creation.

🐞 Tasklists Bug Fixes

Thanks to your continued feedback we continue to make improvements for our tasklist users week over week!

  • Fixed a bug in projects where navigating to an item in the tasklist, going back to the parent, then navigating back to the same item was resulting in a strange and broken display
  • Fixed a bug where interacting with meta-data edits on tasklists too quickly resulted in users being pushed to a nonsensical blank page
  • Fixed a bug where clicking on labels in tasklists sometimes changed their order
  • Fixed a bug related to converting issues where sometimes draft tasks were not displayed as an issue until after the page was refreshed
  • Fixed a bug where users were unable to make changes to item meta-data after dragging and dropping items in the tasklist
  • Fixed a bug where converting too many issues at once sometimes broke tasklists
  • Fixed a bug where dragging and dropping while the tasklist was syncing resulted in the drag and drop not being registered
  • Fixed a bug where changing meta-data while converting an issue made the meta-data not reflect on the tasklist
  • Fixed a bug where pressing ESC when changing metadata resulted in weird UI

✨ Bug fixes and improvements

  • Improved speed on copy and paste behavior in the table view
  • Fixed omnibar margins and positioning in the roadmap layout
  • Workflow save button validation check now works without needing to refresh the page
  • Fixed several filter bar bugs
    • Clicking on the assignee icon no longer removes the assignee:@me filter
    • Clicking on milestones with a no longer ? depopulates the filter

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

GraphQL improvements for fine-grained PATs and GitHub Apps

Fine-grained PATs can now call the GitHub GraphQL API. This was a limitation at the start of the public beta, and is now supported.

Like with the REST API, the resource owner set for the token must match the owner of the resource being accessed. For example, when you want to look up a specific repository in GraphQL:

query {
  repository(owner:"octocat", name:"Hello-World") {
  ...

The resource owner would need to be octocat to succesfully run the query.

In addition, GitHub Apps now have read access to public resources via GraphQL by default when using user-to-server tokens. This is true even if they are not installed on the organization or user that owns the resource.

This change brings consistency to the access control between REST APIs and GraphQL APIs for GitHub Apps. We made similar changes previously for REST APIs which you can read more about here.

To learn more about GraphQL, see "About the GraphQL API". For more details about fine-grained PATs, see "Creating a fine-grained personal access token". And finally, to learn more about GitHub apps, see "Setting permissions for GitHub apps".

See more

Pre-fill form fields when creating a new repo

You can now create new repositories with pre-filled form fields, making it even easier to define the right info for your new repos from the start.
There are a number of query string parameters available, including:

  • name
  • description
  • visibility
  • owner
  • template_name
  • template_owner

To get started you can craft a query string at the end of https://github.com/new starting with ? followed by the fields and their values.

See the example below for more details:

https://github.com/new?owner=octocat&name=new-boilerplate&description=A%20new%20boilerplate%20repository&visibility=private&template_owner=actions&template_name=boilerplate

Learn more about Creating a new repository

We appreciate your feedback in GitHub's public feedback discussions

See more

GitHub Actions: Faster macOS runners are now available in open public beta!

XL macOS runners can now be used by any developer, without the need to sign-up! You can try the new runners today by setting the runs-on: key to macos-latest-xl, macos-12-xl, or macos-13-xl in your workflow file. The runners are available today to all customers!

More information about using the runner can be found here.
To learn more about runner per job minute pricing, check out the docs.

See more

GitHub Actions: macOS 13 is now available

The macOS 13 (Ventura) beta runner image is now available for GitHub-hosted macOS runners. You can try it today by setting the runs-on: key to macos-13 or macos-13-xl in your workflow file. The full list of software available for macOS 13 can be found here. If you see any issues with your workflows when using macOS 13, please create an issue in the runner-images repository.

More information about the runner can be found in our docs. To learn more about pricing, click here.

See more

One Click Into GitHub Codespaces

Codespaces has a number of new features to get you coding fast, from anywhere on the web, with a single click. Let's jump right in!

You can now add recommended secrets to a project when creating a Codespace!
Screenshot 2023-04-21 at 9 08 25 AM

Recommending secrets will ensure developers won't miss any API keys when creating a Codespace from your repo. You can specify any secrets you need to run your project in a Dev Container. If a developer already has a secret stored in their user secrets, Codespaces recommends they add the secret to their repository. Developers can worry less about setup and jump right into development!

Creating A Share Link & Resuming A Codespace

Do you want to share your project for others to try out? You can generate a share link to share in a tweet, add to your website, or send to a friend.
Screenshot 2023-04-21 at 9 09 24 AM

Want developers to pick up on the last Codespace they had when they clicked your share link? You can set your share links to drop developers into the same Codespace every time by selecting "Quick start."

You can select a specific Dev Container for the share link to create a codespace from! Codespaces detects the repo and branch from your repository, limiting your setup.
Screenshot 2023-04-24 at 10 45 11 AM

We've even made it easier to embed the share link into a nice "Codespaces" badge with HTML and Markdown. Nifty!

If your users have never created a codespace from your share link, they are recommended to create a codespace. If users already have a codespace from your share link, they are be prompted to resume their codespace.

Would a Dev Container by any other name smell as sweet?

You can now name your Dev Containers! By defining the property name in your devcontainer.json, you can set the name that will appear under the Dev Container selection on the Codespaces creation page. Even if you don't define the name property in your devcontainer.json, Codespaces will still infer a more useful name from your Dev Container file path.
Screenshot 2023-04-21 at 9 13 48 AM

Jumping Into Development From A Repository With A Comma

Do you want to collaborate on a repository, PR, or Branch? You can jump right back into your Codespace with the ',' key. No need to go to github.com/codespaces, or go to your Code<> drop-down to jump into development. Just one button and you're back to developing!

Learn More

Check out the docs:

Want to leave feedback? Make a post on our discussions page

Thank you!

See more

Enhancements for admins bypassing branch protections on github.com

When editing a file on github.com, repo admins, actors with the bypass branch protections permissions, and actors in bypass lists on branch protections will now default to creating a new branch instead for directly committing. You can still commit directly to a protected branch, but doing so will add notifications in-line highlighting that some rules will be bypassed.

Historically the default behavior was to push through any branch protections with no notifications they were being bypassed.

Now we recommend creating a branch for admins eligible to bypass branch protection rules. This behavior occurs when adding new files to a repository as well as during pull requests.

Screenshot of commiting directly to a repository
Screenshot of bypassing rules in a PR>

We appreciate your feedback in GitHub's public feedback discussions

See more
View more changes