-
Story
-
Resolution: Unresolved
-
Major
As a Jenkins user, I'll like to use sh semantics to execute commands with args.
I believe Jenkins needs an args: parameter for the sh pipeline step, right now we have script:, returnStdout: and returnStatus: both useful to avoid messing around with shell redirection. However, is clearly impossible or at least difficult to have clean (and secure) executions with sh if they involve string interpolations, maybe Jenkins should do this automatically, but I'm not sure if that kind of magic could be counter productive, I rather depend on args.
Like:
sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def])
or a new pipeline step to avoid overloading sh with different behaviour
command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def])
On both cases echo the program, not the shell built-in should be executed, Jenkins should look for the program on the system's $PATH / %PATH% but also an absolute path should be supported too, like a regular Groovy execute() on a List.
["/bin/echo", "foo", "bar"].execute()
Is not common to have Groovy's execute() allowed on Jenkins sandboxed environment, probably for very good reasons.
Also even if execute() is allowed on the Jenkins sandbox, sh semantics are way more convenient.
For reference:
def proc = ['ls', '/meh'].execute() println proc.getText() println proc.exitValue() != 0
Where is stderr?
- is duplicated by
-
JENKINS-44991 Add cross-platform command step
-
- Resolved
-
- relates to
-
-
- Open
-
[JENKINS-44231] Safely pass args to sh step
| Description |
Original:
As a Jenkins user, I'll like to use {{sh}} semantics to execute commands with {{args}}. I believe Jenkins needs an {{args:}} parameter for the {{sh}} step command, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing with the {{FileSystem}}. However, is clearly impossible or at least difficult to have clean (and secure) executions with {{sh}} if they involve string interpolations, maybe Jenkins should do this automatically, but I'm not sure if that kind of magic could be counter productive, I rather depend on args. Like: {code:java} sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} or a new pipeline step to avoid overloading {{sh}} with different behaviour {code:java} command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} On both cases {{echo}} the program, not the shell built-in should be executed, Jenkins should look for the program on the system's {{$PATH}} / {{%PATH%}} but also an absolute path should be supported too, like a regular Groovy {{execute()}} on a List. {code:java} ["/bin/echo", "foo", "bar"].execute(){code} Is not common to have Groovy's {{execute()}} allowed on Jenkins sandboxed environment, probably for very good reasons. Also even {{execute()}} is allowed on the Jenkins sandbox, {{sh}} semantics are way more convenient. For reference: {code:java} def proc = ['ls', '/meh'].execute() println proc.getText() println proc.exitValue() != 0{code} |
New:
As a Jenkins user, I'll like to use {{sh}} semantics to execute commands with {{args}}. I believe Jenkins needs an {{args:}} parameter for the {{sh}} step command, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing with the {{FileSystem}}. However, is clearly impossible or at least difficult to have clean (and secure) executions with {{sh}} if they involve string interpolations, maybe Jenkins should do this automatically, but I'm not sure if that kind of magic could be counter productive, I rather depend on args. Like: {code:java} sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} or a new pipeline step to avoid overloading {{sh}} with different behaviour {code:java} command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} On both cases {{echo}} the program, not the shell built-in should be executed, Jenkins should look for the program on the system's {{$PATH}} / {{%PATH%}} but also an absolute path should be supported too, like a regular Groovy {{execute()}} on a List. {code:java} ["/bin/echo", "foo", "bar"].execute(){code} Is not common to have Groovy's {{execute()}} allowed on Jenkins sandboxed environment, probably for very good reasons. Also even if {{execute()}} is allowed on the Jenkins sandbox, {{sh}} semantics are way more convenient. For reference: {code:java} def proc = ['ls', '/meh'].execute() println proc.getText() println proc.exitValue() != 0{code} |
| Description |
Original:
As a Jenkins user, I'll like to use {{sh}} semantics to execute commands with {{args}}. I believe Jenkins needs an {{args:}} parameter for the {{sh}} step command, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing with the {{FileSystem}}. However, is clearly impossible or at least difficult to have clean (and secure) executions with {{sh}} if they involve string interpolations, maybe Jenkins should do this automatically, but I'm not sure if that kind of magic could be counter productive, I rather depend on args. Like: {code:java} sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} or a new pipeline step to avoid overloading {{sh}} with different behaviour {code:java} command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} On both cases {{echo}} the program, not the shell built-in should be executed, Jenkins should look for the program on the system's {{$PATH}} / {{%PATH%}} but also an absolute path should be supported too, like a regular Groovy {{execute()}} on a List. {code:java} ["/bin/echo", "foo", "bar"].execute(){code} Is not common to have Groovy's {{execute()}} allowed on Jenkins sandboxed environment, probably for very good reasons. Also even if {{execute()}} is allowed on the Jenkins sandbox, {{sh}} semantics are way more convenient. For reference: {code:java} def proc = ['ls', '/meh'].execute() println proc.getText() println proc.exitValue() != 0{code} |
New:
As a Jenkins user, I'll like to use {{sh}} semantics to execute commands with {{args}}. I believe Jenkins needs an {{args:}} parameter for the {{sh}} step command, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing with the {{FileSystem}}. However, is clearly impossible or at least difficult to have clean (and secure) executions with {{sh}} if they involve string interpolations, maybe Jenkins should do this automatically, but I'm not sure if that kind of magic could be counter productive, I rather depend on args. Like: {code:java} sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} or a new pipeline step to avoid overloading {{sh}} with different behaviour {code:java} command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} On both cases {{echo}} the program, not the shell built-in should be executed, Jenkins should look for the program on the system's {{$PATH}} / {{%PATH%}} but also an absolute path should be supported too, like a regular Groovy {{execute()}} on a List. {code:java} ["/bin/echo", "foo", "bar"].execute(){code} Is not common to have Groovy's {{execute()}} allowed on Jenkins sandboxed environment, probably for very good reasons. Also even if {{execute()}} is allowed on the Jenkins sandbox, {{sh}} semantics are way more convenient. For reference: {code:java} def proc = ['ls', '/meh'].execute() println proc.getText() println proc.exitValue() != 0{code} Where is `stderr`? |
| Description |
Original:
As a Jenkins user, I'll like to use {{sh}} semantics to execute commands with {{args}}. I believe Jenkins needs an {{args:}} parameter for the {{sh}} step command, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing with the {{FileSystem}}. However, is clearly impossible or at least difficult to have clean (and secure) executions with {{sh}} if they involve string interpolations, maybe Jenkins should do this automatically, but I'm not sure if that kind of magic could be counter productive, I rather depend on args. Like: {code:java} sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} or a new pipeline step to avoid overloading {{sh}} with different behaviour {code:java} command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} On both cases {{echo}} the program, not the shell built-in should be executed, Jenkins should look for the program on the system's {{$PATH}} / {{%PATH%}} but also an absolute path should be supported too, like a regular Groovy {{execute()}} on a List. {code:java} ["/bin/echo", "foo", "bar"].execute(){code} Is not common to have Groovy's {{execute()}} allowed on Jenkins sandboxed environment, probably for very good reasons. Also even if {{execute()}} is allowed on the Jenkins sandbox, {{sh}} semantics are way more convenient. For reference: {code:java} def proc = ['ls', '/meh'].execute() println proc.getText() println proc.exitValue() != 0{code} Where is `stderr`? |
New:
As a Jenkins user, I'll like to use {{sh}} semantics to execute commands with {{args}}. I believe Jenkins needs an {{args:}} parameter for the {{sh}} step command, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing with the {{FileSystem}}. However, is clearly impossible or at least difficult to have clean (and secure) executions with {{sh}} if they involve string interpolations, maybe Jenkins should do this automatically, but I'm not sure if that kind of magic could be counter productive, I rather depend on args. Like: {code:java} sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} or a new pipeline step to avoid overloading {{sh}} with different behaviour {code:java} command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} On both cases {{echo}} the program, not the shell built-in should be executed, Jenkins should look for the program on the system's {{$PATH}} / {{%PATH%}} but also an absolute path should be supported too, like a regular Groovy {{execute()}} on a List. {code:java} ["/bin/echo", "foo", "bar"].execute(){code} Is not common to have Groovy's {{execute()}} allowed on Jenkins sandboxed environment, probably for very good reasons. Also even if {{execute()}} is allowed on the Jenkins sandbox, {{sh}} semantics are way more convenient. For reference: {code:java} def proc = ['ls', '/meh'].execute() println proc.getText() println proc.exitValue() != 0{code} Where is {{stderr}}? |
| Description |
Original:
As a Jenkins user, I'll like to use {{sh}} semantics to execute commands with {{args}}. I believe Jenkins needs an {{args:}} parameter for the {{sh}} step command, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing with the {{FileSystem}}. However, is clearly impossible or at least difficult to have clean (and secure) executions with {{sh}} if they involve string interpolations, maybe Jenkins should do this automatically, but I'm not sure if that kind of magic could be counter productive, I rather depend on args. Like: {code:java} sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} or a new pipeline step to avoid overloading {{sh}} with different behaviour {code:java} command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} On both cases {{echo}} the program, not the shell built-in should be executed, Jenkins should look for the program on the system's {{$PATH}} / {{%PATH%}} but also an absolute path should be supported too, like a regular Groovy {{execute()}} on a List. {code:java} ["/bin/echo", "foo", "bar"].execute(){code} Is not common to have Groovy's {{execute()}} allowed on Jenkins sandboxed environment, probably for very good reasons. Also even if {{execute()}} is allowed on the Jenkins sandbox, {{sh}} semantics are way more convenient. For reference: {code:java} def proc = ['ls', '/meh'].execute() println proc.getText() println proc.exitValue() != 0{code} Where is {{stderr}}? |
New:
As a Jenkins user, I'll like to use {{sh}} semantics to execute commands with {{args}}. I believe Jenkins needs an {{args:}} parameter for the {{sh}} pipeline step, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing with the {{FileSystem}}. However, is clearly impossible or at least difficult to have clean (and secure) executions with {{sh}} if they involve string interpolations, maybe Jenkins should do this automatically, but I'm not sure if that kind of magic could be counter productive, I rather depend on args. Like: {code:java} sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} or a new pipeline step to avoid overloading {{sh}} with different behaviour {code:java} command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} On both cases {{echo}} the program, not the shell built-in should be executed, Jenkins should look for the program on the system's {{$PATH}} / {{%PATH%}} but also an absolute path should be supported too, like a regular Groovy {{execute()}} on a List. {code:java} ["/bin/echo", "foo", "bar"].execute(){code} Is not common to have Groovy's {{execute()}} allowed on Jenkins sandboxed environment, probably for very good reasons. Also even if {{execute()}} is allowed on the Jenkins sandbox, {{sh}} semantics are way more convenient. For reference: {code:java} def proc = ['ls', '/meh'].execute() println proc.getText() println proc.exitValue() != 0{code} Where is {{stderr}}? |
| Description |
Original:
As a Jenkins user, I'll like to use {{sh}} semantics to execute commands with {{args}}. I believe Jenkins needs an {{args:}} parameter for the {{sh}} pipeline step, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing with the {{FileSystem}}. However, is clearly impossible or at least difficult to have clean (and secure) executions with {{sh}} if they involve string interpolations, maybe Jenkins should do this automatically, but I'm not sure if that kind of magic could be counter productive, I rather depend on args. Like: {code:java} sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} or a new pipeline step to avoid overloading {{sh}} with different behaviour {code:java} command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} On both cases {{echo}} the program, not the shell built-in should be executed, Jenkins should look for the program on the system's {{$PATH}} / {{%PATH%}} but also an absolute path should be supported too, like a regular Groovy {{execute()}} on a List. {code:java} ["/bin/echo", "foo", "bar"].execute(){code} Is not common to have Groovy's {{execute()}} allowed on Jenkins sandboxed environment, probably for very good reasons. Also even if {{execute()}} is allowed on the Jenkins sandbox, {{sh}} semantics are way more convenient. For reference: {code:java} def proc = ['ls', '/meh'].execute() println proc.getText() println proc.exitValue() != 0{code} Where is {{stderr}}? |
New:
As a Jenkins user, I'll like to use {{sh}} semantics to execute commands with {{args}}. I believe Jenkins needs an {{args:}} parameter for the {{sh}} pipeline step, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing around with shell redirection. However, is clearly impossible or at least difficult to have clean (and secure) executions with {{sh}} if they involve string interpolations, maybe Jenkins should do this automatically, but I'm not sure if that kind of magic could be counter productive, I rather depend on args. Like: {code:java} sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} or a new pipeline step to avoid overloading {{sh}} with different behaviour {code:java} command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code} On both cases {{echo}} the program, not the shell built-in should be executed, Jenkins should look for the program on the system's {{$PATH}} / {{%PATH%}} but also an absolute path should be supported too, like a regular Groovy {{execute()}} on a List. {code:java} ["/bin/echo", "foo", "bar"].execute(){code} Is not common to have Groovy's {{execute()}} allowed on Jenkins sandboxed environment, probably for very good reasons. Also even if {{execute()}} is allowed on the Jenkins sandbox, {{sh}} semantics are way more convenient. For reference: {code:java} def proc = ['ls', '/meh'].execute() println proc.getText() println proc.exitValue() != 0{code} Where is {{stderr}}? |
| Component/s | New: workflow-durable-task-step-plugin [ 21715 ] | |
| Component/s | Original: workflow-basic-steps-plugin [ 21712 ] |
This could also automatically or at user direction select a DurableTask implementation (sh, bat, powershell).
| Link | New: This issue relates to JENKINS-26169 [ JENKINS-26169 ] |
String.execute and friends are out of the question; these execute on the master.
In principle sh could take a List<String> though it may be tricky to process these since we do need to ultimately create a textual script, so any metacharacters would need to be escaped by Jenkins.