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

Cannot checkout git repository with submodules: "FATAL: No remotes found!"

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Labels:
      None
    • Environment:
      Master: Jenkins 1.544, Git Plugin 2.0, Ubuntu 13.10 64bit, OpenJDK 1.7.0_25-b30
      Slave: CentOS 6.5 64bit, OpenJDK 1.7.0_45, Git 1.7.1
    • Similar Issues:

      Description

      Steps to reproduce
      1. Create a free-style project.
      2. Set "Git Repository URL". The repository specified should use submodules.
      3. In "Additional Behaviours", add "Advanced sub-modules behaviours" and check "Recursively update submodules".
      4. Build it.
      Expected result

      Workspace should have git working tree and submodules.

      Actual console log
      Cloning the remote Git repository
      Cloning repository git://***/*.git
      Fetching upstream changes from git://***/*.git
      Fetching upstream changes from git://***/*.git
      Checking out Revision 0123456789abcdef0123456789abcdef01234567 (origin/master)
      FATAL: No remotes found!
      hudson.plugins.git.GitException: No remotes found!
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getDefaultRemote(CliGitAPIImpl.java:702)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.setupSubmoduleUrls(CliGitAPIImpl.java:863)
      	at hudson.plugins.git.extensions.impl.SubmoduleOption.onCheckoutCompleted(SubmoduleOption.java:69)
      	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:882)
      	at hudson.model.AbstractProject.checkout(AbstractProject.java:1256)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589)
      	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494)
      	at hudson.model.Run.execute(Run.java:1502)
      	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      	at hudson.model.ResourceController.execute(ResourceController.java:88)
      	at hudson.model.Executor.run(Executor.java:236)
      
      Actual .git/config
      [core]
      	repositoryformatversion = 0
      	filemode = false
      	logallrefupdates = true
      

      There is no [remote "origin"] nor [submodule "submodule-name"] sections.

      Workaround

      One of the followings:

      • Downgrade git plugin to 1.5
      • Do not check "Recursively update submodules"
      • Do not checkout git repository with submodules
      • Create a shell build step with: git submodule update --init --recursive

        Attachments

          Activity

          Hide
          rafiki270 Ondrej Rafaj added a comment -

          I have created an additional shell build step with "git submodule update --init --recursive" ... of course I have disabled the sumodule section completely.

          Show
          rafiki270 Ondrej Rafaj added a comment - I have created an additional shell build step with "git submodule update --init --recursive" ... of course I have disabled the sumodule section completely.
          Hide
          benmonro Ben Monro added a comment -

          Any update on this? This is a severe problem. I have to use submodules and none of the workarounds worked.

          Show
          benmonro Ben Monro added a comment - Any update on this? This is a severe problem. I have to use submodules and none of the workarounds worked.
          Hide
          ndeloof Nicolas De Loof added a comment -

          @Goffredo init+fetch was actually required, there's no option on git-cli to pass credentials - misconception imho, but have to live with this limitation

          Show
          ndeloof Nicolas De Loof added a comment - @Goffredo init+fetch was actually required, there's no option on git-cli to pass credentials - misconception imho, but have to live with this limitation
          Hide
          ndeloof Nicolas De Loof added a comment -

          I guess this has been fixed by 9871e3c81f9f51950edc9cb0f2674304f554fb39

          Show
          ndeloof Nicolas De Loof added a comment - I guess this has been fixed by 9871e3c81f9f51950edc9cb0f2674304f554fb39
          Hide
          markewaite Mark Waite added a comment -

          git-plugin 2.0.1 and git-client-plugin 1.6.2 include the fix for this.

          Future versions of git-client-plugin (after 1.6.2) will have the further refinement that the plugin consistently assigns a remote when cloning, whether using JGit or command line git, and whether the internal implementation is a clone or an init and fetch.

          Show
          markewaite Mark Waite added a comment - git-plugin 2.0.1 and git-client-plugin 1.6.2 include the fix for this. Future versions of git-client-plugin (after 1.6.2) will have the further refinement that the plugin consistently assigns a remote when cloning, whether using JGit or command line git, and whether the internal implementation is a clone or an init and fetch.

            People

            • Assignee:
              ndeloof Nicolas De Loof
              Reporter:
              ohtake_tomohiro OHTAKE Tomohiro
            • Votes:
              22 Vote for this issue
              Watchers:
              34 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: