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

Renovate does not update git submodules when changing branch #26057

Closed
rarkins opened this issue Nov 30, 2023 Discussed in #25689 · 7 comments · Fixed by #26076 or #26163
Closed

Renovate does not update git submodules when changing branch #26057

rarkins opened this issue Nov 30, 2023 Discussed in #25689 · 7 comments · Fixed by #26076 or #26163
Labels
core:git Related to our git platform layer priority-4-low Low priority, unlikely to be done unless it becomes important to more people status:in-progress Someone is working on implementation type:bug Bug fix of existing functionality

Comments

@rarkins
Copy link
Collaborator

rarkins commented Nov 30, 2023

Discussed in #25689

Originally posted by mtardy November 10, 2023

How are you running Renovate?

Self-hosted Renovate

If you're self-hosting Renovate, tell us what version of Renovate you run.

37.54.3

If you're self-hosting Renovate, select which platform you are using.

github.com

Was this something which used to work for you, and then stopped?

I am trying to get this working for the first time

Describe the problem

I created a minimal reproduction repository here https://github.com/mtardy/renovate-submodules-repro.


I'm maintaining a project with Renovate that has a git submodule (and use this submodule in go.mod replace directive). Thanks to the option cloneSubmodules it works when I'm working on the main branch.

But when renovate needs to work on a stable branch, let's say v1.0, it git checkout v1.0 but does not update the submodule along (with git submodule update --init <module> for example). So I end up on the v1.0 stable branch with the content of the submodule folder corresponding to the one on the main branch. It then creates a PR with the changes and thus bump the submodule version to the one of the main branch because it never updated it to the correct commit.

I hope this a clear explanation! Is there a way to fix that behavior? Apparently, there are ways to immediately update submodules on checkout:

Is there a way to add git configs to the renovate run to pass git config submodule.recurse true?

I can do a minimal reproduction repository but I guess this explanation is clear enough maybe? Thanks!!

Relevant debug logs

Logs
Copy/paste the relevant log(s) here, between the starting and ending backticks

Have you created a minimal reproduction repository?

I created a minimal reproduction repository here https://github.com/mtardy/renovate-submodules-repro.

@rarkins rarkins added type:bug Bug fix of existing functionality priority-4-low Low priority, unlikely to be done unless it becomes important to more people core:git Related to our git platform layer labels Nov 30, 2023
@viceice
Copy link
Member

viceice commented Nov 30, 2023

I think we simply need to update submodules when switching base branch.

@mtardy
Copy link
Contributor

mtardy commented Nov 30, 2023

I think we simply need to update submodules when switching base branch.

yes, it's just that the submodule.recurse config does that for you automatically (since I don't see a situation in which you don't want that), but you can also git submodule update ... manually.

@viceice
Copy link
Member

viceice commented Nov 30, 2023

sounds like an easy feature 😊

@viceice viceice self-assigned this Dec 1, 2023
@viceice viceice added the status:in-progress Someone is working on implementation label Dec 1, 2023
@renovate-release
Copy link
Collaborator

🎉 This issue has been resolved in version 37.80.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

@mtardy
Copy link
Contributor

mtardy commented Dec 5, 2023

Thanks a lot, it fixed my issue and now it works for stable branches. However, I had a failure today in my post-upgrade command:

Command failed: make generate
fatal: --untracked not supported with --recurse-submodules
make[1]: *** [Makefile:35: generate] Error 128
make: *** [Makefile:394: generate] Error 2

Not exactly sure why for now but this is new and I guess related to the fix.

This make generate command basically does go mod tidy && go mod vendor && go mod verify in multiple go.mod.

@rarkins
Copy link
Collaborator Author

rarkins commented Dec 5, 2023

Please open a new discussion and ideally with reproduction of the new problem. It seems that the problem is during the Makefile executation so perhaps go is calling git under the hood and the recurse-submodules global flag is problematic

@mtardy
Copy link
Contributor

mtardy commented Dec 6, 2023

Please open a new discussion and ideally with reproduction of the new problem. It seems that the problem is during the Makefile executation so perhaps go is calling git under the hood and the recurse-submodules global flag is problematic

I found the culprit and created this discussion #26153.

@rarkins rarkins reopened this Dec 6, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
core:git Related to our git platform layer priority-4-low Low priority, unlikely to be done unless it becomes important to more people status:in-progress Someone is working on implementation type:bug Bug fix of existing functionality
Projects
None yet
4 participants