Dependabot-core: Lag time before release

[ianwremmel]

Given the social engineering attacks that we've been hearing about lately, it would be nice to be able to delay an update. maybe something like:

1. open an issue according to current bump schedule rules
2. after 1 week, open pull request

alernatively,

1. open PR according to current bump schedule
2. automerge after delay

[greysteil]

Sorry for the slow reply on this one. I'm interested in adding delays to PR creation / automerging, but first want to ship config file support for Dependabot (which we've been crunching on for the last week or so - should go out this week)

[ianwremmel]

Makes sense, thanks for the update!

[connorshea]

https://twitter.com/garybernhardt/status/1093326386465361920?s=21 ;)

[martingjaldbaek]

Just chiming in that this is pretty much the only feature I'm missing from dependabot :)

I'd also like to add that it'd be ideal if it could be configured to still create PRs for 0-day security fixes, while still delaying everything else.

Another question for me is whether newer releases should preclude older releases from getting PRs opened. E.g. I have a delay of 7 days set, version 1.0.2 of a dependency came out 7 days ago, but 1.0.3 came out yesterday - should the presence of release 1.0.3 prevent dependabot from opening a PR for 1.0.2? I think so, since it's likely that 1.0.3 fixes a bug that was introduced in 1.0.2. Catching these sorts of scenarios and avoiding the buggy release completely is exactly why I want this feature, so just always delaying the PR for the buggy version by a week doesn't help. But maybe it should be tied to the patch part of SemVer, so 1.0.3 supersedes 1.0.2 and prevents it from getting a PR, but a 1.1.0 or 2.0.0 release would not.

I guess in theory with a system like that, a dependency might keep not getting updated if they just keep adding patch versions fast enough - if so this could be solved by having an 'If no PRs have been opened for Y days, open one for the latest release that is older than X days' fallback (though that might be overengineering, dunno - I guess you probably have data to tell you if this has historically ever been a possible issue).

[Santas]

This would be amazing to have.

[gingerlime]

Also curious about this... What happens if I close a PR for a version update I'd rather wait with? would it be re-opened later?

For example, I just got a PR open to upgrade Puma from 3.x to 4.0.0 (released 20 hours ago). Now, I'm sure Puma has a great track record, but personally I'm probably happy to wait until 4.0.1 or something :) Can I just close the PR and wait until 4.0.1 then? or would the PR get re-opened during the next schedule?

[greysteil]

@gingerlime - if you close the PR then Dependabot will open you a new one when 4.0.1 is released.

[gingerlime]

@greysteil that's good to know! Thank you!!

[swallenfriedman]

Not sure if this one's still on the table, but this would be awesome to have!

[rebelagentm]

Hi! 👋 We still have the issue open, but the team is heads down for the next few months scaling Dependabot for all of GitHub :octocat:, so it may be a while before we get to work on this.

[ms-ati]

Hi awesome Dependabot team -- here's a real world example where the need for this feature but us. Dependabot had us upgrade to Sidekiq Pro 5.0.1 / Sidekiq 6.0.2, which caused bugs in production that Mike Perham was able to fix quickly (thanks!).

However, he (author of Sidekiq) explicitly recommends _"that you hang back and give a major release time to "settle" and shake out any bugs"_ (see comment here)

So it would be most helpful if Dependabot could be configured to hang back on major version releases of Sidekiq?

[gingerlime]

just my 2 cents, but from my experience after starting to use dependabot:

As a rule of thumb: I would generally recommend just closing most major upgrade PRs from dependabot (e.g. 5.x.x -> 6.0.0 I would just close). And let dependabot remind you when there's a 6.0.1 is released... (or even 6.0.2 or 6.1.0)

I think major versions tend to have breaking changes and then smaller fixes. Unless you're working on the project or really need the bleeding-edge feature right away, holding back will improve how you sleep at night :)

[infin8x]

We've removed automerge from GitHub-native Dependabot due to precisely the sorts of concerns raised in this thread. If/when we bring back auto-merge, we expect to do so in a way that addresses these concerns.

Duplicate of #2243