The Wayback Machine - https://web.archive.org/web/20240222214712/https://github.blog/changelog/2023-02-08-dependency-submission-suggestions-on-gradle-maven-scala-and-mill-repositories/
Dependency graph automatically supports many ecosystems, but some additional ecosystems require configuration to submit dependencies with the dependency submission API. The community maintains several GitHub Actions that make this easier.
Users with write access to Gradle, Maven, Scala, and Mill repositories now see messaging on their dependency graph that directs them to an action that will scan and submit dependencies for their ecosystem. Users with access to Dependabot alerts will also see messaging on their repository's Dependabot alerts tab.
Prompts will display if a repository includes any of the following files: pom.xml, build.gradle, build.gradle.kts, build.sbt, or build.sc.
The dependency graph team is working to have native support for these types of ecosystems with more news to come later this year.
You can now create a custom role to manage branch protections without having to grant the Admin role. Previously, to manage branch protections you had to be an Admin which provides additional permissions that may not be needed. For tighter control of Admin permissions, you can now craft a custom role that has the Edit repository rules permission, allowing just the right amount of access.
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.
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.
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.
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.
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.
