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

Git Publisher does not use Credentials

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Critical
    • Resolution: Fixed
    • Labels:
      None
    • Environment:
      Debian Wheezy with Jetty, Jenkins v1.541, git plugin 2.0, git-client 1.6.0, credentials plugin 1.9.4
    • Similar Issues:

      Description

      It seems that the GIT-Publisher does not use those credentials that are set for the repo.

      Checkout/Clone at the beginning of a job works fine and uses the set credentials.

      Fetching changes from the remote Git repository
      Fetching upstream changes from git@gi-server.tld/project.git
      using GIT_SSH to set credentials WRITE permissions for gitlab
      Checking out Revision XXXX (origin/SOME_BRANCH)
      

      As soon as I want the job to push a tag with GIT-Publisher, it fails since it does not use those credentials.

      [Boolean condition] checking [true] against [^(1|y|yes|t|true|on|run)$] (origin token: true)
      Run condition [Boolean condition] enabling perform for step [Git Publisher]
      Pushing tag job-name-release-296 to repo origin
      ERROR: Failed to push tag job-name-release-296 to origin
      hudson.plugins.git.GitException: Command "git push git@git-server.tld/project.git job-name-release-296" returned status code 128:
      stdout: 
      stderr: Access denied.
      fatal: The remote end hung up unexpectedly
      
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1099)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:985)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.push(CliGitAPIImpl.java:1123)
      	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.push(CliGitAPIImpl.java:1135)
      	at hudson.plugins.git.GitAPI.push(GitAPI.java:65)
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      	at java.lang.reflect.Method.invoke(Method.java:616)
      	at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274)
      	at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:255)
      	at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
      	at hudson.remoting.Request$2.run(Request.java:287)
      	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
      	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
      	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
      	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
      	at hudson.remoting.Engine$1$1.run(Engine.java:60)
      	at java.lang.Thread.run(Thread.java:679)
      Build step 'Flexible publish' changed build result to FAILURE
      

      This issue, together with JENKINS-21110 renders the GIT-Publisher rather unusable.

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment -

          Confirmed closed in git-client-plugin 1.6.2

          Show
          markewaite Mark Waite added a comment - Confirmed closed in git-client-plugin 1.6.2
          Hide
          andreybelyaevskiy Andrey Belyaevskiy added a comment - - edited

          Perhaps, I faced to same issue

          Recording test results
           > /usr/bin/git tag -l 184 # timeout=10
           > /usr/bin/git tag -a -f -m Jenkins Git plugin tagging with 184 184 # timeout=10
          Pushing tag 184 to repo origin
          using GIT_SSH to set credentials 
           > /usr/bin/git --version # timeout=10
           > /usr/bin/git -c core.askpass=true push ssh://git@sk-stash.url.com:7999/par/prsq.git 184 -f
          ERROR: Failed to push tag 184 to origin
          hudson.plugins.git.GitException: Command "/usr/bin/git -c core.askpass=true push ssh://git@sk-stash.url.com:7999/par/parseq.git 184 -f" returned status code 128:
          stdout: 
          stderr: fatal: remote error: Insufficient permissions
          You do not have permission to push to the repository Prsq in project PRSQ
          fatal: Could not read from remote repository.
          

          on versions Git plugin 2.4.0, git client plugin 1.19.0, jenkins 1.581

          Show
          andreybelyaevskiy Andrey Belyaevskiy added a comment - - edited Perhaps, I faced to same issue Recording test results > /usr/bin/git tag -l 184 # timeout=10 > /usr/bin/git tag -a -f -m Jenkins Git plugin tagging with 184 184 # timeout=10 Pushing tag 184 to repo origin using GIT_SSH to set credentials > /usr/bin/git --version # timeout=10 > /usr/bin/git -c core.askpass= true push ssh: //git@sk-stash.url.com:7999/par/prsq.git 184 -f ERROR: Failed to push tag 184 to origin hudson.plugins.git.GitException: Command "/usr/bin/git -c core.askpass= true push ssh: //git@sk-stash.url.com:7999/par/parseq.git 184 -f" returned status code 128: stdout: stderr: fatal: remote error: Insufficient permissions You do not have permission to push to the repository Prsq in project PRSQ fatal: Could not read from remote repository. on versions Git plugin 2.4.0, git client plugin 1.19.0, jenkins 1.581
          Hide
          markewaite Mark Waite added a comment -

          Andrey Belyaevskiy I doubt this bug has reappeared.

          I'm using git plugin 2.4.0 and git client plugin 1.19.0 on multiple machines, with each of them pushing changes to an ssh authenticated central repository. I believe many other users are doing the same with that version of the plugin. The plugin stats show that version 2.4.0 is installed in over 21000 installations and this is quite a common use case.

          You may want to investigate other possible causes for the failure to push that tag.

          As you investigate further, could you update this bug report with your results? I was tempted to immediately mark the issue as resolved, but thought it should wait for you to do some further investigation.

          Show
          markewaite Mark Waite added a comment - Andrey Belyaevskiy I doubt this bug has reappeared. I'm using git plugin 2.4.0 and git client plugin 1.19.0 on multiple machines, with each of them pushing changes to an ssh authenticated central repository. I believe many other users are doing the same with that version of the plugin. The plugin stats show that version 2.4.0 is installed in over 21000 installations and this is quite a common use case. You may want to investigate other possible causes for the failure to push that tag. As you investigate further, could you update this bug report with your results? I was tempted to immediately mark the issue as resolved, but thought it should wait for you to do some further investigation.
          Hide
          andreybelyaevskiy Andrey Belyaevskiy added a comment -

          I found that my key I use for repo clone have read only access in Stash repository as described in http://stackoverflow.com/questions/32627821/push-tag-to-stash-for-successfull-build-in-jenkins-fails-with-code-128-and-error/32643868#32643868. After I changed key to RW one all works fine.

          I'm Sorry for wrong re-open.

          Show
          andreybelyaevskiy Andrey Belyaevskiy added a comment - I found that my key I use for repo clone have read only access in Stash repository as described in http://stackoverflow.com/questions/32627821/push-tag-to-stash-for-successfull-build-in-jenkins-fails-with-code-128-and-error/32643868#32643868 . After I changed key to RW one all works fine. I'm Sorry for wrong re-open.
          Hide
          markewaite Mark Waite added a comment -

          Thanks for the update. I'm glad that it is still fixed.

          I dream of someday finding a way to provide better diagnostics for permission errors. Most permission errors can have multiple causes, and the process to evaluate to root cause can be quite complex, but it seems like it would be possible, and would be much more user friendly if several possible causes could be suggested.

          In your case, the root cause analysis would need to realize that reading the repository was successful, but writing the repository failed. In other cases, the problem could be an incorrect private key, or the wrong public key being registered with the server, or the wrong host key being recorded on the client, or many other causes.

          Show
          markewaite Mark Waite added a comment - Thanks for the update. I'm glad that it is still fixed. I dream of someday finding a way to provide better diagnostics for permission errors. Most permission errors can have multiple causes, and the process to evaluate to root cause can be quite complex, but it seems like it would be possible, and would be much more user friendly if several possible causes could be suggested. In your case, the root cause analysis would need to realize that reading the repository was successful, but writing the repository failed. In other cases, the problem could be an incorrect private key, or the wrong public key being registered with the server, or the wrong host key being recorded on the client, or many other causes.

            People

            • Assignee:
              markewaite Mark Waite
              Reporter:
              der_do Udo Waechter
            • Votes:
              2 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: