rebase command runs an action but doesn't actually rebase the branch

[smlx]

Is there an existing issue for this?

• I have searched the existing issues

Package ecosystem

gomod, docker

Package manager version

n/a

Language version

n/a

Manifest location and content before the Dependabot update

https://github.com/smlx/goodwe-exporters/blob/a559b4c02943badf09483304f2753d905ed9de04/Dockerfile#L1

dependabot.yml content

https://github.com/smlx/goodwe-exporters/blob/a559b4c02943badf09483304f2753d905ed9de04/.github/dependabot.yaml#L1

Updated dependency

alpine from 3.19 to 3.20

What you expected to see, versus what you actually saw

On this PR I commented @dependabot rebase, and that kicked off an action running dependabot which completed successfully. But the PR was never actually rebased, so it still can't be merged.

Native package manager behavior

n/a

Images of the diff or a link to the PR, issue, or logs

smlx/goodwe-exporters#69

Smallest manifest that reproduces the issue

No response

[mbiggs-gresham]

Same with yarn ecosystem. recreate doesn't work either.

[elchininet]

I have seen this issue but it is not the same in my case. In my repos this started just one week ago, rebase command just adds a thumbs up, add a comment at the beginning of the MR and later it removes the comment without rebasing anything.

Example: elchininet/isometric-css#143

[sambauers]

I have seen behaviour that might be the same or possibly related. Attempts to rebase sometimes come up with unresolvable conflicts. I was able to replicate this behaviour outside of Dependabot PRs manually. The cause seems to be the way in which PNPM lock files identify packages. For example this is a fairly normal identifier of a package inside a PNPM lock file:

/@mui/[email protected](@emotion/[email protected])(@mui/[email protected])(@types/[email protected])([email protected])([email protected])

With the above example, if you happen to have seperate PRs to update @mui/[email protected] and [email protected] at the same time, merging one will cause the other PR to have unreconcilable conflicts which require manual resolution.

Intuitively, I would expect that running @dependabot rebase would fix this, but it doesn't, and @dependabot recreate doesn't seem to do anything either.

[jpaakko]

We have exactly the same issue with multiple different PRs in multiple repositories. The issue started a bit over a week ago for Dependabot PRs created on June 22nd and 23rd. As a quick fix, we resolved these PRs by rebasing them manually but that's not something that we want to keep doing for future PRs. The issue occurred again for us for PRs created on June 29th and 30th.

When running @dependabot rebase or @dependabot recreate, Dependabot adds a thumbs up emoji to the comment and the "⚠️ Dependabot is rebasing this PR ⚠️" text appears in the PR description. However, once the action has run and the text is removed from the PR description, nothing happens and Dependabot doesn't rebase the PR.

The Dependabot logs don't show any errors and the logs look the same as for PRs where rebasing works. We've tested running Dependabot using the built-in Dependabot application and on GitHub actions but the issue occurs irrespective of how Dependabot is run.

One thing that is common to all our PRs where rebasing doesn't work is that they are part of a Dependabot group. However, the issue doesn't seem to concern all Dependabot groups as Dependabot has been able to rebase some PRs that concern grouped updates.

Package ecosystem: Yarn (npm)

[mbiggs-gresham]

Can confirm what @jpaakko said, I hadn't noticed before but it seems to be for group PR's. Just tried a rebase on both an individual dependency and a group one. The individual one worked and successfully rebased, the group one gave a thumbs up, said it was rebasing but ultimately did nothing.

[Mr0grog]

I am also seeing this frequently in a project I recently started contributing to with Ruby/Bundler dependencies.

I hadn't been paying attention before, but the last two times I saw this definitely was for grouped dependencies, so that could definitely be related.

---

Update: this absolutely seems related to grouped dependencies. Had another repo with some grouped and non-grouped open PRs and got the same results as @mbiggs-gresham.

[jpaakko]

I previously assumed that the issue didn't concern all grouped update PRs as some of our grouped update PRs had been successfully merged. Thus, I had mentioned:

the issue doesn't seem to concern all Dependabot groups as Dependabot has been able to rebase some PRs that concern grouped updates

However, today I went through all our grouped update PRs for the last couple of weeks. I noticed that the grouped update PRs that had been successfully merged didn't have any @dependabot rebase or @dependabot recreate commands since the PRs had already been up-to-date with the main branch. That explains why Dependabot had been able to merge these without any issues.

In contrast, all of our grouped update PRs during the last couple of weeks that have @dependabot rebase or @dependabot recreate comments have been stuck.

Based on this finding, it looks like rebasing grouped update PRs is currently broken for all grouped update PRs. The last time that Dependabot has been able to successfully rebase a grouped update PR in our repositories is on June 21st.

[broksonic21]

I had filed #10135 as well, which is same scenario:

• @dependabot recreate (or rebase) doesn't do anything on grouped PRs right now

Feel like it's been for a week or two that this has been going on. Seeing it on both bundler and npm scenarios.

[NatoBoram]

We're relying on Dependabot at @coderabbitai and we're affected by this Dependabot outage

• @dependabot rebase does not work
• @dependabot recreate does not work
• @dependabot squash and merge does not rebase or recreate

[boomshakalakah]

I don’t know ruby so I can’t find any suspicious code, but is there a chance that #10002 broke it? The timing lines up, and it changes behaviour around grouped dependencies.

Regardless, here’s potentially relevant stuff from my update logs.

I triggered @dependabot recreate on the PR for a group called tests, which currently has merge conflicts against main.

In the logs for a different PR, I can see

updater | 2024/07/03 18:31:10 INFO <job_851126648> Detected existing pull request for 'tests'.
updater | 2024/07/03 18:31:10 INFO <job_851126648> Deferring creation of a new pull request. The existing pull request will update in a separate job.

In the update logs for the tests group…

I’m seeing "dependency-has-directory":true, which is referenced in that PR.

Also,

updater | 2024/07/03 18:38:58 INFO <job_851129715> Starting job processing
updater | 2024/07/03 18:39:00 INFO <job_851129715> Starting PR update job for <REDACTED>
updater | 2024/07/03 18:39:00 INFO <job_851129715> Updating the 'tests' group
updater | 2024/07/03 18:39:00 INFO <job_851129715> Updating the / directory.

updater | 2024/07/03 18:40:03 INFO <job_851129715> Target versions have changed, existing Pull Request should be superseded
updater | 2024/07/03 18:40:03 INFO <job_851129715> Creating a new pull request for 'tests'

 updater | 2024/07/03 18:40:12 INFO Results:
 updater | +-----------------------------------------------------------------------------------------------+
 updater | |                              Changes to Dependabot Pull Requests                              |
 updater | +---------+-------------------------------------------------------------------------------------+
 updater | | created | @testing-library/dom ( from 10.1.0 to 10.3.0 ), cypress ( from 13.12.0 to 13.13.0 ) |
 updater | +---------+-------------------------------------------------------------------------------------+

However, those target versions haven’t actually changed. They’re the same as the versions in the existing PR.

In the end, it hasn’t created a new PR or recreated commits on the existing PR.

From what I can tell, it looks like it’s ending up in this else block when it should be matching this elsif above it.

EDIT: This setup is configured for an npm/yarn project.

[dotLou]

I think @boomshakalakah is on the right track here. I'm not super familiar with this code base, but I did notice that we've got spots where we create a dependency set that doesn't include the newly added directory key:

dependabot-core/updater/lib/dependabot/updater/operations/refresh_version_update_pull_request.rb

Lines 204 to 210 in e8d8a12

	updated_dependencies.map do |dep|
	{
	"dependency-name" => dep.name,
	"dependency-version" => dep.version,
	"dependency-removed" => dep.removed? ? true : nil
	}.compact
	end

This would mean that the check in

dependabot-core/updater/lib/dependabot/updater/group_update_refreshing.rb

Line 57 in 17fe8bf

elsif dependency_change.matches_existing_pr?

would fail because the sets don't match anymore

Edit:

It's worth noting that because there's no single method that creates these sets, there are also other areas that create them without this new value such as

dependabot-core/updater/lib/dependabot/updater/operations/refresh_security_update_pull_request.rb

Lines 199 to 205 in e8d8a12

	updated_dependencies.map do |dep|
	{
	"dependency-name" => dep.name,
	"dependency-version" => dep.version,
	"dependency-removed" => dep.removed? ? true : nil
	}.compact
	end