Transitive dependencies are now available for Maven

Following the ship of transitive labeling for npm packages, the same capabilities are now available for Maven packages:

  • Dependabot alerts now contain a direct label if they are associated with a package you’ve directly included. In addition, there’s now a relationship:direct filter in the search bar to only show those alerts caused by your direct dependencies.
  • The direct dependency that led to a package’s inclusion in your dependency graph is visible both in the text of any new Dependabot alerts and the dependency insights page (click the … button, then Show options to view it).
  • A repository’s SBOM will contain a relationships section that uses the SPDX relationshipType: DEPENDS_ON field to express the tree of package dependencies. Similarly, the GraphQL API will now return a relationship field with direct, transitive, or unknown values in the DependencyGraphDependency object.

Ability to refresh Dependabot alerts from the list view

In addition to the Maven-specific additions, the Alert Settings menu on Dependabot alert tables now provides a Refresh Dependabot alerts option which will rescan your repository’s manifest files, rebuild its dependency graph, and refresh its open Dependabot alerts.

New 'Refresh Dependabot alerts' option in the Alert Settings menu on the Dependabot alerts page.

Getting started

To get transitive dependency labeling on your repositories, make sure dependency graph is enabled, and either enable Automatic dependency submission on the same settings page or use a dependency submission action. As a beneficial side-effect of this change, other package ecosystems with actions that create transitive dependency trees – such as go – will also now receive transitive and direct labels.

To see the Dependabot labels, you’ll also need to enable Dependabot alerts.

Join the discussion within GitHub Community.

Enterprise custom properties, enterprise rulesets, and pull request merge method rule are all now generally available

An image on a dark background with collaboration-themed colors, showcasing GitHub products. In the forefront, enterprise rulesets and custom properties are highlighted alongside a side angled profile of Mona the Octocat.

Enterprise custom properties and enterprise rulesets are now generally available, further improving the governance features for GitHub Enterprise customers.

Enterprise custom properties

With enterprise-level custom properties, you can now enrich your repositories with metadata across your entire enterprise. This ensures consistent properties across organizations without the need for manual synchronization. By sharing a common namespace, enterprise and organization properties prevent confusion when searching or targeting rulesets with properties. If you’re already using custom properties in your organizations, you can also promote those properties to the enterprise.

Learn more about enterprise custom properties in our documentation.

Enterprise rulesets

Enterprise-level rulesets enforce consistent code governance rules, helping ensure thorough reviews of critical repositories with pull requests, requiring actions workflows, protecting important locations from unauthorized pushes, and more. Rule insights and push rule bypasses are also available at the enterprise level, providing complete visibility into the rulesets.

Learn more about enterprise rulesets in our documentation.

We look forward to seeing how you leverage these new capabilities to streamline your workflows and maintain high standards of code governance.

Pull request merge method rule

An image of GitHub products displayed against a dark collaboration-themed background. In the foreground, there is text saying "Pull request merge method rule generally available", with Mona the Octocat looking at the title in a side-angled profile image.

The new pull request merge method rule is now generally available using whatever method is suitable for your branches, such as ensuring that all changes are squashed when merging to the default branch while rebasing into feature branches. This simplifies your workflows, ensuring consistency across your branches.

The merge method rule is available for rulesets at the repository and organization level. You can use this rule to choose what merge methods are allowed on the targeted branches when merging pull requests from the user interface or APIs. You can choose between merge commit, squash, or rebase.

Learn more in our documentation and join the discussion within the GitHub Community.

See more
View all changes