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

git config --get submodule fails with GIT_SSH credentials

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: git-client-plugin
    • Labels:
    • Environment:
      Jenkins 2.121.1
      Git Client Plugin 2.7.3
    • Similar Issues:

      Description

      When trying to checkout a Git project with several submodules, I get an error on one of them.

       

      All public available GIT submodules are checked out correctly. However one GIT submodule is proprietary and needs the use of GIT_SSH to set the credentials. It has been configured to "Use credentials from default remote of parent repository" in advanced sub-modules behaviour.

       

      he error log:

       

      Cloning the remote Git repository
      Cloning repository ssh://git@bitbucket.televic.com:7999/tra_mec/33.96.8002.git
      > git init /media/Data/workspace/33.96.8002/sources # timeout=10
      Fetching upstream changes from ssh://git@bitbucket.televic.com:7999/tra_mec/33.96.8002.git
      > git --version # timeout=10
      using GIT_SSH to set credentials
      > git fetch --tags --progress ssh://git@bitbucket.televic.com:7999/tra_mec/33.96.8002.git +refs/heads/:refs/remotes/sources/
      > git config remote.sources.url ssh://git@bitbucket.televic.com:7999/tra_mec/33.96.8002.git # timeout=10
      > git config --add remote.sources.fetch +refs/heads/:refs/remotes/sources/ # timeout=10
      > git config remote.sources.url ssh://git@bitbucket.televic.com:7999/tra_mec/33.96.8002.git # timeout=10
      Fetching upstream changes from ssh://git@bitbucket.televic.com:7999/tra_mec/33.96.8002.git
      using GIT_SSH to set credentials
      > git fetch --tags --progress ssh://git@bitbucket.televic.com:7999/tra_mec/33.96.8002.git +refs/heads/:refs/remotes/sources/
      > git rev-parse refs/remotes/sources/feature/gitsubmodules^{commit} # timeout=10
      > git rev-parse refs/remotes/sources/sources/feature/gitsubmodules^{commit} # timeout=10
      Checking out Revision 4511e708dedab56c7b23324e0e21afb3666fbaec (refs/remotes/sources/feature/gitsubmodules)
      > git config core.sparsecheckout # timeout=10
      > git checkout -f 4511e708dedab56c7b23324e0e21afb3666fbaec
      Commit message: "added git submodule info to inject in /etc/jenkins.build file"
      > git rev-list --no-walk 4511e708dedab56c7b23324e0e21afb3666fbaec # timeout=10
      > git remote # timeout=10
      > git submodule init # timeout=10
      > git submodule sync # timeout=10
      > git config --get remote.sources.url # timeout=10
      > git submodule init # timeout=10
      > git config -f .gitmodules --get-regexp ^submodule\.(.+)\.url # timeout=10
      > git config --get submodule.poky.url # timeout=10
      > git remote # timeout=10
      > git config --get remote.sources.url # timeout=10
      > git config -f .gitmodules --get submodule.poky.path # timeout=10
      using GIT_SSH to set credentials
      > git submodule update --init --recursive poky
      > git config --get submodule.meta-openembedded.url # timeout=10
      > git remote # timeout=10
      > git config --get remote.sources.url # timeout=10
      > git config -f .gitmodules --get submodule.meta-openembedded.path # timeout=10
      using GIT_SSH to set credentials
      > git submodule update --init --recursive meta-openembedded
      > git config --get submodule.meta-virtualization.url # timeout=10
      > git remote # timeout=10
      > git config --get remote.sources.url # timeout=10
      > git config -f .gitmodules --get submodule.meta-virtualization.path # timeout=10
      using GIT_SSH to set credentials
      > git submodule update --init --recursive meta-virtualization
      > git config --get submodule.meta-xilinx.url # timeout=10
      > git remote # timeout=10
      > git config --get remote.sources.url # timeout=10
      > git config -f .gitmodules --get submodule.meta-xilinx.path # timeout=10
      using GIT_SSH to set credentials
      > git submodule update --init --recursive meta-xilinx
      > git config --get submodule.meta-ti.url # timeout=10
      > git remote # timeout=10
      > git config --get remote.sources.url # timeout=10
      > git config -f .gitmodules --get submodule.meta-ti.path # timeout=10
      using GIT_SSH to set credentials
      > git submodule update --init --recursive meta-ti
      > git config --get submodule.meta-security.url # timeout=10
      > git remote # timeout=10
      > git config --get remote.sources.url # timeout=10
      > git config -f .gitmodules --get submodule.meta-security.path # timeout=10
      using GIT_SSH to set credentials
      > git submodule update --init --recursive meta-security
      > git config --get submodule.33.97.1231.url # timeout=10
      hudson.plugins.git.GitException: Command "git config --get submodule.33.97.1231.url" returned status code 1:
      stdout:
      stderr:
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2016)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1984)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1980)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1612)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1624)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getSubmoduleUrl(CliGitAPIImpl.java:1224)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$7.execute(CliGitAPIImpl.java:1150)
      at hudson.plugins.git.extensions.impl.SubmoduleOption.onCheckoutCompleted(SubmoduleOption.java:108)
      Caused: java.io.IOException: Could not perform submodule update
      at hudson.plugins.git.extensions.impl.SubmoduleOption.onCheckoutCompleted(SubmoduleOption.java:113)
      at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1264)
      at hudson.scm.SCM.checkout(SCM.java:504)
      at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
      at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
      at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
      at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
      at hudson.model.Run.execute(Run.java:1794)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
      at hudson.model.ResourceController.execute(ResourceController.java:97)
      at hudson.model.Executor.run(Executor.java:429)

        Attachments

          Issue Links

            Activity

            Hide
            markewaite Mark Waite added a comment -

            If it depends on submodule name then you are probably seeing JENKINS-38860 or something related to it. The handling of renamed submodules in the git plugin is incorrect. The only workaround is to perform the `git submodule` commands directly in your job definition rather than relying on the plugin to perform the submodule updates. Sorry about that.

            Show
            markewaite Mark Waite added a comment - If it depends on submodule name then you are probably seeing JENKINS-38860 or something related to it. The handling of renamed submodules in the git plugin is incorrect. The only workaround is to perform the `git submodule` commands directly in your job definition rather than relying on the plugin to perform the submodule updates. Sorry about that.
            Hide
            pietercardoen Pieter Cardoen added a comment -

            If I add the same submodule in folder 33.97.1231, it is working. Apparently, it has to do with the different naming of the submodule.

             

            Show
            pietercardoen Pieter Cardoen added a comment - If I add the same submodule in folder 33.97.1231, it is working. Apparently, it has to do with the different naming of the submodule.  
            Hide
            pietercardoen Pieter Cardoen added a comment -

            I had a closer look to the difference between the submodules.

            1: meta-security is an open source metalayer which is added using git submodule init <link to git repo>

            2: 33.97.1231 is a proprietary git repository and is added to a folder with different name

             

            We are using GIT plugin version 3.9.1

             

            The credentials are indeed assigned in the job that is parent of the submodules. The top module gets checked out which means the credentials are correctly used.

            Show
            pietercardoen Pieter Cardoen added a comment - I had a closer look to the difference between the submodules. 1: meta-security is an open source metalayer which is added using git submodule init <link to git repo> 2: 33.97.1231 is a proprietary git repository and is added to a folder with different name   We are using GIT plugin version 3.9.1   The credentials are indeed assigned in the job that is parent of the submodules. The top module gets checked out which means the credentials are correctly used.
            Hide
            markewaite Mark Waite added a comment -

            I am perplexed by the message that is in the stack trace. The stack trace line which reads:

            git submodule update --init --recursive meta-security
            

            is the line that I would have expected to fail if the credentials were incorrect or had not been provided. The `git submodule update` command performs a remote operation and uses authentication to do so.

            The line which reports a failure in `git config --get submodule.33.97.1231.url ` is unexpected. That is a local operation which should not involve any authentication.

            Are you using a pre-release of the git plugin that has multi-threaded submodule updates enabled? I assume not, but am interested if you are.

            Are credentials assigned in the job to the repository that is the parent of the submodules? I assume yes.

            Show
            markewaite Mark Waite added a comment - I am perplexed by the message that is in the stack trace. The stack trace line which reads: git submodule update --init --recursive meta-security is the line that I would have expected to fail if the credentials were incorrect or had not been provided. The `git submodule update` command performs a remote operation and uses authentication to do so. The line which reports a failure in `git config --get submodule.33.97.1231.url ` is unexpected. That is a local operation which should not involve any authentication. Are you using a pre-release of the git plugin that has multi-threaded submodule updates enabled? I assume not, but am interested if you are. Are credentials assigned in the job to the repository that is the parent of the submodules? I assume yes.

              People

              • Assignee:
                Unassigned
                Reporter:
                pietercardoen Pieter Cardoen
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated: