• 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

          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: