Dependency graph supports all purl-identified package ecosystems

GitHub’s dependency graph now supports a wider range of package ecosystems, including transitive path information and the registered name of the ecosystem. This change increases the accuracy and usefulness of GitHub’s dependency insights, SBOMs, and API results.

The Package URL project provides a registry of software package ecosystems, with a standardized format for package type, namespace, version, and human-readable identifiers. With this release, graphs posted to the dependency submission API that include purl identifiers will now:

  • Correctly preserve transitive and direct relationships, if they were submitted.
  • Show the package ecosystem name in the Dependency Graph insights page.
  • Include the submitted package url in the GraphQL DependencyGraphDependency object, in the field packageUrl.

For searching and filtering, note that the top-level ecosystem type for all purl-identified packages is now other. These packages used to have the unknown type.

To begin using this feature, add a dependency submission action for a purl-supported package ecosystem you’re using in your repository. Then navigate to the repository’s Insights tab and select Dependency graph.

The dependency graph insights page, showing an ecosystem filter of other with three packages in a list.

VMware ESXi 8.0 hypervisor support is now available for GitHub Enterprise Server (GHES) 3.16.0, 3.15.4, 3.14.9, 3.13.12, and later. Until now, GHES was supported on ESXi versions 5.5 to 7.0. However, ESXi 7.0 is reaching the end of general support by October 2025.

If your GHES installation is on VMware ESXi 7.x or an earlier version, you can now use the ESXi 8.0 hypervisor. For more information about installing GHES on VMware, see install on VMware.

See more

Today we’re announcing recent fixes and enhancements to the improved pull request merge experience that became generally available earlier this month.

🆕 Status checks grouping preference

You can now choose to show the list of status checks as a single flat list or grouped by status. Click the settings gear and choose either “Group by status” (the default) or “No grouping“.

Image showing the new merge experience status checks section expanded with a new settings gear menu opened and showing 2 options for controlling how status checks are grouped (no grouping or grouping by status)

Recent fixes

Some of the noteworthy fixes that have landed in the last few weeks:

  • The time since a status check started (e.g. Started 2s ago) now updates consistently.
  • The Draft section was previously hidden for users without write access, making it difficult to know that the pull request was not ready for review.
  • A tooltip was previously not appearing when hovering over a truncated status check’s name, making it difficult to differentiate status checks with similar, long names.
  • Various fixes related to updating the pull request branch by rebasing.
  • Various improvements to performance, especially when there were a significant number of status checks.

Get help

To ask questions or provide feedback, join the discussion within GitHub Community.

See more