Status: Closed (View Workflow)
Resolution: Not A Defect
Git Client Plugin 3.6.4
Git Plugin 2.6.0
Git for Windows 2.15.windows.1 (Credential Manager NOT installed)
Advanced sub-modules behaviors options checked:
"Recursively update submodules"
"Use credentials from default remote of parent repository"
SSH private key stored in Jenkins Credentials
Windows 10 Jenkins 2.87 Git Client Plugin 3.6.4 Git Plugin 2.6.0 Git for Windows 2.15.windows.1 (Credential Manager NOT installed) Advanced sub-modules behaviors options checked: "Recursively update submodules" "Use credentials from default remote of parent repository" SSH private key stored in Jenkins Credentials
See initial Stack Overflow question: https://stackoverflow.com/questions/46518082/jenkins-git-plugin-unable-to-initialize-submodules
I have since updated all components to their latest releases.
The project "Parent_test_repo" includes "Child_test_repo" as a submodule. These are both private repositories. They use the same SSH key, which has been add to the Jenkins credentials.
Building the project results in the parent repository being correctly accessed and clone, but the the "git submodule init" fails with a 128 (access violation?) error.
This problem is specific to Windows: On Ubuntu 17.10 it correctly initializes the submodule and the build succeeds.
Variations tried unsuccessfully:
- Using Windows 7 instead of 10
- Using ~/.ssh instead of storing private SSH key in Jenkins
- Using HTTPS login instead of SSH
- Using Bitbucket instead of GitHub
- Using relative paths in submodule URL
I'm concluding it's a Windows-specific issue with submodule authentication.
I am willing to help debug further.
FYI: "MINGW64" is the default path when the MINTTY option is checked on the windows Git installer. From Git-Bash:
mplavcan@System MINGW64 ~ $ which git /mingw64/bin/git
There is a git.exe located there: Unsure as to why it works correctly with the initial clone.
Confirmed that changing the path to the git.exe to default resolved the issue.
Thanks mplavcan for the clarification on the source of the different path. In all the years I've used git for windows, I've never enabled "mintty" from the Windows git installer.
I may need to add a safeguard to the Jenkins git client plugin which detects that path setting and either ignores it or adapts to it. There are already more configurations than I can comfortably test, and I'd very much like to not have yet another configuration.
The git plugin is tested with git for Windows with the PATH configured to include:
C:\Program Files\Git\bin;C:\Program Files\Git\usr\bin
It appears you have configured git to use an incorrect PATH.
C:\Program Files\Git\Mingw64\bin;C:\Program Files\Git\Mingw64\usr\bin
The git at that incorrect path seems to be unable to find the submodule command for git. Without the submodule command, the plugin can't work with submodules.
Could you try the same steps, but with the PATH using the standard values as configured by the Windows git installer, rather than inserting the "Mingw64" directory into the path?