chore: group Dependabot updates and move them to monthly - #37
Merged
Conversation
A separate PR per dependency per week is a treadmill for a solo maintainer, and five simultaneously open bumps is what it produced. One group per ecosystem on a monthly cadence caps that at two PRs a month. Grouping matches on patterns alone. Splitting runtime from dev tooling would need `dependency-type`, which Dependabot documents as supported for pip but not uv — and a group that matches nothing falls back to one PR per dependency, which is the sprawl this is removing. Security advisories are unaffected: those are raised as they land, outside both this schedule and the grouping. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #36. Config-only; no source, test, or CI changes.
What changes
The five bumps currently open (#30, #31, #32, #33, #34) are what the weekly, ungrouped default produces for a solo maintainer. Under this config that same batch would have arrived as two PRs.
Why one group per ecosystem, not a runtime/dev split
My first draft split the uv entry into
runtimeanddev-toolsgroups viadependency-type, reasoning that a red lint-tool bump shouldn't hold a runtime bump hostage — which is precisely what a grouped Ruff 0.16.0 would have done to the typer bump.The options reference rules that out.
dependency-typeinside a group is "Supported by:bundler,composer,mix,maven,npm, andpip" —uvis not on the list. And "any outdated dependencies that do not match a rule are updated in individual pull requests," so a group matching nothing degrades straight back to per-dependency PRs.The motivating concern is also weaker than it looked: security updates are raised as advisories land, outside both the schedule and the grouping, and are explicitly exempt from open-PR limits. So a red grouped version-update PR can delay a routine bump, never a security fix.
Caveats
main.🤖 Generated with Claude Code