Dependabot frequency #144

Byron · 2021-07-30T00:14:35Z

Discussed in #143

^{Originally posted by edward-shen July 30, 2021}
While keeping up to date is a good thing, frequent updates create a lot of noise and can be annoying. Perhaps we can configure it to once a week, or once a month?

We can take larger period between dependabot checks because we already run cargo deny in CI, so any urgent issues will be noticed quickly, where we manually update.

https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#scheduleinterval

The text was updated successfully, but these errors were encountered:

A number of reusable actions, such as actions/checkout, are in old major versions, including versions that use old deprecated versions of Node.js, such as Node 16 (rather than the current Node 20). Dependabot version updates were disabled for Rust crates in GitoxideLabs#143 and GitoxideLabs#144, with other means used to keep things up to date. This does not reverse that even partially, as it enables version updates only for GitHub Actions (which it has not been used on before). Because most actions are specified with major version tags that get reset to the latest stable minor/patch version under that major version, the actual frequency of updates should not be anywhere near daily. Nonetheless, it may make sense to further refine this configuration, such as to check for updates less often as well as to group multiple updates into a single PR when doing so.

In the past (GitoxideLabs#143), Dependabot version updates had been used to keep `cargo` dependencies up to date. This was removed in favor of doing manual updates based on automatic reports from `cargo deny` and the old `dependabot.yml` was kept but renamed to disable it and point people to GitoxideLabs#144 to learn about the change. Since then, Dependabot security updates, which are distinct from Dependabot version updates, were enabled (see GitoxideLabs#1254), and later, Dependabot version updates were reintroduced for GitHub Actions only (GitoxideLabs#1357). At that point, there were two Dependabot-related YAML files: the old disabled one, and the new one for GHA. This removes the old one, explaining the situation in a comment in the new one, including a link to GitoxideLabs#144. While doing so, this also adjusts the YAML code style there, to bring it in line with the style of most other YAML files in the repository.

This enables grouped version updates for Rust dependencies, on a monthly cadence. When Dependabot version updates for Rust dependencies (i.e. the `cargo` ecosystem) where turned off in 5f2d28e for GitoxideLabs#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 GitoxideLabs#143 (reply in thread) 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 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: #18

This enables grouped version updates for Rust dependencies, on a monthly cadence. When Dependabot version updates for Rust dependencies (i.e. the `cargo` ecosystem) where turned off in 5f2d28e for GitoxideLabs#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 GitoxideLabs#143 (reply in thread) 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: #18

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) where turned off in 5f2d28e for GitoxideLabs#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 GitoxideLabs#143 (reply in thread) 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: #18

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 GitoxideLabs#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 GitoxideLabs#143 (reply in thread) 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: #18

Byron closed this as completed in 5f2d28e Jul 30, 2021

EliahKagan mentioned this issue May 7, 2024

Use Dependabot version updates but just for GitHub Actions #1357

Merged

EliahKagan mentioned this issue Nov 11, 2024

Improve CI permissions, auto-merge maintainability, and clarity #1668

Merged

EliahKagan mentioned this issue Apr 10, 2025

Bump the cargo group across 1 directory with 21 updates EliahKagan/gitoxide#18

Closed

EliahKagan mentioned this issue Apr 11, 2025

Enable grouped Dependabot version updates for Rust #1948

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Dependabot frequency #144

Dependabot frequency #144

Byron commented Jul 30, 2021

Dependabot frequency #144

Dependabot frequency #144

Comments

Byron commented Jul 30, 2021

Discussed in #143