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

GIT Build with Parameters is not listing branches

      We have a job and it is configured as "Build with Parameters".
      We have chosen "GIT Parameter" when we try to list "Branches/tags" while click build option it is not listing instead showing error message.
      But when we try build job able to clone with SSH keys:

      Command "git ls-remote -h ssh://server.de.xyz.com:7999/xdk/xdk110.git" returned status code 128:
      stdout:
      stderr: error: cannot run ssh: No such file or directory
      fatal: unable to fork
      

      We were using:

      • Jenkins LTS version "2.46.2"
      • Git plugin -->3.3.1
      • Git client plugin --->2.4.6
      • Git Parameter Plug-In--->0.8.0

        1. chrome_2019-02-20_18-34-30.png
          chrome_2019-02-20_18-34-30.png
          123 kB
        2. chrome_2019-02-20_18-34-30.png
          chrome_2019-02-20_18-34-30.png
          308 kB
        3. chrome_2019-02-20_18-41-40.png
          chrome_2019-02-20_18-41-40.png
          37 kB
        4. config-no-flyweight.xml
          6 kB
        5. config-windows-flyweight.xml
          6 kB
        6. Credentional_configuration.png
          Credentional_configuration.png
          46 kB
        7. few_builds.png
          few_builds.png
          76 kB
        8. github_key_add.png
          github_key_add.png
          22 kB
        9. image-2017-11-20-08-59-44-472.png
          2.33 MB
        10. image-2019-03-06-09-41-20-264.png
          image-2019-03-06-09-41-20-264.png
          370 kB
        11. image-2019-03-06-11-03-41-468.png
          image-2019-03-06-11-03-41-468.png
          39 kB
        12. Job_Test_2B_out.png
          Job_Test_2B_out.png
          68 kB
        13. Job_Test_2B.png
          Job_Test_2B.png
          143 kB
        14. Job_test_B_output.png
          Job_test_B_output.png
          220 kB
        15. Job_Test_B.png
          Job_Test_B.png
          132 kB
        16. Windows_slave_configuration.png
          Windows_slave_configuration.png
          71 kB

          [JENKINS-45480] GIT Build with Parameters is not listing branches

          delo delo added a comment -

          Please also note that the bug is present only when using SSH Git. When I use HTTPS connection, it works flawlessly.

          delo delo added a comment - Please also note that the bug is present only when using SSH Git. When I use HTTPS connection, it works flawlessly.

          Mark Waite added a comment -

          delovan the git plugin uses command line git to clone the repository. Command line git requires a script file that provides the private key for authentication to ssh repositories. That script file invokes the command ssh to provide authenticated transport between command line git and your git repository. That script can't find the ssh command on the path.

          That could be because the /tmp directory on the master is mounted with the noexec option. Refer to stackexchange for instructions to check the file system mount options.

          That could be because the PATH environment variable has been damaged or altered so that ssh is not on the PATH when running from the Jenkins master. The Jenkins "System Information" page will show you the value of the PATH environment variable on that Jenkins server.

          That could be because the ssh command has been removed from the master. Seems unlikely, but possible. Check for /usr/bin/ssh or /bin/ssh to confirm that you have an ssh command installed in the environment where Jenkins is running.

          The git plugin uses command line git to clone https repositories as well, but cloning an https repository uses a username / password instead of a private key. Cloning an https repository does not use ssh, while cloning an ssh based repository does use the ssh command.

          Mark Waite added a comment - delovan the git plugin uses command line git to clone the repository. Command line git requires a script file that provides the private key for authentication to ssh repositories. That script file invokes the command ssh to provide authenticated transport between command line git and your git repository. That script can't find the ssh command on the path. That could be because the /tmp directory on the master is mounted with the noexec option. Refer to stackexchange for instructions to check the file system mount options. That could be because the PATH environment variable has been damaged or altered so that ssh is not on the PATH when running from the Jenkins master. The Jenkins "System Information" page will show you the value of the PATH environment variable on that Jenkins server. That could be because the ssh command has been removed from the master. Seems unlikely, but possible. Check for /usr/bin/ssh or /bin/ssh to confirm that you have an ssh command installed in the environment where Jenkins is running. The git plugin uses command line git to clone https repositories as well, but cloning an https repository uses a username / password instead of a private key. Cloning an https repository does not use ssh, while cloning an ssh based repository does use the ssh command.

          delo delo added a comment -

          Hello markewaite and thank you for your response. 

          I also forget to mention that I run Jenkins under it's docker version.

          Therefore, the /tmp directory with noexec is not affected by that

          I did check the PATH variable, it's configured with _/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin_ so ssh is in it.

          When I docker exec into the docker container, I can launch ssh commands without issues.

           

          Is there a way to preserve the temporary bash scripts in _/_tmp that are used to launch the git commands? That way, it would be far easier to troubleshoot the issue.

          delo delo added a comment - Hello markewaite and thank you for your response.  I also forget to mention that I run Jenkins under it's docker version. Therefore, the /tmp directory with noexec is not affected by that I did check the PATH variable, it's configured with _/ usr /local/ sbin :/usr/local/bin:/usr/ sbin :/usr/bin:/sbin:/bin_ so ssh is in it. When I docker exec into the docker container, I can launch ssh commands without issues.   Is there a way to preserve the temporary bash scripts in _/_tmp that are used to launch the git commands? That way, it would be far easier to troubleshoot the issue.

          Mark Waite added a comment -

          There isn't a way to preserve the temporary bash scripts. That's intentional, since they contain credentials. We want the credential information to be removed from the disc as soon as possible.

          You could build a local copy of the git client plugin and remove the code in the finally block that deletes those temporary files.

          Mark Waite added a comment - There isn't a way to preserve the temporary bash scripts. That's intentional, since they contain credentials. We want the credential information to be removed from the disc as soon as possible. You could build a local copy of the git client plugin and remove the code in the finally block that deletes those temporary files.

          Robson Hermes added a comment -

          I had the same problem, and changing from SSH to HTTP did not work. I got the error below when trying HTTP:

           

          I managed to "fix" the problem by creating a new project cloning the existing one. The new one worked fine. I did not change any config at all. Thus I suppose this is really some sort of problem in the Git plugin. Not a user config problem.

          Robson Hermes added a comment - I had the same problem, and changing from SSH to HTTP did not work. I got the error below when trying HTTP:   I managed to "fix" the problem by creating a new project cloning the existing one. The new one worked fine. I did not change any config at all. Thus I suppose this is really some sort of problem in the Git plugin. Not a user config problem.

          delo delo added a comment -

          robsonhermes Are you sure it's durable ?

           

          With SSH, cloning the project was a workaround but only works for the very first build. Starting the 2nd build, it failed.

          delo delo added a comment - robsonhermes Are you sure it's durable ?   With SSH, cloning the project was a workaround but only works for the very first build. Starting the 2nd build, it failed.

          Robson Hermes added a comment -

          Oh damn it. You are right, now I have failure starting from the 2nd attempt.

          Robson Hermes added a comment - Oh damn it. You are right, now I have failure starting from the 2nd attempt.

          delo delo added a comment -

          robsonhermes, I suggest you do as markewaite suggested for keeping tmp files. I've done it and surprisingly I can't reproduce the bug anymore, even though I switch back to the original plugin.

          For info, after you build the plugin, just copy the plugin files over the original plugin (keep a backup) and restart jenkins.

          With theses files, you will be able to run them directly in bash and have more debug info.

          delo delo added a comment - robsonhermes , I suggest you do as markewaite suggested for keeping tmp files. I've done it and surprisingly I can't reproduce the bug anymore, even though I switch back to the original plugin. For info, after you build the plugin, just copy the plugin files over the original plugin (keep a backup) and restart jenkins. With theses files, you will be able to run them directly in bash and have more debug info.

          Amos Hason added a comment -

          Amos Hason added a comment - Related:  https://issues.jenkins-ci.org/browse/JENKINS-56558

          Amos Hason added a comment -

          In our case "/tmp" is not mounted with "noexec".

          I don't understand why it even tries to execute it on the master machine instead of the slave machine. It clearly should run on the slave machine.

          Amos Hason added a comment - In our case "/tmp" is not mounted with "noexec". I don't understand why it even tries to execute it on the master machine instead of the slave machine. It clearly should run on the slave machine.

            klimas7 Boguslaw Klimas
            spalani Senthilkumar Palanisamy
            Votes:
            3 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated:
              Resolved: