Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-47832

Unable to initialize private submodules due to access error (Windows-only)

    • Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Major Major
    • git-client-plugin

      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.

          [JENKINS-47832] Unable to initialize private submodules due to access error (Windows-only)

          Mark Waite added a comment -

          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?

          Mark Waite added a comment - 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?

          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.

          Matthew Plavcan added a comment - 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.

          Mark Waite added a comment -

          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.

          Mark Waite added a comment - 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.

            markewaite Mark Waite
            mplavcan Matthew Plavcan
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: