A non immortal PR is reopen multiple times because the first time it was (wrongly) accepted then manually reverted #32564
Replies: 7 comments 1 reply
-
Closing a PR only stops renovate from creating PR for same version update. When another version will be available a new PR for same dep will be created. Use |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
This may be because the findPr() for Bitbucket |
Beta Was this translation helpful? Give feedback.
-
Yes that is exactly what I was thinking about. And my successful "hack" was indeed to change findPr to find the newest one. PS : my problem is with the bitbucket cloud platform, but as you said other platforms may have the problem |
Beta Was this translation helpful? Give feedback.
-
If you want I could share my workaround (after some polishing ;-) ) for the BitBucket cloud platform and share a PR ? |
Beta Was this translation helpful? Give feedback.
-
What I think we should do is:
|
Beta Was this translation helpful? Give feedback.
-
Hi, here is my PR #32672 I did not find a param to control the sort key in https://developer.atlassian.com/cloud/bitbucket/rest/api-group-pullrequests/#api-repositories-workspace-repo-slug-pullrequests-get |
Beta Was this translation helpful? Give feedback.
-
How are you running Renovate?
Self-hosted Renovate
If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.
Bitbucket Cloud, Renovate v.39.17.0
Please tell us more about your question or problem
Hi,
I'm facing a strange situation where Renovate still recreate & open PR ignoring my decline.
I think the origin of the problem was that the first PR to update the lib (PR name is "Update dependency com.github.jknack:handlebars to v4.3.1" (branch: renovate/handlebars-version) was accepted by a dev
,automerge disabled, but the build was ok, so the PR got merged.
Later, more in depth tests show that the upgrade broke the app (I agree : a test is missing somewhere).
So the team reverted the commit to restore the old version.
And since, Renovate is opening PR for that upgrade. The team denies the new PR.. but the next run , renovate recreate the PR.
I came to this conclusion by reading the log & code : if i understood well Renovate says that it found a previous PR # 187 (the first one indeed) and as it is not rejected, recreate a new PR # 201.
I found that the findPr method for the BitBucket platform ask for the list of PRs, filter by branch, name & state and use the first, optional, item of this list.
I then modify the getPrList method to sort found PRs by pr number desc : last one first & run renovate manually.
So now the
findPr
found the PR 200 which was rejected and renovate stop poping new PR. (And other patch are processed as I have limited renovate to a single PR per repo)I also found about the
reopen!
magic comment see #22984 and I wonder if a better solution exists with aignore!
or other "magic" comment...I still think that the last matching PR is more important than the first one... but I quickly look at the github platform impl and did not see a sort wo maybe I'm completely wrong.
Thanks !
Logs (if relevant)
Logs
For visibility issue I have remove this common parts
"name":"renovate","hostname":"h","pid":9,"level":20,"logContext":"actx","repository":"acme/a-repo",
Beta Was this translation helpful? Give feedback.
All reactions