Grouped updates with git-submodules
enabled causes flacky updates
#30279
Labels
manager:git-submodules
Git Submodules manager
priority-4-low
Low priority, unlikely to be done unless it becomes important to more people
type:bug
Bug fix of existing functionality
Discussed in #30187
Originally posted by Shegox July 15, 2024
What would you like help with?
I think I found a bug
How are you running Renovate?
Self-hosted
If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.
37.431.5
Please tell us more about your question or problem
This issue revisits the problem discussed in #22098, but I am creating a new ticket because the original issue was marked as resolved.
While using this
renovate.json
configuration and grouping a submodule update with another update:I encounter flaky behavior in updates. Here is a summary of the problematic behavior observed:
The root cause seems to be related to treating
git-submodules
as special and always marking them as tainted, which forces an update:renovate/lib/workers/repository/update/branch/get-updated.ts
Lines 276 to 281 in 1c8eb34
Unlike other updates, we don’t rerun with
reuseExistingBranch: false
for submodules as we do here:renovate/lib/workers/repository/update/branch/get-updated.ts
Lines 258 to 268 in 1c8eb34
Demo
You can see the behavior in this demo repository/update: Demo Pull Request.
Proposed Solutions
I have two potential solutions and would appreciate input on the best approach:
getUpdatedPackageFiles()
withreuseExistingBranch: false
forgit-submodules
..isLockfileUpdate
, could avoid the need for special handling of package file updates inget-updated.ts
.Looking forward to feedback on these proposed solutions.
Logs (if relevant)
Logs
Update (
2
step) from having the right updates to removing the non-submodule update: Shegox/renovate-submodule-group@4d18355The text was updated successfully, but these errors were encountered: