-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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(git)!: determine branch modification based on all branch commits #28225
feat(git)!: determine branch modification based on all branch commits #28225
Conversation
Co-authored-by: Sam Chung <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had a couple of attempts at this same concept and both times it caused unintended consequences causing it to be rolled back. It's important we understand why that happened and how this fresh attempt avoids the same problem before merging
Good call @rarkins I hadn't thought about checking closed issues/discussions so I hadn't seen that context. I have found #21505 - this comment stands out to me #21504 (comment) - and I support the assessment because the attempt used Are you able to find what the other issue was? |
Ah, was this the second time? https://github.com/renovatebot/renovate/pull/21558/files#r1361930608 I think this attempt also doesn't have that problem. That being said, if it's been wrong twice, who's to say it can't be a third time. What do you recommend to gain confidence? |
This PR does things correctly I think ie. instead of the wrong way In both the previous attempts the wrong way was merged. I think some real runs will help us gain confidence. Some example test runs:
Some other mixes like simple update PR with commits from ignored authors. |
In update PR created by the bot. There is a checkbox present which user can check to rebase the PR. |
Cool, rebase is fine too (updated prior comment). As well,
This all seems to be working as expected for the cases I have tested. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make baseBranch mandatory
Removes fallback to checking depName for all matchPackageX and excludePackageX rules. BREAKING CHANGE: matchPackageNames and related functions no longer fall back to checking depName. Rewrite packageRules to use matchDepNames instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this make or require any change to caching?
…for tag lookups (renovatebot#28400) Changes default Docker Hub lookups from index.docker.io to hub.docker.com, which is more efficient. If you are configuring a Docker Hub token for docker.io then you should now configure it for docker.com as well. Closes renovatebot#24666 BREAKING CHANGE: Docker Hub lookups prefer hub.docker.com over index.docker.io. Set RENOVATE_X_DOCKER_HUB_TAGS_DISABLE=true in env to revert behavior.
Hmm, good question on caching changes. One potential thing is that the cache is solely based on the branch name and not the base branch. I guess if you now call isBranchModified for multiple different base branches then you could get into trouble? Is there a use case for this? I'll take your guidance on if we need to fix or not. |
If the cashing is based on branchName + commitSha then it might already work fine. If a branch SHA was "unmodified" on a previous run then it shouldn't change to modified even if the base branch has received commits. There's potentially an edge case where a modified one changes to unmodified due to creative git use but in that case they can request a rebase/retry |
Thanks all for the work on this 🙏 is someone happy to merge for me? Looks like I can't myself 😄 |
Changes
Extract all authors from the git log of the changes in the branch for a given PR against master and use those in isBranchModified
Context
Currently, the documentation for
gitIgnoredAuthors
states:The current implementation, however, only looks at the latest commit. If you have a flow like:
This will mean isBranchModified returns false and the rebase flow throws away commits 2 and 3.
Documentation (please check one with an [x])
How I've tested my work (please select one)
I have verified these changes via: