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

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

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Not A Defect
    • Component/s: git-client-plugin
    • Labels:
    • Environment:
    • Similar Issues:

      Description

      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.

        Attachments

          Activity

          Hide
          markewaite 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?

          Show
          markewaite 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?
          Hide
          mplavcan 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.

          Show
          mplavcan 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.
          Hide
          markewaite Mark Waite added a comment -

          Thanks Matthew Plavcan 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.

          Show
          markewaite Mark Waite added a comment - Thanks Matthew Plavcan 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.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: