From db480e740d9271cc0cb47097136fcf302af64837 Mon Sep 17 00:00:00 2001 From: Eliah Kagan Date: Wed, 9 Apr 2025 23:16:57 -0400 Subject: [PATCH] Enable grouped Dependabot version updates for Rust This enables Dependabot version updates for Rust dependencies, with all such updates grouped into a single PR, on a monthly cadence. When Dependabot version updates for Rust dependencies (i.e. the `cargo` ecosystem) were turned off in 5f2d28e for #144, Dependabot did not yet support grouped version updates. Clustering all the PRs to occur together once per month was possible, and it was considered and decided to be unsuitable, but that is different from a single PR to update multiple dependencies. The comment https://github.com/GitoxideLabs/gitoxide/discussions/143#discussioncomment-1089296 noted: > [...] bundling its updates and making it once a month or even > less often would be the preferred mode of operation. > > Right now I would be hesitant to change the schedule interval in > fear of an onslaught of PRs every month. > > On the other hand, there may be value in seeing each PR as it > contains release notes and changes[...] Using *grouped* Dependabot version updates satisfies each of those points: - The update PR can be set to occur once a month. (This is furthermore independent of the cadence for other ecosystems; it does not require that GitHub Actions version updates be only once a month.) - It is a single PR for all updates in the `cargo` ecosystems, not an onslaught of multiple PRs, so long as it is configured with a single group with which the exhaustive pattern `*` is associated. - The Dependabot pull request description includes any and all of release notes, changelogs, and commits since the release being upgraded from, for *each* of the dependencies being upgraded. Because we already have Dependabot security updates enabled, which are created immediately for any security advisory where Dependabot can upgrade the dependency, it should not be a problem to configure Dependabot version updates on a monthly cadence. This will include updates with breaking changes, so long as they're consistent with explicitly declared MSRV and other constraints. This shouldn't cause a problem, since CI is fairly robust, and will thus detect most breakages. When it is necessary to make changes to adapt to new versions, changes can be committed to the Dependabot feature branch for the PR (or other techniques can be used). To see what the first Dependabot PR after these changes is likely to look like, as well as what kind of commits to its feature branch are likely to fix it up to be ready to merge, see this experiment in a fork: https://github.com/EliahKagan/gitoxide/pull/18 --- .github/dependabot.yml | 6 ------ 1 file changed, 6 deletions(-) diff --git a/.github/dependabot.yml b/.github/dependabot.yml index 3dd899d8350..f3c7773dbfe 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -1,15 +1,9 @@ version: 2 updates: - # Only GitHub Actions dependencies receive Dependabot *version* updates. Rust dependencies are - # checked via `cargo deny` (https://github.com/GitoxideLabs/gitoxide/issues/144) and updated - # manually or via Dependabot *security* updates (which the restrictions here do not constrain). - package-ecosystem: cargo directory: '/' schedule: - # We include this required key, but it only applies to version updates, which are suppressed. interval: monthly - # Disable version updates for Rust dependencies. Security updates are still allowed. - open-pull-requests-limit: 0 commit-message: # Avoid non-"purposeful" prefix due to Dependabot misdetecting style (see `DEVELOPMENT.md`). prefix: ''