-
Notifications
You must be signed in to change notification settings - Fork 995
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rebase command runs an action but doesn't actually rebase the branch #10118
Comments
Same with yarn ecosystem. |
I have seen this issue but it is not the same in my case. In my repos this started just one week ago, Example: elchininet/isometric-css#143 |
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:
With the above example, if you happen to have seperate PRs to update Intuitively, I would expect that running |
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 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) |
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. |
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. |
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:
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 In contrast, all of our grouped update PRs during the last couple of weeks that have 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. |
I had filed #10135 as well, which is same scenario:
Feel like it's been for a week or two that this has been going on. Seeing it on both bundler and npm scenarios. |
We're relying on Dependabot at @coderabbitai and we're affected by this Dependabot outage
|
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 In the logs for a different PR, I can see
In the update logs for the tests group… I’m seeing Also,
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. |
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 dependabot-core/updater/lib/dependabot/updater/operations/refresh_version_update_pull_request.rb Lines 204 to 210 in e8d8a12
This would mean that the check in
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
|
In case more examples provide any clues, I've also been facing this:
All three cases were for a grouped dependency (I'll check next time there is a non-grouped dependency to see if that case works) |
I don't know if others had this happen as well but 2 minutes ago dependabot did finally issue the force push on PhilanthropyDataCommons/service#1095, merged, and now everything is as it should be. It seems this bug may be fixed? |
LGTM |
Confirmed in cockpit-project/cockpit-ostree#651 (comment) , works again. Thanks! |
Confirmed also on my pending pull requests. It is working now.👍🏼 |
The rebase regressions are fixed now. The main cause for it was This fixes it going forward because it handles directory being present or not: #10224 The reason you saw it started working again before this fix was I flipped the feature flag back off to mitigate the issue. Sorry about that and thanks for your patience! Thanks for all the reports! |
Is there an existing issue for this?
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
The text was updated successfully, but these errors were encountered: