Dependabot feels a bit noisy

[goosys]

Does anyone else feel that Dependabot is a bit noisy in this repo?

Since this is a library, I don’t think we always need to update every dependency to the latest version right away. It also feels a bit off that PRs get a red ❌ just because the Dependabot security audit isn’t passing yet — that doesn’t seem very meaningful for most contributions.

I’d like to propose the following changes to the setup:

• Stop running the security audit as part of every PR
• Enable Grouped security updates in Dependabot so it doesn’t create so many separate PRs

What do you think about this?

[nickcharlton]

It is quite noisy, yeah. Because Actions is quite slow, sometimes it's all I can manage to look through (I timebox some regular notifications reviews, so I do it frequently).

I think I'd like to try dropping bundle audit from regular runs. Maybe keep it running on main, and on Dependabot updates? Just so there's enough opportunities to see it.

Then there's some grouped updates that are worth doing: Rails dependencies and Sentry are the first that come to mind.

Feel free to do either of them if you feel like it. Otherwise I'll take a look when I've got some time.

[nickcharlton]

I've been thinking about this again these last two weeks. I've been doing a bundle audit only dependency bumping approach on a side project, and when I created a new one yesterday for something else I also figured I'd keep following the same approach. It's actually working fairly well — at least when you've got few dependencies it's easy to keep on top of it.

I've also been thinking about the idea of dependency cooldowns quite a lot more, especially with recent LLM triggered vulnerabilities: https://grith.ai/blog/clinejection-when-your-ai-tool-installs-another

• https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns
• https://words.filippo.io/dependabot/
• https://nesbitt.io/2026/03/04/package-managers-need-to-cool-down.html

If we took this approach, we'd also need a solution for JavaScript dependencies, does any one know of a tool for that?

Plus, a regular review to keep non-vulnerable dependencies fairly up to date. I haven't figured that one out yet on my projects.

I think my concern is that trying to apply it here is a different situation and so the constraints don't apply. Thoughts?

[pablobm]

I agree. Our use of dependabot is overkill. The app is only an example app and doesn't warrant this pace of upgrades. The only real dependencies we have are in administrate.gemspec, and these last changed in 2024.

I think we should do one of these two:

1. Stop dependabot altogether. Run upgrades manually every now and then.
2. Enable grouped security updates. I've seen them used at OpenStreetMap (PR) and work well. I would even reduce the interval to be monthly.

On top of that, we could try implement some cooldown measures. Reading the article by Andrew Nesbitt, I understand the following:

• Yarn has now an option npmMinimalAgeGate to specify a cooldown period.
• gem.coop has an option to enforce a hard-coded 48 hour cooldown period.

Thoughts on these?

[goosys]

Since we are deploying the online documentation and the demo to Heroku, I still think Dependabot is useful, so I wouldn’t go as far as stopping it altogether.

Instead, it might be better to use grouped security updates, run them on a schedule, and then trigger them manually whenever something is merged into main. What do you think about operating it that way?

[nickcharlton]

Okay, nice, sounds like we're all on the same page. It sounds like the next move is to:

1. Switch to monthly grouped security updates on Dependabot
2. Explore cooldowns, which would mean moving to gem.coop, or seeing where these thoughts on adding cooldowns to Ruby Gems/Bundler goes.

If someone wants to try configuring 1., that'd be very helpful.

[nickcharlton]

We're trying out running weekly and with cooldowns since merging in: #3013.

Let's try that for a bit, and we can start a new discussion if we want to revisit it.