Dependabot-core: Updating stale Cargo dependencies always fails with "Expected content to change!"

Created on 18 Sep 2020 · 10Comments · Source: dependabot/dependabot-core

Package manager/ecosystem
Cargo (Rust).

Manifest contents prior to update
I'm seeing this in multiple repositories, but I'll use this one as an example. See the manifest here and the most interesting member of the workspace here.

Updated dependency
I'm seeing these errors when Dependabot examines multiple dependencies, but [nalgebra] always shows up in the logs and is stale (I expect Dependabot to open a PR to upgrade it). I see both [nalgebra] and [ultraviolet] show up consistently in another repository ([ultraviolet] is also stale).

What you expected to see, versus what you actually saw
I expect Dependabot to run successfully and open PRs for stale crates ([nalgebra] and [ultraviolet]). Instead, checking for updates always fails and produces logs similar to the following:

updater | ERROR <job_62440466> Error processing nalgebra (RuntimeError)
updater | ERROR <job_62440466> Expected content to change!

Images of the diff or a link to the PR, issue or logs
See the logs here and here for examples. Attempting an update in either of these repositories results in similar errors each time. See the Dependabot configuration here.

bug 🐞

Source

olson-sean-k

Most helpful comment

Alright, I'll try to carve out some time next week to dig into this.

jurre on 9 Oct 2020

❤2

All 10 comments

I manually updated the affected packages described previously and I'm now seeing the same errors in the logs for other packages that have become stale (in this case winit, which can be upgraded from ^0.22.1 to ^0.23.0). I'm curious if Cargo support is broken in general or if there's something unique in my repositories that is triggering this behavior...

olson-sean-k on 6 Oct 2020

@olson-sean-k I have a feeling this may have the same underlying root-cause as https://github.com/dependabot/dependabot-core/issues/2512. I started observing that after we switched from the preview app to the built-in dependabot integration.
I'm also possibly seeing a pattern where the ^ is present in all the failed runs. Do you maybe have a repository where there are stale dependencies and you can quickly try removing a ^ from the requirement and see if the bot gets unstuck?

lucab on 9 Oct 2020

👍1

Indeed, removing the carets worked on our repository: https://github.com/coreos/afterburn/pull/496

lucab on 9 Oct 2020

Could this resolve some of these issues perhaps? https://github.com/dependabot/dependabot-core/pull/2620 we were on a pretty old version of cargo 🤔

jurre on 9 Oct 2020

@jurre it could be, but I doubt.
At least on coreos repositories we started using Dependabot in late 2018, and at that time there was an even older toolchain (1.31.0 at most). This caret issue seems to have appeared recently, more or less one month after the switch to the native integration.
Going back in the history, the last working caret+minor bump was on 2020-07-27 (https://github.com/coreos/afterburn/pull/467) and the first time I noticed a missed update was on 2020-09-01 (https://github.com/dependabot/dependabot-core/issues/2512).

lucab on 9 Oct 2020

Alright, I'll try to carve out some time next week to dig into this.

jurre on 9 Oct 2020

❤2

I have a feeling this may have the same underlying root-cause as #2512. I started observing that after we switched from the preview app to the built-in dependabot integration.

Interesting! I nearly always use ^ in version specifications. Thanks for the insight. I haven't tested this out yet, but I'll give it a try when I get a chance.