public-preview

Subscribe to all “public-preview” 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

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

As we work towards general availability of pull request merge queue, we want to thank everyone that has provided feedback (keep it coming!) and let you know about some recent fixes and new API support.

See the public beta announcement to learn more about merge queue and how it can help increase velocity by automating pull request merges into your busiest branches.

🆕 API support

You can now interact with merge queue programmatically using new GraphQL APIs. Add or remove a pull request from the queue, see which pull requests are queued, get details about a queued pull request, and more. For example:

Call the enqueuePullRequest mutation to add a pull request to the queue or dequeuePullRequest to remove a pull request.

Use the mergeQueue field on Repository to list its contents or configuration. Use the mergeQueueEntry field on PullRequest to get details about a queued pull request including its state, position in the queue, estimated time to merge, and more.

🐛 Fixes

Some of the more noteworthy fixes made since the public beta launch:

  • Fixed: GitHub Actions workflows would not trigger on merge_group events in some repos
  • Fixed: failing queued pull request would remain failing even after checks were rerun and and passed
  • Fixed: confusing “pushed a commit that referenced this pull request” message would appear in the timeline
  • Fixed: commits could be pushed to queue-created prep branches (note: these commits were ignored and not merged, but it created confusion for some users)

Get started

Interested in merge queue? Learn how to get started.

Questions or suggestions? Join the conversation in the merge queue public beta discussion.

See more

Commenting directly on a file in a pull request (not just a specific line) is now available in public beta! 🎉

With this capability you can now comment on deleted, binary (including images), and renamed files in a pull request. You can also comment generally about a changed code file without having to attach the comment to a specific line.

How it works

To comment on any file in a pull request, click the Comment on this file button in the header of the file (next to the Viewed checkbox):
image

Comments on files appear in the Files Changed and Conversation tabs and can be replied to and resolved like regular review comments.
image

Tell us what you think

This feature is currently in public beta, with GitHub Mobile and API support coming soon.

Join the discussion and let us know what you think!

See more

The GitHub Codespaces plugin for the JetBrains Gateway now supports Rider as a remote IDE. .NET developers can now leverage the standardization and power of GitHub Codespaces with JetBrains Rider’s singular code indexing, navigation, and debugging capabilities.

JetBrains Rider in Gateway

GitHub Codespaces support for Rider enables multiple solution file scenarios. If there is only one solution file in a given codespace, the GitHub Codespaces plugin will automatically select that solution file. If there are multiple, the plugin will prompt the user to select which solution file they intend to use to open their project. Repositories without solution files are still compatible with Rider, however some features will be limited when no solution file is selected.

Rider solution file picker

To get started with Rider, follow the documentation for installing GitHub Codespaces into the JetBrains Gateway. Once installed, users can connect to any of their existing codespaces with Rider as their selected IDE.

We are extremely excited to deliver our top requested feature since the beta announcement of JetBrains support in GitHub Codespaces.

Additional Resources:

See more

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

Today we are announcing the public beta of roadmaps in GitHub Projects! 🎉

Last November at GitHub Universe, we announced the private beta for roadmap. With your help and feedback over the last three months, we have shipped many exciting updates making it easier for you to visualize and plan your work over time, understand what is in progress or coming up next, and keep your team and stakeholders up to date.

image

🗺 Creating a roadmap

You can quickly build a roadmap alongside the same table and board views you already know and love.

When creating a roadmap, use existing date or iteration fields in your project to populate your items on the roadmap or create a new field from the Date fields menu. Set the zoom level to Month, Quarter, or Year depending on how granular you need your roadmap to be.

➕ Adding items and dates

Adding roadmap items works just like adding project items in any other view. Use the + Add item to search for or create a new issue, or type to create a draft placeholder. Once you’ve added the item, assign it to a specific date or within an iteration with a single click.

If plans change (which they often do!), you can adjust and move an item directly on the roadmap to reflect the new plan.

🎨 Customizing the view

Customizing your roadmap helps you create a tailored view for you and your teams. Select a group by field to segment and bucket your items by a custom field, such as status or team. This allows you to visually separate your items to understand both how they line up with each other and how long they all are expected to take.

Select a sort by field to further organize your roadmap, and specify a filter so that you only include relevant project items.

Tell us what you think!

We’ve got more improvements planned but we want to hear from you! Be sure to drop a note in the discussion and let us know how we can improve! Check out the documentation for more details.

If you would like to request access for the tasklists private beta to visualize the hierarchy of your items on the roadmap, sign up on the waitlist.

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

Security overview’s new risk and coverage views provide greater visibility into your security posture and risk analysis.

Each new view offers a refreshed design with several key improvements, including insights and dynamic filtering.

Coverage view

The coverage view gives visibility into enablement across all repositories. On the coverage view, you can:

  • See counts and percentages of repositories with GitHub security features enabled or disabled, which update when you apply filters
  • Track enablement for additional security features, including secret scanning push protection, Dependabot security updates, and code scanning pull request alerts.

security-tab-coverage-page

Risk view

The coverage view is complimented by a new risk view that gives visibility into all alerts across these repositories.
On the risk view, you can:

  • See counts and percentages of repositories with security vulnerabilities, which also update when you apply filters
  • See open alerts segmented by severity for both Dependabot and code scanning.

security-tab-risk-page

Both views are now available as a public beta. In the coming weeks, we will deprecate the overview in favor of these two new views.

Learn more about the new risk and coverage views and send us your feedback

See more

GitHub now supports the use of GitHub Codespaces with JetBrains IDEs via the JetBrains Gateway. After downloading the JetBrains Gateway and installing the GitHub Codespaces plugin, users will be able to connect to their codespaces with the JetBrains IDE of their choice.

jb-gateway

Once connected, users can leverage the full power of JetBrains’ IDEs in the cloud: fast, accurate code completion; integrated run and debug configurations; and unparalleled code navigation tools. Rather than needing to install each IDE on a developer machine, using GitHub Codespaces with JetBrains IDEs enables the use of any JetBrains IDEs in the cloud.

jetbrains-image

The beta supports connectivity to a codespace, private port forwarding, and a fully featured code editing experience in the following IDEs:

  • IntelliJ IDEA
  • PyCharm
  • WebStorm
  • GoLand
  • RubyMine
  • PHPStorm

Additional IDE support, codespace management tools (e.g. creation, deletion, changing the machine type), and better support for Development Container creation will be added as the beta progresses.

In order to connect to a codespace via the JetBrains Gateway, users will need the following:

Check out the documentation to learn more and get started.
For feedback or questions, create an issue in this repository and we will get back to you.

See more

GitHub is excited to announce support for using GitHub Codespaces with JupyterLab. JupyterLab is the next-generation user interface for Project Jupyter offering all the familiar building blocks of the classic Jupyter Notebook (notebook, terminal, text editor, file browser, rich outputs, etc.) in a flexible and powerful user interface.

JupyterLab in a Codespace

Using GitHub Codespaces with JupyterLab combines the delightful notebook editing, data exploration, and narrative building experiences of JupyterLab with the power, standardization, and simplicity of a codespace.

You can open any codespace in JupyterLab via the repository page or the GitHub CLI:

open in JupyterLab examples

You can also set JupyterLab as your preferred editor, enabling single click access to codespaces via JupyterLab:

set JupyterLab as default editor

JupyterLab support is even more powerful when combined with GPU-powered codespaces. Though GPU access is not yet generally available, you can request early access here.

Click here to learn more about GitHub Codespaces support for Machine Learning and AI, or jump straight into our template repository and try it out!

See more

an image showing a shipped project- bring projects to github mobile in mobile interface with text- projects on the go

Now more than ever flexibility is not only needed for how we work, but where we work. Stay connected and up to date on your work with GitHub Projects on GitHub Mobile, now in public beta. This marks the first milestone to bring GitHub Projects to your hands, so that you can track issues and projects from anywhere at any time. We would love for you to try it out on iOS TestFlight or Google Play (Beta) and give us your early feedback.

Let’s take a look at what you can do.

Access GitHub Projects

With GitHub Projects on GitHub Mobile you can quickly access the projects you need through a repository, organization, or your own user profile.

an image of quick navigation to access projects on mobile

Switch Views

You can view items as they’ve been configured and grouped and easily switch views on your projects to find what you need. Just tap on the title bar on top to pick a view from the pull-down menu. Project tables are rendered in a list layout for a simplified experience that still conveys all the necessary information you need for planning and tracking on the go. With collapsible buckets you can hide and reveal information as you wish for a better overview when you plan for a feature or track a sprint.

an image showing switching views in projects on mobile

Custom fields and quick actions

All your custom fields, such as status, category, priority, and iteration, are rendered as glanceable metadata pills in the list. Long-press on a project item to quickly edit these fields, delete the item, or preview its content so you can keep everything up to date and organized. Want to leave a comment on a specific issue? Simply tap on the preview and write a message in the issue detail view.

an image showing custom fields and quick actions to edit

Tell us what you think

GitHub Projects on GitHub Mobile is available today from Google Play (Beta) or iOS TestFlight.

There’s a lot more to come, and we’re excited to keep you updated as we make GitHub Projects on Mobile even better. In the meantime, we want to hear from you. Leave us your thoughts in GitHub Mobile Discussions, by tapping Share Feedback in your app profile, or reviewing our app in the Play Store or iOS App store.

See more

GitHub Advanced Security customers can now see an overview of code scanning alerts at the enterprise level. This page provides a repo-centric view of application security risks, as well as an alert-centric view of all secret scanning, Dependabot and now code scanning alerts. This view is beta and will be followed in the coming weeks with an enterprise level REST API to retrieve code scanning alerts.

Code scanning alerts at the enterprise level

Learn more about security overview
Learn more about GitHub Advanced Security

See more

GitHub Advanced Security customers can now see an overview of Dependabot alerts at the enterprise level. This page provides a repo-centric view of application security risks, as well as an alert-centric view of all secret scanning and now Dependabot alerts. The views are in beta and will be followed in the coming months by alert-centric views for code scanning.

Dependabot alerts at the enterprise level

Learn more about security overview
Learn more about GitHub Advanced Security

See more

GitHub Advanced Security customers can now view an overview of security alerts at the enterprise level. The new “Security” tab at the enterprise level provides a repo-centric view of application security risks, as well as an alert-centric view of all secret scanning alerts. Both views are in beta, and will be followed in the coming months by alert-centric views for code scanning and Dependabot alerts.

Security overview at the enterprise level

Learn more about security overview
Learn more about GitHub Advanced Security

See more

Organizations can now grant teams permission to manage security alerts and settings on all their repositories. The “security manager” role can be applied to any team and grants the team’s members the following permissions:

  • Read access on all repositories in the organization
  • Write access on all security alerts in the organization
  • Access to the organization-level security tab
  • Write access on security settings at the organization level
  • Write access on security settings at the repository level

Security manager configuration

Learn more about the security manager role

See more