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

failure when incorrect shell is configured is not clear enough to diagnose root cause.

      If you have a shell configured in "manage jenkins" and that shell is not available on the slave used by a workflow sh step, then the error does not help you diagnose the issue.

      e.g.

      node ('different_slave') {
        sh 'echo hello'
      }
      

      produces the following error

      [workflow_test] Running shell script
      sh: 1: /home/jenkins/slave/workspace/workflow_test/.e59a0d2c/script.sh: not found
      

      this implies an error with Jenkins code and not the configuration.

      Compare this to the same failure in a FreeStyle Job

      [huh] $ c:\cygwin64\bin\bash -xe /tmp/hudson2505861960930827932.sh
      FATAL: command execution failed
      java.io.IOException: Cannot run program "c:\cygwin64\bin\bash" (in directory "/home/jenkins/slave/workspace/huh"): error=2, No such file or directory
      

      Notice how the FreeStyle is explicit about which shell it is trying to run and what could not be found.

          [JENKINS-29877] failure when incorrect shell is configured is not clear enough to diagnose root cause.

          Jesse Glick added a comment -

          In the case of a traditional Shell step, Jenkins is actually trying to launch the bash process from Java, which throws that IOException if it does not exist. In the case of durable BourneShellScript, Jenkins is launching sh on a controller script, which in turn runs your script.sh with a shebang interpreter directive. And I suppose sh is printing this unhelpful message.

          Configuring a global shell is a very bad idea to begin with. Probably when it is set, BourneShellScript should note its value in a message.

          Jesse Glick added a comment - In the case of a traditional Shell step, Jenkins is actually trying to launch the bash process from Java, which throws that IOException if it does not exist. In the case of durable BourneShellScript , Jenkins is launching sh on a controller script, which in turn runs your script.sh with a shebang interpreter directive. And I suppose sh is printing this unhelpful message. Configuring a global shell is a very bad idea to begin with. Probably when it is set, BourneShellScript should note its value in a message.

          It seems odd that this never gave us trouble until the Pipeline. I agree its a lousy idea and I'd be willing to see the Shell option removed from Manage Jenkins -> System Configuration.

          Christian Höltje added a comment - It seems odd that this never gave us trouble until the Pipeline. I agree its a lousy idea and I'd be willing to see the Shell option removed from Manage Jenkins -> System Configuration.

            jglick Jesse Glick
            teilo James Nord
            Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: