Configuration of a minimum package age required before a PR is created

[ericmatthys]

A "cooldown" feature would delay opening a PR for a newly updated dependency until a certain amount of time has passed. This feature could help teams with mature / stable projects that would like to be more conservative with dependency updates, but still stay on top of regular updates. A cooldown period would allow for patch updates after a release without impacting the project or creating excess noise. Also, for packages that update very frequently, a cooldown period could help cut down on noise from that project without changing the entire schedule to be slower. It would also be useful to allow the cooldown time to be configurable for different semver versions. For example, I might set semver-major to 1 month, semver-minor to 1 week, and semver-patch to 3 days.

Here's how a config snippet might look:

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
      cooldown:
      - semver-major: 30
      - semver-minor: 7
      - semver-patch: 3

Here's a scenario using those values in mind:

1. Package updates from 1.1.0 to 1.1.1
2. 3 days pass
3. PR for 1.1.1 is created
4. Package updates from 1.1.1 to 1.2.0
5. 2 days pass
6. Package updates from 1.2.0 to 1.2.1 with a bug fix
7. 1 day passes
8. Package updates from 1.2.1 to 1.2.2 with a bug fix
9. 4 days pass
10. PR for 1.2.2 is created
11. Package updates from 1.2.2 to 1.3.0
12. 3 days pass
13. Package updates from 1.3.0 to 1.4.0, resetting the cooldown because it's another minor update
14. 7 days pass
15. PR for 1.4.0 is created

[asciimike]

Hah, this is actually an option we looked at when thinking about https://github.com/dependabot/dependabot-core/issues/2219. It's not on the near term roadmap, but definitely makes sense and something we'd be interested in adding in the future.

[hiqua]

This feature would be very welcome.

Beyond having less PRs from frequently updated projects, there's also the problem of how many of them are even relevant when several libraries used in the same project are made incompatible with each other in a version bump.

If A v1 and B v1 are currently used:

1. A goes from v1 to v2
2. B v1 is compatible with A v1 but not with A v2
3. B has not anticipated A v2, but will introduce fixes later in B v2

An open PR is basically TODO item, but in this case the best course of action is often to wait right after A v2 release, in case 3) happens and the version bump is less painful that it seemed at first glance. And if 3) doesn't happen, then a manual fix can be done. But opening the PR right after A v2 release is premature.

In short, I'd much rather have PRs open when I'm reasonably certain I have to do something if they don't pass the CI (rather than just leaving them open and wait for $n days to give a chance for the issue to fix itsel).

[ZackKanter]

We need this as well. FWIW, Snyk's default/non-configurable behavior is a 21-day delay:

Snyk does not recommend upgrades to versions that are less than 21 days old. This is to avoid versions that introduce functional bugs and subsequently get unpublished, or versions that are released from a compromised account (where the account owner has lost control to someone with a malicious intent).

This setting cannot be overridden. It would be very nice to have this a configurable option in dependabot.

[ZackKanter]

Renovate calls this stabilityDays.

[limonte]

Yes please!

When a vulnerability is introduced to an npm package, it takes at least several days to discover the vulnerability and to report the vulnerable release to security databases (npm, Snyk, dependabot, etc.)

Because of that reason, it would make sense for developers to use 3rd party dependencies with the version that matches these conditions:

• as latest as possible (the obvious one)
• free from vulnerabilities, i.e. not present in npm/Snyk/dependabot security databases
• X days mature, because of the reason mentioned above - it takes time to discover and report vulnerabilities

[L1ghtman2k]

We have multiple production environments of different maturity, and we use gitops model to deploy our changes to the clusters(So, Dependabot is a big part of it).

It would be nice to have Dependabot update production clusters of the highest maturity only after the first two environments have been updated(one way I could see this achieved is via this feature request)

[JacobEvelyn]

Just sharing that given the increasing frequency of sophisticated supply-chain attacks, over the past few years this feature has gone from nice-to-have to a necessity for us.

We're planning on hacking together this functionality on top of Dependabot PRs using the GitHub API, but it will be a pain because there's so much more state to manage (e.g. PRs open but not yet at the cooldown period, GitHub labels, branch rules, etc.) than there would be if this was a first-class Dependabot feature. Even just adding it ecosystem-by-ecosystem would be very welcome.

@jeffwidman would Dependabot be open to PRs that support this feature for a given ecosystem? For example, the RubyGems API call Dependabot is makes returns published timestamps (example) and it looks straightforward to change the Gem::Version objects we create from that API response to a duck-type that can also provide timestamps, and use those to determine whether to create a PR. Even if the feature doesn't yet support private registries/etc. or every ecosystem, this would still be very valuable to us. We could even beta-test it as an undocumented config setting. We might be able to make a PR for this but won't bother if it has no hope of getting accepted.

[JacobEvelyn]

@jeffwidman just pinging you again on this question ☝️ (or let me know if there's someone else I should ask).

[IvanRibakov]

Agree with @limonte and @JacobEvelyn that while initially this feature was presented to be about stability and noise, it has far more importance from the security point of view. You might think that if Dependabot PR with compromised dependency is created, the impact is small until the PR is merged + there may be additional delay until that merge commit is released. However the damage from the pwn requests coming from compromised dependencies is going to be instantaneous as soon as the Dependabot PR is created and the CI workflow is kicked off. So for those use cases when other recommendations for mitigating pwn requests are not feasible, the last thing that is left is to try to delay the introduction of new dependency versions.

Please consider security implications of lacking this feature and consider increasing it's priority in the backlog.

[fallemand]

Any update over this feature request? 🙏