Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to monthly Dependabot schedule #10351

Open
PyvesB opened this issue Jul 12, 2024 · 1 comment
Open

Switch to monthly Dependabot schedule #10351

PyvesB opened this issue Jul 12, 2024 · 1 comment
Labels
dependencies Related to dependency updates developer-experience Dev tooling, test framework, and CI needs-discussion A consensus is needed to move forward

Comments

@PyvesB
Copy link
Member

PyvesB commented Jul 12, 2024

Do our users really benefit from us having bumped @typescript-eslint/parser six times since the start of June? Or eslint-plugin-jsdoc and @sentry/node five times? And many other consecutive weekly version bumps?

Going through third-party changelogs, sometimes testing in a review app, and approving PRs every week feels like an unwelcome maintenance overhead, especially in a world where there are only one or two Shields.io maintainers active at any given time. Furthermore, it bloats our commit history and uses CI resources for no good reason.

I propose we switch to a monthly schedule, which will allow to batch multiple version bumps together for packages that are a bit too update-happy, lessening the overall burden.

I had already suggested this a few years ago, but a maintainer had pointed out that simple-icons would benefit from staying on a weekly schedule. Dependabot does not officially support multiple schedules for the same directory, but there is apparently a workaround mentionned here: dependabot/dependabot-core#1778 (comment). We could give it a try, and if ever it stops working in the future, we revert back to the original Dependabot config.

@chris48s as you've taken care of 95% of the Dependabot updates in the past couple of years, would be curious to hear your thoughts.

@PyvesB PyvesB added developer-experience Dev tooling, test framework, and CI dependencies Related to dependency updates needs-discussion A consensus is needed to move forward labels Jul 12, 2024
@chris48s
Copy link
Member

Yeah it is a good challenge. We've been doing things this way for so long that I haven't really thought to question it recently. Here's a few thoughts:

  • You are right that there are a small number of packages that account for a lot of PRs. As you say, we bump eslint-plugin-jsdoc, @typescript-eslint/parser, @sentry/node, etc every week and don't get much out of it.
  • People do really get worked up about simple-icons updates, but I think that is the only package with that property really.
  • One useful property of weekly updates is that it requires time "little and often". I can bash though a week's worth of updates in about an hour usually. Finding an hour a week isn't too cumbersome or daunting. Working though a month's worth of updates probably wouldn't be 4x the effort and you don't have to do them all at once, but I feel like it requires finding a larger block of time (albeit less frequently).
  • Another good thing about weekly updates is that one week's worth of updates doesn't tend to generate enough PRs at once that rate limits on tokens are a problem. With a month's worth of updates at once, we might start running into builds failing because we've hit rate limits again when we are running a lot of builds on PRs, in the merge queue, and after merge. I fixed a lot of these issues with fixes for integration test rate limit issues #8538 and remove pull_request:edited trigger from most workflows #9072 but there is some limit on how many builds we can run in a one hour window.
  • Switching the schedule shouldn't have any impact on security. We can tell dependabot to treat security updates differently from regular package bumps.

All in all, I don't consider things to be unnecessarily cumbersome as they are. At the same time, I'd be willing to try out a less frequent schedule (monthly, or perhaps fortnightly?) and see how it goes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Related to dependency updates developer-experience Dev tooling, test framework, and CI needs-discussion A consensus is needed to move forward
Projects
None yet
Development

No branches or pull requests

2 participants