Skip to content

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

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

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

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

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

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

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

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

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

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

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

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!

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

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

For GitHub Enterprise Cloud customers, team sync no longer invites members to organizations by default. For existing team sync customers we have added a configuration option to disable automatic organization provisioning for users that are synced from your identity provider groups. Team sync will not remove users from an organization when they are removed from a team.

For additional information and instructions to opt out of the default behavior, learn more in our team sync documentation.

See more

GitHub today announced public beta support for custom deployment protection rules for safely rolling out deployments using GitHub Actions.

Custom deployment protection rules are powered by GitHub Apps and can be enabled on any GitHub org/repo/environment to allow external systems to approve or reject deployments.
Each rule evaluates specific conditions in those external systems to assess the readiness of the environments for automated deployments, making them less risky and more robust.

Starting with this public beta, GitHub Enterprise Cloud (GHEC) users can create their own protection rules to control deployment workflows and, if desired, share them by publishing their apps to the GitHub Marketplace.
You could also install official apps for deployment protection rules from various external partners to define security, compliance and governance related conditions in their services that can be used to control deployments with Actions workflows.

Two custom deployment protection rules enabled on a production environment

Learn more about creating and configuring custom deployment protection rules to set up rigorous, streamlined guardrails for your deployments that ensure only the deployments that have passed all quality, security, and manual approval requirements make it to production.

For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.

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

npm packages built on a cloud CI/CD system (like GitHub Actions) can now publish with provenance, meaning the package has verifiable links back to its source code and build instructions.

The cloud CI/CD system securely communicates this information by sending provenance information in a signed OIDC JWT to Sigstore's public-good servers, which returns a signing certificate that is sent to the registry along with your built package.

Here's an example of how to do a build with provenance in a GitHub Actions workflow:

name: Publish Package to npmjs
on:
 release:
   types: [created]
jobs:
 build:
   runs-on: ubuntu-latest
   permissions:
     contents: read
     id-token: write
   steps:
     - uses: actions/checkout@v3
     - uses: actions/setup-node@v3
       with:
         node-version: '18.x'
         registry-url: 'https://registry.npmjs.org'
     - run: npm install -g npm
     - run: npm ci
     - run: npm publish --provenance --access public
       env:
         NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Once published, packages display provenance on the registry website:

Provenance displayed on the registry website

Dependencies with provenance can also be verified from the command line with npm audit signatures.

For more information, see generating provenance.

See more

On March 30, 2023, we fixed a bug that allowed a dependency graph hovercard URL to be used to retrieve the name, description, and star count of any repository on GitHub.com. The bug was introduced on March 28, 2023 and our investigation has found no evidence of exploitation. To exploit the bug, a specific header needed to be set when making a request to the URL and the numeric ID of a repository provided. The URL would then return the HTML content designed to be used for a hovercard UI element with the repository name, description, and star count in the response.

This bug was reported to GitHub via the GitHub Bug Bounty program.

See more