Repository navigation
Consider a maintenance strategy for the Dependabot PR backlog #1092
Description
There are currently several open Dependabot pull requests that have accumulated without being merged or otherwise resolved.
Some of them are routine dependency updates, but others can also affect security findings in the current dependency graph. For example, #1081 updates Testcontainers to 4.14.0, which includes the SSH.NET dependency update addressing the vulnerability that is currently also visible in downstream builds.
Would it make sense to define a more explicit maintenance strategy for Dependabot PRs?
Possible approaches could include:
- periodically reviewing and merging passing Dependabot PRs;
- automatically merging passing patch/minor dependency updates where appropriate;
- keeping major updates subject to manual review;
- prioritizing dependency updates that resolve known security advisories;
- grouping related dependency updates to reduce the number of individual PRs.
The goal would not be to automatically accept every dependency update, but to prevent dependency PRs from accumulating indefinitely and to make security-related updates easier to get into main.
Would such a maintenance policy be useful for this repository?
Activity
ardalis commentedon Sep 10, 2026
Are there better tools available than dependabot, or configuration options for dependabot, that make this less of a maintenance headache/chore? I'm finding it's generally easier to run something like
dotnet outdated -uand make a single PR than to wade through a huge list of dependabot PRs for every little dependency. But that also requires local effort as opposed to letting a bot do it...MartinHock commentedon Sep 11, 2026
We tried Renovate in another .NET repository and had a good experience with it.
The main benefit for us was grouping non-major NuGet updates into a single PR while keeping major updates separate. That reduced the PR noise considerably without giving up control.
The initial setup took some effort, but once configured it worked reliably. So Renovate might be worth considering here, especially for grouped patch/minor updates.
MartinHock commentedon Sep 11, 2026
Quick follow-up: I put together a small proof of concept in my fork.
It runs Renovate against the pre-Dependabot state and is intentionally scoped to the root Directory.Packages.props.
Renovate created a single grouped PR for the non-major NuGet updates, while major updates remain under manual control:
MartinHock#93
The configuration is on the poc/renovate-grouped-updates branch.
This is essentially the workflow I had in mind for reducing the number of dependency PRs.
MartinHock commentedon Sep 13, 2026
Another option would be to keep Dependabot and use its built-in grouping.
We could group patch/minor NuGet updates into a single PR while keeping major updates separate:
groups:
nuget-non-major:
That would reduce most of the PR noise without introducing another bot or workflow.
I have already prepared a minimal implementation in my fork on the fix/dependabot-group-non-major branch. It changes only .github/dependabot.yml.
If this direction is preferred, I can open it as an upstream PR.
MartinHock commentedon Sep 14, 2026
Following up on the dotnet outdated -u idea: I also tried automating that approach in my fork.
I added a small GitHub Actions POC that runs dotnet-outdated with:
--upgrade --version-lock Major --pre-release Never
It validates that only Directory.Packages.props is changed and then creates or updates a single grouped update PR.
The workflow successfully created:
MartinHock#109
The resulting PR contains the current non-major NuGet updates, while major updates such as xUnit 3.x → 4.x remain out for separate review.
The POC is on the poc/dotnet-outdated-automated-updates branch.
This is probably the option closest to your current local workflow, but without the local/manual step and without introducing another dependency-update bot.
One limitation is that dotnet-outdated works from the projects in the solution, so packages present in Directory.Packages.props but not referenced by those projects may not be updated.
MartinHock commentedon Sep 29, 2026
Hi Steve, just following up on this.
Do you have a preference between the grouped Dependabot approach in #1093 and the automated dotnet-outdated approach from my fork?
I’d rather focus on one direction than keep both options moving in parallel.