• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • None
    • In this case: Jenkins 1.536 (Jenkins version doesn't really matter :) running on Linux(CentOS6.4) respectively MacOSX(Mavericks)
      Plugins: git v 2.0, git-client 1.4.6

      When using the git plugin 2.0 and git-client plugin 1.4.6 the connection to a remote git repository via https fails.
      Using a connection URL like https://<user>:<password>@<URL> I receive a "failed to connect" where the connection URL was reduced to https://<user>@<URL> - where of course was clear why it failed: The password wasn't submitted !?

      Reverting to versions 1.5.0 (git) respectively 1.0.7 (git-client) and a Jenkins restart solved it. Keeping one of both plugins on the newer version and only downgrading the other produced another symptom: The GIT was no longer available for configuration in Jenkins. So there's a dependency between both plugins.

      The "million-dollar-question" is: Is this a bug in those plugins? Or or do they simply need to be handled/configured differently. I didn't find any hint on this so far ..

          [JENKINS-20533] Git2 plugin and HTTP-authentication fails

          Coleman added a comment -

          Running into the same behavior on our Jenkins install using https://username:password@host URLs

          Coleman added a comment - Running into the same behavior on our Jenkins install using https://username:password@host URLs

          Mark Waite added a comment -

          The git plugin 2.0 now connects with the credentials plugin. You should be able to create a new credential in the "Manage Credentials" panel ( http://localhost:8080/credentials/? ), then use that credential for the https authentication with git plugin 2.0.

          Since this is the first release of the git plugin with support for the credentials plugin, the documentation is still sparse, but you may be able to infer how to use it without detailed documentation.

          Mark Waite added a comment - The git plugin 2.0 now connects with the credentials plugin. You should be able to create a new credential in the "Manage Credentials" panel ( http://localhost:8080/credentials/? ), then use that credential for the https authentication with git plugin 2.0. Since this is the first release of the git plugin with support for the credentials plugin, the documentation is still sparse, but you may be able to infer how to use it without detailed documentation.

          We are also experiencing this problem. I have found no way to get this working, even with assorted values in the credentials plugin. My best guess at the moment is that the plugin is unable to deal with self-signed SSL certificates... but since I don't have a non-self-signed certificate to switch to, I can't confirm.

          The only solution I've found is reverting all the way back to git 1.2.0 plugin as described at https://issues.jenkins-ci.org/browse/JENKINS-17204. Versions 1.3.0 through 1.5.0 failed with one error message; Version 2.0 continues to fail, although with a different error message:

          Started by user My Name
          [EnvInject] - Loading node environment variables.
          Building on master in workspace D:\Jenkins\jobs\test\workspace
          Fetching changes from the remote Git repository
          Fetching upstream changes from https://validusername@git.domainname.net/scm/SVC/devkit.git
          FATAL: Failed to fetch from https://validusername@git.domainname.net/scm/SVC/devkit.git
          hudson.plugins.git.GitException: Failed to fetch from https://validusername@git.domainname.net/scm/SVC/devkit.git
          	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:612)
          	at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:836)
          	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:861)
          	at hudson.model.AbstractProject.checkout(AbstractProject.java:1412)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652)
          	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:557)
          	at hudson.model.Run.execute(Run.java:1679)
          	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
          	at hudson.model.ResourceController.execute(ResourceController.java:88)
          	at hudson.model.Executor.run(Executor.java:230)
          Caused by: hudson.plugins.git.GitException: Failed to connect to https://validusername@git.domainname.net/scm/SVC/devkit.git
          	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getURLWithCrendentials(CliGitAPIImpl.java:1441)
          	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.fetch(CliGitAPIImpl.java:179)
          	at hudson.plugins.git.GitAPI.fetch(GitAPI.java:229)
          	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:610)
          	... 10 more
          

          I have a valid "Username with password" credential selected. On the project configuration page, it presents a red error message:

          Failed to connect to repository : Failed to connect to https://git.domainname.net/scm/SVC/devkit.git using credentials credentialsname

          Jonathan Brecher added a comment - We are also experiencing this problem. I have found no way to get this working, even with assorted values in the credentials plugin. My best guess at the moment is that the plugin is unable to deal with self-signed SSL certificates... but since I don't have a non-self-signed certificate to switch to, I can't confirm. The only solution I've found is reverting all the way back to git 1.2.0 plugin as described at https://issues.jenkins-ci.org/browse/JENKINS-17204 . Versions 1.3.0 through 1.5.0 failed with one error message; Version 2.0 continues to fail, although with a different error message: Started by user My Name [EnvInject] - Loading node environment variables. Building on master in workspace D:\Jenkins\jobs\test\workspace Fetching changes from the remote Git repository Fetching upstream changes from https: //validusername@git.domainname.net/scm/SVC/devkit.git FATAL: Failed to fetch from https: //validusername@git.domainname.net/scm/SVC/devkit.git hudson.plugins.git.GitException: Failed to fetch from https: //validusername@git.domainname.net/scm/SVC/devkit.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:612) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:836) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:861) at hudson.model.AbstractProject.checkout(AbstractProject.java:1412) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:557) at hudson.model.Run.execute(Run.java:1679) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:230) Caused by: hudson.plugins.git.GitException: Failed to connect to https: //validusername@git.domainname.net/scm/SVC/devkit.git at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getURLWithCrendentials(CliGitAPIImpl.java:1441) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.fetch(CliGitAPIImpl.java:179) at hudson.plugins.git.GitAPI.fetch(GitAPI.java:229) at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:610) ... 10 more I have a valid "Username with password" credential selected. On the project configuration page, it presents a red error message: Failed to connect to repository : Failed to connect to https: //git.domainname.net/scm/SVC/devkit.git using credentials credentialsname

          Mark Waite added a comment -

          I've read in other bug reports that self signed certificates are a problem.
          I don't recall the details of the problem, only that they were a problem.

          The only work around I've heard is to switch protocol to something other
          than https. Can you use ssh instead of https?

          Mark Waite added a comment - I've read in other bug reports that self signed certificates are a problem. I don't recall the details of the problem, only that they were a problem. The only work around I've heard is to switch protocol to something other than https. Can you use ssh instead of https?

          Michael Tutty added a comment -

          It's not self-signed certs in my case. Something is wrong with either the default credentials added to the GitClient instance, or the format of the command that's actually run. No network request is ever opened from the Jenkins server, it fails immediately.

          Notice line 150 in the Git plugin's job configuration code: https://github.com/jenkinsci/git-plugin/blame/master/src/main/java/hudson/plugins/git/UserRemoteConfig.java - it was changed on 10-09-13.

          Also check line 1261 in the Git client implementation: https://github.com/jenkinsci/git-client-plugin/blame/master/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java - credential-related changes also made about a month ago.

          This would be a great place to add some logging code, I was unable to diagnose anything with the logging facility in Jenkins web UI. Specifically, it would be great when the underlying process returns != 0, to know the exact command-line and args that were used, as well as the contents of STDOUT and STDERR.

          Michael Tutty added a comment - It's not self-signed certs in my case. Something is wrong with either the default credentials added to the GitClient instance, or the format of the command that's actually run. No network request is ever opened from the Jenkins server, it fails immediately. Notice line 150 in the Git plugin's job configuration code: https://github.com/jenkinsci/git-plugin/blame/master/src/main/java/hudson/plugins/git/UserRemoteConfig.java - it was changed on 10-09-13. Also check line 1261 in the Git client implementation: https://github.com/jenkinsci/git-client-plugin/blame/master/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java - credential-related changes also made about a month ago. This would be a great place to add some logging code, I was unable to diagnose anything with the logging facility in Jenkins web UI. Specifically, it would be great when the underlying process returns != 0, to know the exact command-line and args that were used, as well as the contents of STDOUT and STDERR.

          Switching to ssh for us would require significant user retraining, and updating of hundreds of existing Jenkins jobs. So yes, we can switch to ssh. It wouldn't be our first choice, though. Downgrading to 1.2.0 of the Git plugin isn't our first choice either, but way higher on the list than switching to ssh.

          Jonathan Brecher added a comment - Switching to ssh for us would require significant user retraining, and updating of hundreds of existing Jenkins jobs. So yes, we can switch to ssh. It wouldn't be our first choice, though. Downgrading to 1.2.0 of the Git plugin isn't our first choice either, but way higher on the list than switching to ssh.

          Michael Tutty added a comment -

          I downgraded git-client and git packages in Jenkins, and it's working again.

          Michael Tutty added a comment - I downgraded git-client and git packages in Jenkins, and it's working again.

          In our case, git-client seems NOT to be a problem.
          git-client 1.4.6 with git 1.2.0 works fine
          git-client 1.4.6 with git 2.0 fails

          Jonathan Brecher added a comment - In our case, git-client seems NOT to be a problem. git-client 1.4.6 with git 1.2.0 works fine git-client 1.4.6 with git 2.0 fails

          Juergen Klasen added a comment - - edited

          Today I was able to check that issue again on a non-production environment:
          I upgraded the git-client plugin (again) to version 1.4.6 and git plugin to 2.0
          I checked to have a valid credential configured in the credential plugin
          -> scope 'global', username=xxx, password=yyy (where 'xxx' and 'yyy' are valid for my git server - like said
          A correct selfsigned certificate is there (else it wouldn't work with the older plugins 1.0.7 resp. 1.5.0 )
          I configured my job to use a connection URL to the git server like
          https://<myserver>/<myrepository>
          and selected the credentials for user 'xxx'

          Result is, that I receive a

          "Failed to connect to repository : Failed to connect to https://<myserver>/<myrepository> using credentials connection to GIT repo on <myserver>" error.

          So, either there's a bug with the git-related plugins, or the credentials plugin ?

          What else to do, in order to provide more debugging information?

          Juergen Klasen added a comment - - edited Today I was able to check that issue again on a non-production environment: I upgraded the git-client plugin (again) to version 1.4.6 and git plugin to 2.0 I checked to have a valid credential configured in the credential plugin -> scope 'global', username=xxx, password=yyy (where 'xxx' and 'yyy' are valid for my git server - like said A correct selfsigned certificate is there (else it wouldn't work with the older plugins 1.0.7 resp. 1.5.0 ) I configured my job to use a connection URL to the git server like https://<myserver>/<myrepository> and selected the credentials for user 'xxx' Result is, that I receive a "Failed to connect to repository : Failed to connect to https://<myserver>/<myrepository> using credentials connection to GIT repo on <myserver>" error. So, either there's a bug with the git-related plugins, or the credentials plugin ? What else to do, in order to provide more debugging information?

          Sam Xiao added a comment -

          I have the same problem with Gerrit's SSH URL

          11:04:53 Building remotely on bob-10.47 in workspace /home/jenkins/slave-root/workspace/gerrit_client_android_build_debug
          11:04:53 
          11:04:53 Deleting project workspace... done
          11:04:53 
          11:04:53 Cloning the remote Git repository
          11:04:53 Cloning repository ssh://XXXXXXXXXX:29418/client.git
          11:04:53 git --version
          11:04:53 git version 1.8.4.2
          11:05:15 ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
          

          Here suggest a downgrade:
          https://groups.google.com/forum/#!topic/repo-discuss/BWjtSX07IpQ

          Sam Xiao added a comment - I have the same problem with Gerrit's SSH URL 11:04:53 Building remotely on bob-10.47 in workspace /home/jenkins/slave-root/workspace/gerrit_client_android_build_debug 11:04:53 11:04:53 Deleting project workspace... done 11:04:53 11:04:53 Cloning the remote Git repository 11:04:53 Cloning repository ssh://XXXXXXXXXX:29418/client.git 11:04:53 git --version 11:04:53 git version 1.8.4.2 11:05:15 ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job. Here suggest a downgrade: https://groups.google.com/forum/#!topic/repo-discuss/BWjtSX07IpQ

          Michael Tutty added a comment -

          Juergen, that is the same behavior I saw as well. It didn't matter whether I had a credential, added one or removed one, it always failed the same way.
          Your question about further debugging info is exactly why I suggested better logging in this section. There isn't anything I could find to gather more data at runtime.

          Michael Tutty added a comment - Juergen, that is the same behavior I saw as well. It didn't matter whether I had a credential, added one or removed one, it always failed the same way. Your question about further debugging info is exactly why I suggested better logging in this section. There isn't anything I could find to gather more data at runtime.

          Ean Rollings added a comment - - edited

          so my odd error is around the password. when the password contains a dollar sign ($), it seems to be sending the value as "%24" instead of a $ (maybe desired behavior for other parts of the URI but not for the password). In my case, the password began with a dollar sign.

          the important bit of the error message I was getting is:

          stderr: error: The requested URL returned error: 401 while accessing https://USERNAME:%24-the-rest-of-the-password@git.url/...

          Ean Rollings added a comment - - edited so my odd error is around the password. when the password contains a dollar sign ($), it seems to be sending the value as "%24" instead of a $ (maybe desired behavior for other parts of the URI but not for the password). In my case, the password began with a dollar sign. the important bit of the error message I was getting is: stderr: error: The requested URL returned error: 401 while accessing https://USERNAME:%24-the-rest-of-the-password@git.url/ ...

          Artem Belov added a comment -

          Have the same issue with git 2.0 and git-client 1.6 plugins
          I was trying to fix it using previous versions.
          In all these versions auth was broken due to some reasons,

          Caused by: hudson.plugins.git.GitException: Failed to connect to https://stash.***/***.git using credentials YYY (status = 403)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkCredentials(CliGitAPIImpl.java:1610)

          hudson.plugins.git.GitException: Failed to connect to https://login@stash.***/***.git (status = 403)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getURLWithCrendentials(CliGitAPIImpl.java:1437)

          hudson.plugins.git.GitException: Failed to connect to https://login@stash.***/***.git (status = 403)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkCredentials(CliGitAPIImpl.java:1597)

          hudson.plugins.git.GitException: Failed to connect to https://login@stash.***/***.git (status = 403)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkCredentials(CliGitAPIImpl.java:1610)

          and so on. Sorry, couldn't map these messages to versions now. It was both versions with integrated credentials plugin and without it.

          The only working solution was roll back to git 1.5 and git-client 1.0.7.

          I guess one of the possible causes of the bug is that my git login contains @ sign which should be replaced by %40 to be put into connection string correctly. And it's not clear should I use it when define login/password pair in credentials password. Anyway, it's just a guess, because neither @ nor %40 worked

          Some info about enviroment:

          1. Git server is internal Atlassian Stash
          2. We have to use https instead of SSL because of firewall issues
          3. To force it we use sslVerify = false in git config
          4. It properly works using CLI directly and from Jenkins with plugins git 1.5 and git-client 1.0.7 but not later ones.

          Artem Belov added a comment - Have the same issue with git 2.0 and git-client 1.6 plugins I was trying to fix it using previous versions. In all these versions auth was broken due to some reasons, Caused by: hudson.plugins.git.GitException: Failed to connect to https://stash.***/***.git using credentials YYY (status = 403) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkCredentials(CliGitAPIImpl.java:1610) hudson.plugins.git.GitException: Failed to connect to https://login@stash.***/***.git (status = 403) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getURLWithCrendentials(CliGitAPIImpl.java:1437) hudson.plugins.git.GitException: Failed to connect to https://login@stash.***/***.git (status = 403) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkCredentials(CliGitAPIImpl.java:1597) hudson.plugins.git.GitException: Failed to connect to https://login@stash.***/***.git (status = 403) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkCredentials(CliGitAPIImpl.java:1610) and so on. Sorry, couldn't map these messages to versions now. It was both versions with integrated credentials plugin and without it. The only working solution was roll back to git 1.5 and git-client 1.0.7 . I guess one of the possible causes of the bug is that my git login contains @ sign which should be replaced by %40 to be put into connection string correctly. And it's not clear should I use it when define login/password pair in credentials password. Anyway, it's just a guess, because neither @ nor %40 worked Some info about enviroment: Git server is internal Atlassian Stash We have to use https instead of SSL because of firewall issues To force it we use sslVerify = false in git config It properly works using CLI directly and from Jenkins with plugins git 1.5 and git-client 1.0.7 but not later ones.

          John Mickey added a comment -

          I upgraded Jenkins and Git plugins yesterday to the latest versions and ran into the same problems. We also use Atlassian Stash and the http credentials stopped working.

          We reverted to git 2.0 and git-client 1.4.6.

          This is the error

          using .gitcredentials to set credentials
          Could not remove the credential section from the git configuration
          ERROR: Error cloning remote repo 'origin'
          hudson.plugins.git.GitException: Command "git config --local credential.helper store --file=/tmp/git1201805025806835574.credentials" returned status code 129:
          stdout:
          stderr: error: unknown option `local'
          usage: git config [options]

          Config file location
          --global use global config file
          --system use system config file
          -f, --file <FILE> use given config file

          Action
          --get get value: name [value-regex]
          --get-all get all values: key [value-regex]
          --get-regexp get values for regexp: name-regex [value-regex]
          --replace-all replace all matching variables: name value [value_regex]
          --add adds a new variable: name value
          --unset removes a variable: name [value-regex]
          --unset-all removes all matches: name [value-regex]
          --rename-section rename section: old-name new-name
          --remove-section remove a section: name
          -l, --list list all
          -e, --edit opens an editor
          --get-color <slot> find the color configured: [default]
          --get-colorbool <slot>
          find the color setting: [stdout-is-tty]

          Type
          --bool value is "true" or "false"
          --int value is decimal number
          --bool-or-int value is --bool or --int
          --path value is a path (file or directory name)

          Other
          -z, --null terminate values with NUL byte

          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1148)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1125)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1121)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1117)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1014)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:74)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:207)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:356)
          at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
          at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
          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(FutureTask.java:262)
          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
          at hudson.remoting.Engine$1$1.run(Engine.java:63)
          at java.lang.Thread.run(Thread.java:744)
          ERROR: null

          John Mickey added a comment - I upgraded Jenkins and Git plugins yesterday to the latest versions and ran into the same problems. We also use Atlassian Stash and the http credentials stopped working. We reverted to git 2.0 and git-client 1.4.6. This is the error using .gitcredentials to set credentials Could not remove the credential section from the git configuration ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Command "git config --local credential.helper store --file=/tmp/git1201805025806835574.credentials" returned status code 129: stdout: stderr: error: unknown option `local' usage: git config [options] Config file location --global use global config file --system use system config file -f, --file <FILE> use given config file Action --get get value: name [value-regex] --get-all get all values: key [value-regex] --get-regexp get values for regexp: name-regex [value-regex] --replace-all replace all matching variables: name value [value_regex] --add adds a new variable: name value --unset removes a variable: name [value-regex] --unset-all removes all matches: name [value-regex] --rename-section rename section: old-name new-name --remove-section remove a section: name -l, --list list all -e, --edit opens an editor --get-color <slot> find the color configured: [default] --get-colorbool <slot> find the color setting: [stdout-is-tty] Type --bool value is "true" or "false" --int value is decimal number --bool-or-int value is --bool or --int --path value is a path (file or directory name) Other -z, --null terminate values with NUL byte at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1148) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1125) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1121) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1117) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1014) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:74) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:207) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:356) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146) 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(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at hudson.remoting.Engine$1$1.run(Engine.java:63) at java.lang.Thread.run(Thread.java:744) ERROR: null

          Mark Waite added a comment -

          I think that stack trace indicates that your version of command line git does not understand the "--local" option to the config command. What version of git is running on that machine?

          Could you attempt the same operations using JGit by configuring another Git implementation in the Jenkins global configuration and choosing JGit from that list?

          Mark Waite added a comment - I think that stack trace indicates that your version of command line git does not understand the "--local" option to the config command. What version of git is running on that machine? Could you attempt the same operations using JGit by configuring another Git implementation in the Jenkins global configuration and choosing JGit from that list?

          Mark Waite added a comment -

          Mark Waite added a comment - http://stackoverflow.com/questions/5343068/is-there-a-way-to-skip-password-typing-when-using-https-github describes alternatives based on the version of git you are running.

          I'd like to update the info here with two things ...

          1st: (about the latest remarks on the GIT version) : YES, you need a GIT that understands the '--local' option. But even then ... (see 2nd)

          2nd: I got everything running okay with plugins 'credential-helper' 1.9.4, 'git plugin' 2.0.1 and 'GIT client plugin' 1.6.4 on a LINUX system. However using the same combination of plugins on WINDOWS, I still can't get it to work - although I'm using identical Jenkins configurations there !?

          P.S.: The Jenkins version was in both cases 1.549

          Obviously Jenkins is behaving differently on Windows and on Linux !??
          ... possibly an issue with the used Java version? On Linux I right now use Java7U45. On Windows the system is running Jenkins with J7U25.

          Can't upgrade the Java here now ... Maybe try this as next when the use of the machine allows "downtime".

          Can't test further on the Windows system this week, as this in produciton use ...

          Juergen Klasen added a comment - I'd like to update the info here with two things ... 1st: (about the latest remarks on the GIT version) : YES, you need a GIT that understands the '--local' option. But even then ... (see 2nd) 2nd: I got everything running okay with plugins 'credential-helper' 1.9.4, 'git plugin' 2.0.1 and 'GIT client plugin' 1.6.4 on a LINUX system. However using the same combination of plugins on WINDOWS, I still can't get it to work - although I'm using identical Jenkins configurations there !? P.S.: The Jenkins version was in both cases 1.549 Obviously Jenkins is behaving differently on Windows and on Linux !?? ... possibly an issue with the used Java version? On Linux I right now use Java7U45. On Windows the system is running Jenkins with J7U25. Can't upgrade the Java here now ... Maybe try this as next when the use of the machine allows "downtime". Can't test further on the Windows system this week, as this in produciton use ...

          Mark Waite added a comment -

          Is the Windows machine running the Jenkins process (master or slave) as a service?

          JENKINS-20356 reports that credentials don't work as expected on Windows when the Jenkins process is running as a service.

          Jenkins behaves differently on Windows and Linux in many cases, most often due to platform differences (symbolic links are handled quite differently between the two platforms, open files are handled quite differently between the two platforms, etc.).

          Mark Waite added a comment - Is the Windows machine running the Jenkins process (master or slave) as a service? JENKINS-20356 reports that credentials don't work as expected on Windows when the Jenkins process is running as a service. Jenkins behaves differently on Windows and Linux in many cases, most often due to platform differences (symbolic links are handled quite differently between the two platforms, open files are handled quite differently between the two platforms, etc.).

          Typically a Jenkins runs on a Windows box as service (so it does on a UNIX/LINUX env)
          ... and in my case it is like that
          However: The service is NOT started under the system account but runs under an own account (again: same as under UNIX the service doesn't run as 'root' user but under an own account)

          Why should one run a Jenkins service manually - unless it's for testing purposes?

          I can see a reason why it makes a difference if a procees runs under the system account, or under a user account. This is pretty evident.
          But I can not see a reason why it should make a difference whether a process is started during system startup, or later by a user - unless they would get a differently set up environment.
          But when starting a process under a user account, it should inherit all corresponding setting of the user, no matter if the service control manager is starting it, or not - right ?

          Juergen Klasen added a comment - Typically a Jenkins runs on a Windows box as service (so it does on a UNIX/LINUX env) ... and in my case it is like that However: The service is NOT started under the system account but runs under an own account (again: same as under UNIX the service doesn't run as 'root' user but under an own account) Why should one run a Jenkins service manually - unless it's for testing purposes? I can see a reason why it makes a difference if a procees runs under the system account, or under a user account. This is pretty evident. But I can not see a reason why it should make a difference whether a process is started during system startup, or later by a user - unless they would get a differently set up environment. But when starting a process under a user account, it should inherit all corresponding setting of the user, no matter if the service control manager is starting it, or not - right ?

          Mark Waite added a comment -

          I rarely run Jenkins as a service on any of the Windows machines I configure. Most of the products which I need to build and test are working from the assumption that if they are running on Windows they have access to the Windows Desktop. Access to the Windows Desktop is most directly available by running the Jenkins master and Jenkins slaves from a command prompt on the Windows Desktop.

          I realize that there is a setting which allows a service to interact with the Desktop, but that is not the typical environment where my programs run. They are more likely to run on a real desktop, as real desktop programs.

          There have been several bugs reported which have been related to Jenkins running as a service on Windows. I prefer to avoid those bugs by running on the Desktop.

          I don't know why the git-client-plugin has this difference when running from a service or not. If I find a way to write automated tests of credentials in the git-client-plugin, that will probably also lead to a solution to JENKINS-20356. Until then, it will probably remain open as a bug.

          Mark Waite added a comment - I rarely run Jenkins as a service on any of the Windows machines I configure. Most of the products which I need to build and test are working from the assumption that if they are running on Windows they have access to the Windows Desktop. Access to the Windows Desktop is most directly available by running the Jenkins master and Jenkins slaves from a command prompt on the Windows Desktop. I realize that there is a setting which allows a service to interact with the Desktop, but that is not the typical environment where my programs run. They are more likely to run on a real desktop, as real desktop programs. There have been several bugs reported which have been related to Jenkins running as a service on Windows. I prefer to avoid those bugs by running on the Desktop. I don't know why the git-client-plugin has this difference when running from a service or not. If I find a way to write automated tests of credentials in the git-client-plugin, that will probably also lead to a solution to JENKINS-20356 . Until then, it will probably remain open as a bug.

          Hmmmh, no sysadmin background ... I suppose ? (no offense here !)

          BUT: Why should one run a program that is supposed to provide a service function (this is where the name is coming from ) under the expectation that it has access to the Desktop?

          Jenkins is not meant to be run as a desktop program !!!

          Obviously you seem to have got the idea fundamentally wrong !?

          And: If there should be plugins for a service(and this is, what Jenkins is all about: a service!) which behave differently under such conditions they are implemented faulty. No discussion about that ...

          Maybe you're mixing things like "running under system account vs. running under a user account" ?

          Juergen Klasen added a comment - Hmmmh, no sysadmin background ... I suppose ? (no offense here !) BUT: Why should one run a program that is supposed to provide a service function (this is where the name is coming from ) under the expectation that it has access to the Desktop? Jenkins is not meant to be run as a desktop program !!! Obviously you seem to have got the idea fundamentally wrong !? And: If there should be plugins for a service(and this is, what Jenkins is all about: a service!) which behave differently under such conditions they are implemented faulty. No discussion about that ... Maybe you're mixing things like "running under system account vs. running under a user account" ?

          Mark Waite added a comment -

          Your assertion that Jenkins is supposed to provide a service function solely within the context of a Windows service does not match my use model, nor does it match the use model of many Jenkins users.

          Jenkins provides the capability to build, test, and report results. Many test contexts require desktop access.

          As an example, Selenium tests need access to a desktop so that they can drive the web browser. Desktop applications often assume desktop access even when running in test mode.

          Mark Waite added a comment - Your assertion that Jenkins is supposed to provide a service function solely within the context of a Windows service does not match my use model, nor does it match the use model of many Jenkins users. Jenkins provides the capability to build, test, and report results. Many test contexts require desktop access. As an example, Selenium tests need access to a desktop so that they can drive the web browser. Desktop applications often assume desktop access even when running in test mode.

          Again: No offense - BUT ...

          If your "use model" is to use Jenkins interactively, and believe that this is the intended way to use Jenkins then you must have got it wrong.

          JENKINS IS ALL ABOUT USING IT AS A SERVICE.

          Jenkins is supposed to run on some (if you want to put it this way) "background server", doing tasks like

          • building software in an automated way
          • running unit tests, code coverage and stylecheck test
            additionally it can
          • deploy the build results to testing environments
          • trigger tests of the deployed software remotely
          • collect the test results
          • display them as report on the jobs dashboard page
            etc.

          And it's supposed to do all this with NO INTERACTION required!

          If you don't get this concept - and do not accept that this is the main usage of Jenkins - then you are definitely on a wrong path !

          Sorry ...

          Juergen Klasen added a comment - Again: No offense - BUT ... If your "use model" is to use Jenkins interactively, and believe that this is the intended way to use Jenkins then you must have got it wrong. JENKINS IS ALL ABOUT USING IT AS A SERVICE. Jenkins is supposed to run on some (if you want to put it this way) "background server", doing tasks like building software in an automated way running unit tests, code coverage and stylecheck test additionally it can deploy the build results to testing environments trigger tests of the deployed software remotely collect the test results display them as report on the jobs dashboard page etc. And it's supposed to do all this with NO INTERACTION required! If you don't get this concept - and do not accept that this is the main usage of Jenkins - then you are definitely on a wrong path ! Sorry ...

          Mark Waite added a comment -

          This exchange seems to be no longer useful.

          It seems you will continue to insist that I'm on the wrong path if I require desktop access for tests. I've invested many years contributing to Jenkins, using Jenkins, and administering continuous integration servers. I'm comfortable that mine is not the only use model, but am just as comfortable that the use model you're proposing is also not the only use model. The Selenium test users (including Jenkins' own testing with Selenium) would likely disagree with you, as would all those users who use the Xvnc plugin on Linux.

          I'll resume trying to contribute to Jenkins, without worrying about your perceptions of how I use Jenkins.

          Mark Waite added a comment - This exchange seems to be no longer useful. It seems you will continue to insist that I'm on the wrong path if I require desktop access for tests. I've invested many years contributing to Jenkins, using Jenkins, and administering continuous integration servers. I'm comfortable that mine is not the only use model, but am just as comfortable that the use model you're proposing is also not the only use model. The Selenium test users (including Jenkins' own testing with Selenium) would likely disagree with you, as would all those users who use the Xvnc plugin on Linux. I'll resume trying to contribute to Jenkins, without worrying about your perceptions of how I use Jenkins.

          <quote>This exchange seems to be no longer useful.</quote>

          Full ACK - This exchange really seems to be no longer useful.

          ----------
          BTW - About running Selenium Tests: The typical way is to deploy the built software package to a (mostly remote) testing environment (along with the Selenium scripts), then trigger the script execution on this environment, collect the test result data and display it in the report on Jenkins.

          We have done lot's of this, and all work without trouble and don't require any desktop/user-interface interaction at all.

          Juergen Klasen added a comment - <quote>This exchange seems to be no longer useful.</quote> Full ACK - This exchange really seems to be no longer useful. ---------- BTW - About running Selenium Tests: The typical way is to deploy the built software package to a (mostly remote) testing environment (along with the Selenium scripts), then trigger the script execution on this environment, collect the test result data and display it in the report on Jenkins. We have done lot's of this, and all work without trouble and don't require any desktop/user-interface interaction at all.

          SANJAY TIWARI added a comment -

          I do not see any recent update to this issue. What is the conclusion on resolving this issue? What I see is that jenkins must be run as service Linux/Windows, does that mean you need to have a dedicated Linux/Windows account for it?

          SANJAY TIWARI added a comment - I do not see any recent update to this issue. What is the conclusion on resolving this issue? What I see is that jenkins must be run as service Linux/Windows, does that mean you need to have a dedicated Linux/Windows account for it?

          Mark Waite added a comment - - edited

          Jenkins may be run as a service on both Linux and Windows.

          When Jenkins is installed using the Windows (MSI) installer, it is installed as a service and runs with the permissions of a service, similar to many other Windows services. No dedicated Windows account is required for it.

          When Jenkins is installed using the Debian package manager (Debian, Ubuntu, etc.), a "jenkins" user is created and that user is the user which runs Jenkins.

          When Jenkins is installed using the Red Hat package manager (Red Hat, CentOS, Scientific Linux, Oracle Linux, etc.), I believe a "jenkins" user is created and that is the user which runs Jenkins.

          Mark Waite added a comment - - edited Jenkins may be run as a service on both Linux and Windows. When Jenkins is installed using the Windows (MSI) installer, it is installed as a service and runs with the permissions of a service, similar to many other Windows services. No dedicated Windows account is required for it. When Jenkins is installed using the Debian package manager (Debian, Ubuntu, etc.), a "jenkins" user is created and that user is the user which runs Jenkins. When Jenkins is installed using the Red Hat package manager (Red Hat, CentOS, Scientific Linux, Oracle Linux, etc.), I believe a "jenkins" user is created and that is the user which runs Jenkins.

          Juergen Klasen added a comment - - edited

          When running Jenkins as a service, using a dedicated user account here for is a must!!!

          Under Linux you don't want to run your service as root user. Similar you don't want to run the Jenkins service on Windows under the 'System Account'.

          And: YES, the pre-install script of that Linux rpm package does create the corresponding group and account named 'jenkins' for you. As well it registers Jenkins as service.

          For the Windows installation package I'm not sure. If I recall correctly there have been packages out which registered the service to run under the 'System Account' - which may no longer be true ...
          We ugraded the up'n running Windows Jenkins environments only with replacing the jenkins.war.

          But it's easy to check, under which account the Jenkins service is running under Windows (look into the Task manager )

          I have no update on the situation of git, git-client and credential-helper plugins on Windows though ... :|

          Juergen Klasen added a comment - - edited When running Jenkins as a service, using a dedicated user account here for is a must!!! Under Linux you don't want to run your service as root user. Similar you don't want to run the Jenkins service on Windows under the 'System Account'. And: YES, the pre-install script of that Linux rpm package does create the corresponding group and account named 'jenkins' for you. As well it registers Jenkins as service. For the Windows installation package I'm not sure. If I recall correctly there have been packages out which registered the service to run under the 'System Account' - which may no longer be true ... We ugraded the up'n running Windows Jenkins environments only with replacing the jenkins.war. But it's easy to check, under which account the Jenkins service is running under Windows (look into the Task manager ) I have no update on the situation of git, git-client and credential-helper plugins on Windows though ... :|

          Alpesh Shah added a comment -

          Hello,

          I did same as suggested by wgent above. i.e. roll back to git 1.5 (from 2.0.3) and git-client 1.0.7 (from 1.6.3) and it worked find. Note that I tried git-client 1.4.6 first so that I can use credential option but it didn't work. So I think correct combination of these 2 plugins are important. (I plan to try git-client 1.2.0 which has credential support to avoid passing username password in url)

          Alpesh Shah added a comment - Hello, I did same as suggested by wgent above. i.e. roll back to git 1.5 (from 2.0.3) and git-client 1.0.7 (from 1.6.3) and it worked find. Note that I tried git-client 1.4.6 first so that I can use credential option but it didn't work. So I think correct combination of these 2 plugins are important. (I plan to try git-client 1.2.0 which has credential support to avoid passing username password in url)

          Mark Waite added a comment -

          I am able to read and write a public bitbucket.org repository through https by embedding the user name and password into the URL, as in https://markewaite:mypassword@bitbucket.org/markewaite/git-client-plugin.git.

          I'm able to read and write a public bitbucket.org repository through https using a username / password credential through Jenkins credentials.

          I am not able to read or write a private bitbucket.org repository through https with the embedded user name and password in the URL or using the username / password credential through Jenkins credentials.

          Those results were checked with git plugin 2.2.5 and git client plugin 1.10.1.

          Mark Waite added a comment - I am able to read and write a public bitbucket.org repository through https by embedding the user name and password into the URL, as in https://markewaite:mypassword@bitbucket.org/markewaite/git-client-plugin.git . I'm able to read and write a public bitbucket.org repository through https using a username / password credential through Jenkins credentials. I am not able to read or write a private bitbucket.org repository through https with the embedded user name and password in the URL or using the username / password credential through Jenkins credentials. Those results were checked with git plugin 2.2.5 and git client plugin 1.10.1.

          Mark Waite added a comment -

          The call to checkCredentials() has been removed in git-client-plugin from 1.13.1 and beyond. Would you be willing to test a pre-release of git-client-plugin 1.13.1 for this case?

          Mark Waite added a comment - The call to checkCredentials() has been removed in git-client-plugin from 1.13.1 and beyond. Would you be willing to test a pre-release of git-client-plugin 1.13.1 for this case?

          Mark Waite added a comment -

          Call to checkCredentials removed in git-client-plugin 1.14.0, released 25 Dec 2014.

          Mark Waite added a comment - Call to checkCredentials removed in git-client-plugin 1.14.0, released 25 Dec 2014.

            ndeloof Nicolas De Loof
            jklasen Juergen Klasen
            Votes:
            11 Vote for this issue
            Watchers:
            19 Start watching this issue

              Created:
              Updated:
              Resolved: