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

Git plugin with checkout to subdir and prune stale branches fails all builds

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
    • Environment:
      Jenkins 1.509.4, Git 2.0, Git client 1.4.5, Windows and Linux, AMD64 and x86
    • Similar Issues:

      Description

      I configured a job with the git 2.0 plugin to checkout to a specific subdirectory and to prune stale branches. That pair of configuration settings cause the initial git operations to fail with both git command line and jgit implementations.

      The stack trace for the command line implementation is:

      Started by user anonymous
      Building remotely on alan-pc in workspace C:\J\workspace\git-multi-subdir-prune
      Pruning obsolete local branches
      FATAL: Command "config --get remote.origin.url" returned status code 1:
      stdout: 
      stderr: 
      hudson.plugins.git.GitException: Command "config --get remote.origin.url" returned status code 1:
      stdout: 
      stderr: 
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:940)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:921)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:865)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:875)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRemoteUrl(CliGitAPIImpl.java:603)
      	at hudson.plugins.git.GitAPI.getRemoteUrl(GitAPI.java:61)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.prune(CliGitAPIImpl.java:393)
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
      	at java.lang.reflect.Method.invoke(Unknown Source)
      	at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:299)
      	at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:280)
      	at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:239)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
      	at hudson.remoting.Request$2.run(Request.java:326)
      	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
      	at java.util.concurrent.FutureTask.run(Unknown Source)
      	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
      	at hudson.remoting.Engine$1$1.run(Engine.java:63)
      	at java.lang.Thread.run(Unknown Source)
      

      The stack trace for the jgit implementation is:

      Started by an SCM change
      Started by user anonymous
      Building remotely on waite2011 in workspace D:\J\workspace\git-multi-jgit-subdir-prune
      Pruning obsolete local branches
      FATAL: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null
      hudson.plugins.git.GitException: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null
      	at org.jenkinsci.plugins.gitclient.JGitAPIImpl.prune(JGitAPIImpl.java:869)
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
      	at java.lang.reflect.Method.invoke(Unknown Source)
      	at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:299)
      	at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:280)
      	at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:239)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
      	at hudson.remoting.Request$2.run(Request.java:326)
      	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
      	at java.util.concurrent.FutureTask.run(Unknown Source)
      	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
      	at hudson.remoting.Engine$1$1.run(Engine.java:63)
      	at java.lang.Thread.run(Unknown Source)
      Caused by: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null
      	at org.eclipse.jgit.transport.URIish.<init>(URIish.java:205)
      	at org.jenkinsci.plugins.gitclient.JGitAPIImpl.listRemoteBranches(JGitAPIImpl.java:879)
      	at org.jenkinsci.plugins.gitclient.JGitAPIImpl.prune(JGitAPIImpl.java:857)
      	... 16 more
      

        Attachments

          Issue Links

            Activity

            Hide
            pmv pmv added a comment -

            It looks like JGit 3.3 can now do pruning? "Support fetch.prune and remote.<name>.prune to set prune mode when fetching" - https://wiki.eclipse.org/JGit/New_and_Noteworthy/3.3

            Should a new ticket be opened to get this fix applied to the JGit implementation?

            Show
            pmv pmv added a comment - It looks like JGit 3.3 can now do pruning? "Support fetch.prune and remote.<name>.prune to set prune mode when fetching" - https://wiki.eclipse.org/JGit/New_and_Noteworthy/3.3 Should a new ticket be opened to get this fix applied to the JGit implementation?
            Hide
            markewaite Mark Waite added a comment -

            Code already exists in the JGit implementation to evaluate the prune implementation that was included in JGit 3.3. Unfortunately, the JGit 3.3 prune removes more branches than command line git. Since that would give incompatible behavior between CliGit and JGit, and CliGit is the reference implementation, the JGit prune at fetch can't be enabled.

            Refer to this submission which attempted to use JGit prune with JGit 3.5.2 and confirmed that it is still pruning too many branches.

            Show
            markewaite Mark Waite added a comment - Code already exists in the JGit implementation to evaluate the prune implementation that was included in JGit 3.3. Unfortunately, the JGit 3.3 prune removes more branches than command line git. Since that would give incompatible behavior between CliGit and JGit, and CliGit is the reference implementation, the JGit prune at fetch can't be enabled. Refer to this submission which attempted to use JGit prune with JGit 3.5.2 and confirmed that it is still pruning too many branches.
            Hide
            pmv pmv added a comment -

            Thanks for the update. Is there an open ticket I can watch for this feature (rather than commenting on this old one)?

            Personally I'd be in favor of a "use this feature with JGit at your own risk" message rather than not supporting prune at all, but I understand your logic.

            Show
            pmv pmv added a comment - Thanks for the update. Is there an open ticket I can watch for this feature (rather than commenting on this old one)? Personally I'd be in favor of a "use this feature with JGit at your own risk" message rather than not supporting prune at all, but I understand your logic.
            Hide
            markewaite Mark Waite added a comment -

            I've been unwilling to accept incompatible behavior between CliGit and JGit. Use at your own risk seems too risky for a plugin used in over 50 000 installations.

            You're welcome to open a separate bug report / enhancement request to track it. That seems like it will make it easier to track, and easier to report the problem to the upstream JGit process.

            Show
            markewaite Mark Waite added a comment - I've been unwilling to accept incompatible behavior between CliGit and JGit. Use at your own risk seems too risky for a plugin used in over 50 000 installations. You're welcome to open a separate bug report / enhancement request to track it. That seems like it will make it easier to track, and easier to report the problem to the upstream JGit process.
            Hide
            pmv pmv added a comment -

            Created and linked JENKINS-26197.

            Show
            pmv pmv added a comment - Created and linked JENKINS-26197 .

              People

              • Assignee:
                Unassigned
                Reporter:
                markewaite Mark Waite
              • Votes:
                3 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: