+1 to quieting dependabot. it mostly just creates neverending busywork. better to try to use it more strategically as you suggest.
On Tue, Feb 4, 2025 at 6:45 PM Cole Greer <cole.gr...@improving.com.invalid> wrote: > Hi everyone, > > I wanted to kick off a discussion around dependabot in our repo as I don’t > think > the current configuration is beneficial for us. As it currently stands, > the repo is > permanently cluttered by 30+ dependabot PRs. I tend to group the > dependabots > into 3 buckets: > Trivial: (requires minimal work to evaluate and accept) > Moderate: (requires follow-up investigations into potential conflicts, > licensing > concerns, or breaking changes) > Blocked: (upgrade cannot proceed without conducting some major piece of > work) > > I think for each of these groups, we would be better served by some > alternative > process. > > Instead of the current flood of trivial dependabots, it would be more > efficient to evaluate minor version bumps for dependencies roughly once per > release cycle. This could either be done by adding this as another task > for the > release manager, or it could be approximated by reconfiguring dependabot to > only run once per quarter for minor version bumps. > > Instead of having major version bumps (often involves breaking changes) > targeting > maintenance branches (eg 3.7-dev), they should at the very least be moved > to only > target master. I would argue that most of these pending major upgrades are > better > served as JIRAs than dependabot PRs as the actual upgrade requires > substantial > changes which aren’t covered by the dependabot. One example of the current > process failing here (and what motivated this email) is Stephen’s recent PR > upgrading to slf4j 2. We have had an open dependabot PR for this upgrade > for over > a year, which has been completely ignored until the upgrade was completed > independently. It’s clear that dependabot isn’t adding any value for us in > such cases. > > One final change I want to suggest is that we open a ticket with infra to > see if we can > enable dependabot security alerts in our repo. This could serve as a > useful warning > mechanism for security vulnerabilities which we are currently missing. > > I would be interested to gather feedback on where people think dependabots > are and > are not valuable, and if there are any additional suggestions to improve > our processes > or reduce clutter. > > Thanks, > Cole >
