How does dependabot auto-resolve conflicts?

[GiriB]

I see that when multiple PRs are open and I complete one by one - there are times when there is a conflict in package.json. I'm curious to know how these conflicts automatically? Does dependabot re-run the updates in background with the latest master? Does it rebase?

[feelepxyz]

@GiriB dependabot re-runs the update with the latest master and force pushes over the existing PR

[xh3b4sd]

May I ask what the best practise in such cases looks like. When will dependabot rebuild the pull request having merge conflicts? It looks like it just happens after the usual interval which is a bit unfortunate. How should the workflow look like?

[feelepxyz]

May I ask what the best practise in such cases looks like. When will dependabot rebuild the pull request having merge conflicts? It looks like it just happens after the usual interval which is a bit unfortunate. How should the workflow look like?

Unless you disable automatic rebases we try to do it every time your manifests change on your default branch, this will then kick of the rebase job but these can take some time as the update needs to be re-done from scratch. Not sure I follow what you mean by How should the workflow look like??

[xh3b4sd]

My workflow question was directed towards the sequence of events depending on the configuration. I am not sure how long one is supposed to wait for the conflict resolution. So right now I just close PRs as soon as they have conflicts and wait for new PRs to get proposed again from scratch by Dependabot.

[feelepxyz]

My workflow question was directed towards the sequence of events depending on the configuration. I am not sure how long one is supposed to wait for the conflict resolution. So right now I just close PRs as soon as they have conflicts and wait for new PRs to get proposed again from scratch by Dependabot.

Hm that sounds like a bug! It should be within minutes if you enable Automatically rebase Dependabot PRs when they have conflicts in your dependabot dashboard account settings page.

You can also trigger a rebase by commenting on the PR with @dependabot rebase. Once a rebase is kicked off there should be a message added to the PR body notifying you of this. Otherwise, could you send over the URL to the latest logs and I can take a look? You'll find the logs if you go the dependabot dashboard and click on last checked..

[xh3b4sd]

Thank you for your support. I will try to get back to this here once I encounter the situation again. I cannot find the exact PR where I perceived the described behaviour as it was a couple of days ago and I did not write it down in the first place.

[xh3b4sd]

I think I perceived the situation again and left it alone to see what actually happens. When I came back the other day I saw a new commit which was made by dependabot round about a minute later. So I guess there is no real problem. From my side there would only have been the expectation that this is way more snappy and quick or that this is at least explained somewhere where I could read how the behaviour was implemented. Anyway thanks a lot for checking in here.

[feelepxyz]

@xh3b4sd that's fair, it's slow because we actually re-run the entire update against the head version of your manifests, so depends on the size of your project and the workload we're currently under where things can get stuck in queues if we're backed up. Will see if we can add this to our docs. We're moving it all to help.github.com at the moment.