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

feat: compare all branch authors when deciding if a branch is modified #21558

Merged
merged 27 commits into from Oct 17, 2023

Conversation

Keysox
Copy link
Contributor

@Keysox Keysox commented Apr 17, 2023

Changes

Previously, when Renovate tried to determine if a branch was modified before force-pushing, it only looked at the last commit, which can result in losing commit history. This PR changes the behavior to compare all of the commits to the default branch.

Context

Documentation (please check one with an [x])

  • I have updated the documentation, or
  • No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

  • Code inspection only, or
  • Newly added/modified unit tests, or
  • No unit tests but ran on a real repository, or
  • Both unit tests + ran on a real repository

@Keysox Keysox marked this pull request as ready for review April 17, 2023 17:35
@rarkins
Copy link
Collaborator

rarkins commented May 23, 2023

Hi @Keysox thanks for resubmitting this functionality. Could you describe your confidence about whether the problem which occurred previously has been resolved and how?

Copy link
Member

@viceice viceice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

last time it was totally broken, are those issues now resolved?

lib/util/git/index.ts Outdated Show resolved Hide resolved
@Keysox
Copy link
Contributor Author

Keysox commented May 23, 2023

@rarkins @viceice, the original one used git log --pretty=format:%ae origin/main...origin/multiple_commits and this one does git log --pretty=format:%ae origin/main..origin/multiple_commits (with two dots). https://git-scm.com/docs/git-log#_description has an explanation of the differences but testing locally with a few branches, the new behavior shows only the newly added commits to a branch whereas the other was a total difference, which no longer worked if a branch wasn't up to date since it would pull in every change.

Do you have any suggestions on how to add unit tests? The last PR had them but when I tried a month ago, I wasn't able to this time around since this new approach relied on the branch being pushed, which I wasn't able to figure out how to do with jest. Will poke at it again!

@rarkins
Copy link
Collaborator

rarkins commented Sep 16, 2023

@Keysox do you have the time to add the requested test?

lib/util/git/index.ts Show resolved Hide resolved
lib/util/git/index.ts Show resolved Hide resolved
Keysox and others added 2 commits September 25, 2023 09:21
Co-authored-by: Rhys Arkins <rhys@arkins.net>
@viceice viceice requested a review from rarkins October 16, 2023 15:21
@rarkins rarkins added this pull request to the merge queue Oct 17, 2023
Merged via the queue into renovatebot:main with commit c2cb93c Oct 17, 2023
36 checks passed
@renovate-release
Copy link
Collaborator

🎉 This PR is included in version 37.26.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

await git.raw([
'log',
'--pretty=format:%ae',
`origin/${branchName}..origin/${baseBranch}`,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The syntax here is the wrong way.
This check means "all from baseBranch except those on branchName".

So basically this would return all commits that are on the base but NOT on the renovate-bot.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what would be the right command?

Copy link

@kindlich kindlich Oct 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@viceice Either switch the operands

Suggested change
`origin/${branchName}..origin/${baseBranch}`,
`origin/${baseBranch}..origin/${branchName}`,

Or use the explicit

Suggested change
`origin/${branchName}..origin/${baseBranch}`,
`origin/${branchName} ^origin/${baseBranch}`,

Both should show all commits on the branchName (e.g. renovate/dep-abc), but without any commits on the baseBranch (e.g. main).

So if we were to have the following git tree (I hope the mermaid rendering is supported in all browsers):

gitGraph
       commit id: "A"
       commit id: "B"
       commit id: "C"
       branch renovate/x
       checkout main
       commit id: "D"
       commit id: "E"
       checkout renovate/x
       commit id: "X"

Then baseBranch would be main and branchName would be renovate/x
We'd probably only want to look at the commit X, but the way this MR was written would return the D and E

Then the result would be:

command result
main..renovate/x X
renovate/x..main D, E
renovate/x ^main X
main ^renovate/x D, E

Of course, if there were some rebasing done in between, it would be a bit different.
Let's say we rebased C, D, E on the main branch (if for whatever reason you were to rebase on main).
Or well, pretty much anything that rewrites history, like someone else force-pushing over someone else's changes.

gitGraph
       commit id: "A"
       commit id: "B"
       branch renovate/x
       checkout renovate/x
       commit id: "C"
       commit id: "X"
       checkout main
       commit id: "C - rebased"
       commit id: "D - rebased"
       commit id: "E - rebased"

Then the result would be:

command result
main..renovate/x C, X
renovate/x..main C - rebased, D - rebased, E - rebased
renovate/x ^main C, X
main ^renovate/x C - rebased, D - rebased, E - rebased

I don't know what the expected behaviour should be in the case the main was force-pushed, but you can at least use these tables as reference if you wanted this feature again 😉

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rebase would be an issue now too. I'm not too worried about that. it shouldn't be a normal workflow with renovate. can we detect that?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe I'll try to create this PR again with proper tests

@muffl0n
Copy link
Contributor

muffl0n commented Oct 17, 2023

This just closed all our merge requests in Bitbucket Server. 🥲

   INFO: Comment added (repository=US/gcp-helmfile, branch=renovate/defaults-external-secrets-0.x)
         "prNo": 687,
         "topic": "Edited/Blocked Notification"

@viceice
Copy link
Member

viceice commented Oct 17, 2023

@rarkins revert again?

@bobvandevijver
Copy link
Contributor

bobvandevijver commented Oct 17, 2023

Yeah, renovate is marking all our open MRs as edited/blocked incorrectly as well with this update.

@rarkins
Copy link
Collaborator

rarkins commented Oct 17, 2023

This just closed all our merge requests in Bitbucket Server. 🥲

   INFO: Comment added (repository=US/gcp-helmfile, branch=renovate/defaults-external-secrets-0.x)
         "prNo": 687,
         "topic": "Edited/Blocked Notification"

@mufflon it closed them? Or added a comment?

@muffl0n
Copy link
Contributor

muffl0n commented Oct 17, 2023

That was wrong: It did not close them, it posted this message. Sorry for the confusion!
screenshot 2023-10-17 um 13 45 32

@rarkins
Copy link
Collaborator

rarkins commented Oct 17, 2023

Now reverted, please upgrade to 37.26.1 once it's built and available. Sorry for the trouble everyone!

@bobvandevijver
Copy link
Contributor

Now reverted, please upgrade to 37.26.0 once it's built and available. Sorry for the trouble everyone!

37.26.1 you mean😸 Thanks for the quick action! 👍🏻

@rarkins
Copy link
Collaborator

rarkins commented Oct 17, 2023

Yes, fixed now thanks!

@ben-foxmoore
Copy link

With the rollback, is there any straightforward way to recover PRs that have been marked in this way, without having to go through and checking each individual box?

@rarkins
Copy link
Collaborator

rarkins commented Oct 17, 2023

Renovate should treat them as unmodified now, although I'm not sure if it will remove those comments

@ben-foxmoore
Copy link

OK - as long as the comment itself doesn't have some significance to Renovate. I'll keep an eye on the affected PRs. Thanks @rarkins

@chezsmithy
Copy link
Contributor

The MRs affected by this issue don't seem to be auto resolving with newer builds. Is anyone seeing anything different?

I'm trying to force a rebase now to get some of them unblocked.

@rarkins
Copy link
Collaborator

rarkins commented Oct 18, 2023

@chezsmithy please copy/paste the logs for one such branch.

My expectation is that the comment remains, but that Renovate should be back to its old functionality and consider the branch to be unmodified

@muffl0n
Copy link
Contributor

muffl0n commented Oct 18, 2023

Can confirm this: Renovatebot proceeds to update the PRs. The comment remains, though.

@chezsmithy
Copy link
Contributor

chezsmithy commented Oct 18, 2023

@chezsmithy please copy/paste the logs for one such branch.

My expectation is that the comment remains, but that Renovate should be back to its old functionality and consider the branch to be unmodified

@rarkins Also seeing what @muffl0n is reporting. The comment remaining was the unexpected part.

jon4hz pushed a commit to jon4hz/renovate that referenced this pull request Nov 9, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 18, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants