Skip to content
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

Dependabot recreate / rebase not working #6886

Closed
1 task done
jack-berg opened this issue Mar 21, 2023 · 18 comments
Closed
1 task done

Dependabot recreate / rebase not working #6886

jack-berg opened this issue Mar 21, 2023 · 18 comments
Assignees
Labels
service 💁 Relates to Dependabot features GitHub provides T: bug 🐞 Something isn't working

Comments

@jack-berg
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Package ecosystem

gradle

Package manager version

maven

Language version

No response

Manifest location and content before the Dependabot update

No response

dependabot.yml content

No response

Updated dependency

No response

What you expected to see, versus what you actually saw

I expected rebase / recreate to rebase / recreate the PR respectively. Instead, no updates are made to the PR commits. The PR description is temporarily changed to indicate some work is happening, but nothing is changed when the description returns to normal.

Native package manager behavior

No response

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

The commands recreate and rebase don't do anything. When I comment with those commands, dependabot adds a 👍 emoji, the PR temporarily has its description changed to:

⚠️ Dependabot is rebasing this PR ⚠️
Rebasing might not happen immediately, so don't worry if this takes some time.
Note: if you make any changes to this PR yourself, they will take precedence over the rebase.

Eventually, the description is restored, but no changes have be applied. I'm forced to manually resolve conflicts.

Examples:

Many more examples available upon request.

Seems to be a duplicate of #1645 but the advice in that issue is that "catch all" issues aren't helpful and I should open a new issue.

Smallest manifest that reproduces the issue

No response

@jack-berg jack-berg added the T: bug 🐞 Something isn't working label Mar 21, 2023
@jeffwidman
Copy link
Member

Hmm... I'm not seeing any conflicts on those PR's?

@jeffwidman jeffwidman added the service 💁 Relates to Dependabot features GitHub provides label Mar 22, 2023
@jack-berg
Copy link
Author

They need to rebase to incorporate updates to the target branch required for the build to pass. See this other PR where I manually merged main into the dependabot branch and the build now passes. I should be able to rebase or recreate to achieve the same affect.

@rturner3
Copy link

I am also seeing the same issue on several PRs:
spiffe/spire#4015
spiffe/spire#4016

@ikisler
Copy link

ikisler commented Mar 23, 2023

I am also running into this issue in multiple JS repos, but unfortunately they are all private so I can't share examples.

@nibynool
Copy link

nibynool commented Apr 5, 2023

Like @ikisler I'm also experiencing this on some JS/TS private repos. About 95% of the time asking dependabot to close the PR and then asking it to reopen it, then requesting a recreate or rebase will get things moving again. In the other 5% of cases I will wait for my team to push some additional changes to master/main and that will get the rebase going.

@jeffwidman
Copy link
Member

jeffwidman commented Apr 6, 2023

Yeah, this unfortunately isn't one we can just ask you to repro on a public repository because it's a non-deterministic issue of some kind related to the :dependabot: service that GitHub runs.

I think the best thing to do here is to create a GitHub support ticket so you can point to the specific examples in your private repo, feel free to link specifically to this issue, and then one of us can dig into it to see if there's a race or some infra / DB flake that we're not properly recovering from.

I'm going to close as this isn't one we can really address via the public issue tracker.

@jack-berg
Copy link
Author

@jeffwidman can you clarify why this is closed? The original issue I posted was reproducible on a public repo. Was this not an appropriate forum?

@jeffwidman
Copy link
Member

jeffwidman commented Apr 6, 2023

Ah yeah, I missed that sorry. Let me re-open this one.

We will almost certainly end up having an internal ticket on our side to track the investigation and any internal facing notes about DB/service, and using the support ticket that we get is a good placeholder for that conversation, but there's nothing needed more from you, so no need for you to jump through the hoops necessary for that.

For anyone else who comes along, please open separate tickets... in general a public ticket linking to a publicly reproducible repository is preferred, but for something like this where it may only manifest on your private repo, then an internal support ticket is okay.

@jakecoffman
Copy link
Member

I can see in the server logs that Dependabot ran the rebase, but when it posted the PR update to GitHub, it went silent. I'm adding additional logging on the server-side to get a better idea of what is happening. We need to capture what the error is from GitHub in order to address it.

Let me know if it happens again to another PR.

@jakecoffman jakecoffman self-assigned this Apr 11, 2023
@jack-berg
Copy link
Author

Let me know if it happens again to another PR.

Will do! Thanks for the update.

@jack-berg
Copy link
Author

@jakecoffman just had another occurrence here.

@jakecoffman
Copy link
Member

@jack-berg can you give it the rebase command one more time?

@jack-berg
Copy link
Author

Just ran it.

@jakecoffman
Copy link
Member

Thanks I was able to capture the error with the new logging: 422 - At least 1 approving review is required by reviewers with write access.

It looks like that repo has a wildcard branch protection rule. I think it is preventing Dependabot from force pushing to the branch it created.

@jack-berg
Copy link
Author

Huh. There's a branch protection rule for branching matching dependabot/**/** which applies to this branch. It does require approvals (which we want), but is configured to allow force pushes by all users with push access. Seems weird that I would need to remove a required approvals setting to allow force pushing. Can I somehow grant dependabot push / write acces?

Screen Shot 2023-04-13 at 1 21 06 PM

@jack-berg
Copy link
Author

Oh never mind I see. The "Require a pull request before merging" setting dictates that changes can't be made to the dependabot branches except through a pull request.

@jack-berg
Copy link
Author

Removed that setting and it worked. Thanks for looking into that @jakecoffman! I didn't se anything like that in the docs, but maybe I missed something. If not, would be good to add it so folks like me that self help. Thanks again! 🙂

@asbjornu
Copy link

asbjornu commented Jun 6, 2024

Please allow me to echo @jack-berg's request:

I didn't se anything like that in the docs, but maybe I missed something. If not, would be good to add it so folks like me that self help.

I just ran into this problem myself, where @dependabot rebase and @dependabot recreate caused Dependabot to thumbs up my comment and mark the original pull request message with:

⚠️ Dependabot is rebasing this PR ⚠️

However, no force-push was performed by Dependabot no matter how long I waited (over 24 hours for a particular pull request). I'm not sure how to tweak the branch protection rules in my repositories to allow Dependabot to do its thing. Just to be clear: I only have branch protection rules for main in my repositories, there are no rules defined for dependabot/**.

I would expect Dependabot to respond to the pull request with a comment explaining why it was unable to update it. Isn't that a reasonable thing to expect, @jakecoffman?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
service 💁 Relates to Dependabot features GitHub provides T: bug 🐞 Something isn't working
Projects
Archived in project
Development

No branches or pull requests

7 participants