dependabot

Dependabot version updates help you keep your dependencies up-to-date by opening pull requests when dependencies can be upgraded. With today's release, you can now use flexible grouping options in dependabot.yml to take control of how Dependabot structures its pull requests to make them more mergeable for you based on your context. Whether you'd like to simply update as many dependencies at once as possible (patterns: *) or minimize the risk of breaking changes (dependency-type: development or update-types: "patch"), there are grouping options for you.

Until today, Dependabot would always open individual pull requests for every dependency update in accordance with your configuration in dependabot.yml. Not only can this result in a large number of Dependabot pull requests, but there are some dependencies which must be updated in tandem with each other or the update will fail. In these cases, the individual Dependabot pull requests would always fail until you manually intervened to do the update.

The available grouping options are:

• patterns, which will match based on package names
• dependency-type, which will group based on development or production dependencies, for ecosystems where this is supported, and
• update-types, which will group based on SemVer level update

At this time, grouping is not available for security updates or Dependabot alerts.

Learn more about grouping configuration options here

Dependabot can now open pull requests to resolve alerts for your Gradle dependencies! If you have used the dependency submission API to upload your Gradle dependencies to the dependency graph and are receiving Dependabot alerts for those dependencies, Dependabot will now try to open a pull request to resolve them automatically if you have security updates enabled for your repository.

• Learn more about Dependabot security updates
• Learn more about the dependency submission API
• Learn more about the Gradle build action

If you are using Dependabot grouped version updates (currently in public beta), you can now group your pull requests by semantic version update level. This addition is designed to help reduce the risk of introducing a breaking change through an update.
To use this new functionality, add a new update-types key in your group rule, as shown below:

groups:
  angular:
    patterns:
    - "@angular*"
    update-types:
    - "minor"
    - "patch"

The update-types key accepts values "major," "minor," and "patch," following the SemVer structure of major.minor.patch.

This new key works alongside existing grouping parameters such as patterns, dependency-type, and exclude-patterns, allowing you to fine-tune the grouped pull requests that Dependabot creates for you!

Learn more about configuring grouped Dependabot version updates

If you are using the Dependabot grouped version updates feature (currently in public beta), you can now tell Dependabot to ignore updates in the group (similar to how you can do it for Dependabot's individual updates). While closing a grouped pull request will still not create ignore conditions, you can use Dependabot comment commands to tell Dependabot to ignore certain updates in the group – either a specific minor update, a specific major update, or all updates for one dependency.

On a grouped pull request, you can now also tell Dependabot to stop ignoring certain updates that you have already ignored. By commenting @dependabot unignore, you can specify either to stop ignoring a specific range of updates, all updates for a specific dependency, or all updates for every dependency in the group. Dependabot will now also list in the pull request body all the ignore conditions it used to build the pull request. Alternatively, you can comment @dependabot show <dependency-name> ignore conditions and Dependabot will list the ignore conditions for that dependency.

For more information on Dependabot ignore conditions and chat commands, please see the documentation.

If you are using the Dependabot grouped version updates feature (currently in public beta), you can now group your pull requests by dependency type in ecosystems that support this. Instead of listing all the dependencies by name or pattern for your groups, you can now also use the dependency-type key (set to either "production" or "development") to create groups based on dependency type. Then, on your version updates schedule, Dependabot will try to open one pull request to update all available dependencies of that type.

For more information on how to use this feature, check out our documentation on configuring groups for Dependabot pull requests.

Dependabot can now open pull requests to update your Swift dependencies. In June, support for Swift advisories in the Advisory Database and Dependabot alerts was released. Dependabot will now be able to open pull requests to fix related alerts, and you will also be able to configure scheduled updates for your dependencies via dependabot.yml.

For more information on how to configure Dependabot updates, please view our documentation here: https://docs.github.com/en/code-security/dependabot

Dependabot version updates helps you keep your dependencies up-to-date by opening pull requests when dependencies can be upgraded. With today's release, you can now group version updates by dependency name.

Until today, Dependabot would always open individual pull requests for every dependency update in accordance with your configuration in dependabot.yml. Not only can this result in a large number of Dependabot pull requests, but there are some dependencies which must be updated in tandem with each other or the update will fail. In these cases, the individual Dependabot pull requests would always fail until you manually intervened to do the update.

Now, in your dependabot.yml configuration file, you can set custom grouping rules for Dependabot based on pattern matching on package name. Here is an example of how these rules can be set up:

version: 2
  updates:
  - package-ecosystem: "bundler"
    directory: "/"
    schedule:
      interval: weekly
    # New!
    groups:
      # This is the name of your group, it will be used in PR titles and branch names
      dev-dependencies:
        # A pattern can be...
        patterns:
          - "rubocop" # a single dependency name
          - "aws*"  # or a wildcard string that matches multiple dependencies
          # If you'd simply like to group as many dependencies together as possible, 
          # you can use the wildcard * - but keep in mind this may open a very large PR!
        # Additionally, you can specify any dependencies to be excluded from the group
        exclude-patterns:
          - "aws-sdk"

This configuration applies to regularly scheduled Dependabot version updates only. Security updates for Dependabot will continue to open as individual pull requests, even if they match a configured grouping rule.

This feature is in beta, so you may encounter instability and the feature-set is currently limited. You may file any bugs encountered in the dependabot-core repo.

To learn more about grouping rules for Dependabot version updates, please refer to our documentation.

Suppressed notifications for Dependabot alerts at enablement time

At first time enablement, Dependabot will no longer send web or email notifications that summarize when a repository is populated with Dependabot alerts. Now, you'll have visibility across all your Dependabot alerts without immediately notifying developers who watch security alerts across your repository or organization. This change applies across all levels: repository, organization, and enterprise.

For any developers both watching a repository and opted in to receive Dependabot alert notifications, future notifications will still be sent for incoming alerts after enablement, as well as for daily and weekly digests.

About this change

We’ve been working to steadily improve our security alert notifications. As part of our notification strategy, notifications will no longer be sent at first time enablement for Dependabot alerts. Notifications are muted across all levels of enablement: repository, organization, and enterprise.

This change does not affect email digests or notifications on newly created alerts after enablement.

Available alert notifications and indicators

Today, when a dependency-based vulnerability is detected, Dependabot lets you know based on your user notifications settings and repository watching settings. You can opt to receive:

• Web-based notifications on alerts in your GitHub inbox
• Email-based notifications on alerts
• Email digests (weekly or daily roll-ups of alerts).

From the UI, you can also use the "Security" alert count in your repository navigation as an indicator for when your repository has alerts. This Security tab includes the count for all active Dependabot alerts, code scanning alerts, secret scanning alerts, and any security advisories that you have permissions to view.

Learn more about Dependabot alerts and configuring notifications for alerts.

Sometimes, due to misconfiguration or incompatible versions, Dependabot jobs for a repository will fail and Dependabot will continue to run and continue to fail. Now, after 30 failed runs, Dependabot will immediately fail subsequent scheduled jobs until you trigger a check for updates from the dependency graph or by updating a manifest file. Dependabot security update jobs will still trigger as usual.

• Learn more about Dependabot

When changes in a repository make a Dependabot pull request out-of-date, Dependabot will automatically rebase it so that it is able to be merged without your manual effort. With this release, if a PR has not been merged for 30 days, Dependabot will stop rebasing it and will include a note about this in the PR body. You will still be able to manually rebase and merge the pull request. We've heard your feedback about Dependabot noisiness and are making Dependabot quieter and more focused on repositories you care about. For enterprise customers, this improvement has the added benefit of enhanced efficiency with your self-hosted GitHub Actions runners. For Enterprise Server customers, this update will be available to you in GHES 3.10.

• Learn more about Dependabot pull requests

You can now fetch release notes, changelogs and commit history for Docker update pull requests with Dependabot. This will allow you to quickly evaluate the stability risk of the dependency upgrade. To enable support, add the org.opencontainers.image.source label to the Dockerfile with the URL of the source repository. Additionally, the repository should be tagged with the same tags as the published Docker images. This allows Dependabot to understand which repo and commit is associated each version/tag of a Docker image. Here's an example repository demonstrating this setup.

Did you know? Dependabot's internal library for identifying dependency updates is open source. If you notice a Dependabot pull request is missing metadata, you can leverage the transparency of open source to debug the root cause – for example, if the package maintainer needs to fix their metadata annotation.

• Learn more about Dependabot

If you use Gradle Version Catalogs to centralize managing dependencies for a Gradle project, you will now be able to use Dependabot version updates to keep these dependencies up-to-date!

You can read more about what ecosystems are supported by Dependabot here